Hi,

On Mon, 13 Dec 2004, Brion Vibber wrote:

[...] that some new version of lilypond has a safe mode of some kind, but is not yet supported.

With all due respect, I inform you that LilyPond is heading away from TeX towards PostScript. And the extension which I posted, and which you also can find at

http://lily4jedit.sf.net/mediawiki-LilyPond-extension.tar.gz

uses this and the safe mode. The safe mode in LilyPond does not completely strip away GUILE support, but uses a sort of safe mode for GUILE as well AFAIK.

Hth, Dscho

Peter Danenberg wrote:

...

It does not (as I for some reason had assumed) seem to be part of MediaWiki 1.4. Is this being saved for 2.0?

 Brion (good man) and I laboriously hashed out a plan of

attack:

 1.   relativized, escaped paths

 2.   specific, fail-safe error messages

 3.   dvipng

As an addition, one actually can adjust the size and baseline alignment dynamically. Example:

http://www.mai.liu.se/~jalar/dvipng/test2.html

* Change your font size.

* Change text zoom and click on the page.

(Javascript on the client. Python on the server, currently.)

/Jan-Åke

Peter Danenberg wrote:

...

As an addition, one actually can adjust the size and baseline alignment dynamically.

 Using the --depth option, I understand, Jan-Åke?

Exactly. A javascript snippet walks through the class="latex"-marked html pieces, and asks the server for images suitable for the current fontsize. The font-size is extracted on the client individually and dynamically for each code piece, while the code is extracted server-side and images are generated. The client gets a response which contains links to correct-sized images, and their depth. It then exchanges the code pieces for the images and sets their vertical-align suitably.

/JÅ

Jan-Ake Larsson wrote:

Benefits:

• No need to pre-render latex code.
• Nicely positioned correctly sized math.
• REAL SIMPLE code: <span class="latex">$\sqrt2$</span>

Drawbacks:

• No javascript? No images. You'll see latex source.
• IE on a high-res screen still has problems, I haven't had time to fix this.

* There is no javascript text-zoom-change event. That is why you'll need to click on the page to re-render it after text zoom change.

/JÅ

Brion Vibber wrote:

On Dec 16, 2004, at 4:41 AM, Jan-Ake Larsson wrote:

...

• No need to pre-render latex code.

Oh, this one's *so* not gonna happen. Sounds like DoS heaven -- every wonk who changes his font size hits our servers up for a slow TeX render and rasterization.

TeX render only happens once for each page (you already have this run in your present solution, just cache the DVI). Then, change your Really Slow dvips->gs raster route to dvipng and you'll find that the rasterization is not that slow anymore. And then there is image caching, which you already use. So do I. Putting a sensible limit to the number of allowed font sizes will remove another problem. About a dozen or so different (integer pixel) sizes will be more than enough. Only Really Odd people (and DoS wonks, of course) will be outside that, and the improvement is great for the large mass of users.

...

• No javascript? No images. You'll see latex source.

Sorry, not gonna happen.

At the price of prerendering some fixed-size default image this can be avoided, of course. You already do this "standard"-size rendering, and cache the result. I'd think this is mostly a problem for static-html sites (as is mine). Not so much a problem for a site where the pages are generated dynamically anyway.

Don't let the shortcomings of my present code stop you from improving it.

/JÅ