On Mon, Dec 30, 2002 at 02:29:31PM -0800, Jason Richey wrote:

I am 100% for the comments you had about changing the backend to be more generalizable. I think that a plugin type architecture for this type of thing would be ideal...

We can make such system after we have 3 or so renderers.

My thoughts: We currently have the <math> tags and are considering <music> and <tex>, right? At what point are we going to realize that the stuff that goes between these tags all share the same idea. That is, they are all text rendered into images and/or HTML for presentation. I think that it is crazy to add a tag every time we want to support a new renderer. We should use a single tag, and a modifier. A few possible examples:

<render type=tex>\sqrt[3]{x+y}</render> <render type=math>\sqrt[3]{x+y}</render> <render type=texvc>\sqrt[3]{x+y}</render> <render type=lilypond>\notes{r4 <a c e> c e}</render>

I think that using different tags makes it more readable. We'll probably have only a few renderers (math, music, chemistry, anything else ?) plus maybe some multilingual pronunciation processor (so people can see kana/kunrei/hepburn or pinyin_with_diactrics/pinyin_with_numbers/wadegiles or real_arabic/latinization or whatever else, depending on what they set in preferences, and maybe to connect it to some speech generator ...).

I don't think it's insane. XML guys do this all the time.

Of course I realize that this adds a bit of complexity for the wikipedian who is editing the code in the first place, but it could remove a huge burden from the wikipedia developers.

I'm kinda Wikipedia developer and I don't think it's a big burden. It's less than 10 lines per tag.

We could just publish a "render plugin API", and hope that someone from planetmath, or lilypond or whatever group of developers would take interest and write a plugin for that project.

Connecting texvc to Wikipedia script wasn't all that hard.

On a related note, I'd like some feedback on the suggestion to provide support for inline musical notation via GNU Lilypond: http://meta.wikipedia.org/wiki/Music_markup

In favor if we can get possible security issues sorted out (anyone e- mailed the Lilypond folks yet?). Also, we should run some performance tests on the MIDI generation etc. to make sure that it's not too taxing.

Since this is likely to come up again, should we think about a general plugin framework or something like that? texvc might be extended in that fashion.

Regards,

Erik

Brion Vibber wrote in part:

Shall I install [texvc] wikipedia-wide? Is there any objection other than Toby's? See: http://meta.wikipedia.org/wiki/Texvc

Since Tomasz responded yes when everybody knew that he thought so, then I won't feel bad about responding no when everybody knows that I think that. In any case, get Axel's answer first.

My essay on the above page left out an important point: Why we shouldn't install texvc now and then fix it later (assuming that the essay is persuasive on other points). Basically, the reason is that supporting LaTeX directly (as Axel and I want) won't be backwards compatible with current texvc; fixing it later will break some things.

I realise that I now need to get to work on writing an alternative to texvc that we can install soon. (Saying that texvc isn't good enough is unhelpful if there's nothing that is!) I hope that Axel agrees with my opinions on TeX support and will help. I don't expect that Tomasz will want to help, but of course I'd welcome anybody. (How such an alternative would work is already outlined in the essay.)

-- Toby

On Tue, Dec 31, 2002 at 02:45:44AM -0800, Brion Vibber wrote:

On lun, 2002-12-30 at 23:23, Toby Bartels wrote:

...

Why we shouldn't install texvc now and then fix it later (assuming that the essay is persuasive on other points). Basically, the reason is that supporting LaTeX directly (as Axel and I want) won't be backwards compatible with current texvc; fixing it later will break some things.

Is there anything that couldn't be fixed by a script (such as texvc itself modified to spit out the preferred LaTeX forms) which would hunt down and fix articles with problem math?

texvc is very automatic and also very fast. By very little code it can easily find things that break after upgrade - you can just check if old version accepts something while new doesn't and what is it.

So far I have used it for finding which symbols look different with AMS and without, and for lot of texvc testing.

Also texvc includes script that exports anything to pure TeX (which is also available on CGI), so if you wanted to take math from Wikipedia and do something with it you still can. (texvc produces some redundant {}s now in its TeX output, is it serious problem ?)

If someone really wants to try blacklist way, texvc can be easily modified to support it. Last line of texutil.ml says: | s -> raise (Illegal_tex_function s)

What means: everything else is illegal

It should be modified to: | "\foo" as s -> raise (Illegal_tex_function s) | "\bar" as s -> raise (Illegal_tex_function s) | s -> LITERAL (TEX_ONLY (s ^ " "))

What means: everything else is legal tex-only literal

where foo bar etc. are all banned functions. Those on current whitelist may be left to support HTML rendering etc.

But I don't think blacklist is any better as: * there may be dangerous undocumented functions * new functions may appear in new versions of TeX modules * adding more supported functions to texvc is very easy if they aren't too magical like \big. In particular adding support for tex-only symbols is trivial.