Mailing List Archive

On lun, 2002-12-30 at 13:08, Magnus Manske wrote:
> What's with the Tex feature update? Anything final yet?

It's sitting in CVS, and the fixed English language file looks right.
(** But we're still missing translations for the TeX options for most
languages! **)

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

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

-- brion vibber (brion @ pobox.com)

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...

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>

That way, Toby could lobby (and create...) for a different math
rendering engine without stopping progress on texvc, and people who
like texvc could use it if they wanted.

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. 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.

Just my $0.02

Jason

Brion Vibber wrote:

> On lun, 2002-12-30 at 13:08, Magnus Manske wrote:
> > What's with the Tex feature update? Anything final yet?
>
> It's sitting in CVS, and the fixed English language file looks right.
> (** But we're still missing translations for the TeX options for most
> languages! **)
>
> Shall I install it wikipedia-wide? Is there any objection other than
> Toby's? See: http://meta.wikipedia.org/wiki/Texvc
>
> 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
>
> -- brion vibber (brion @ pobox.com)
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikitech-l

--
"Jason C. Richey" <jasonr@bomis.com>

> 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

On Mon, Dec 30, 2002 at 02:01:35PM -0800, Brion Vibber wrote:
> On lun, 2002-12-30 at 13:08, Magnus Manske wrote:
> > What's with the Tex feature update? Anything final yet?
>
> It's sitting in CVS, and the fixed English language file looks right.
> (** But we're still missing translations for the TeX options for most
> languages! **)
>
> Shall I install it wikipedia-wide?

Yes.
Translations can be provided later.

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.

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 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?

-- brion vibber (brion @ pobox.com)

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.

----- Original Message -----
From: "Jason Richey" <jasonr@bomis.com>
To: <wikitech-l@wikipedia.org>
Sent: Monday, December 30, 2002 10:29 PM
Subject: Re: [Wikitech-l] Tex update status


> 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...
>
> 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>

While this makes logical sense from a development point of view, it leads to
exactly the kind of unreadable text which frightens non-programmers off. If
we're going down this road, we might as well drop the Wiki mark up
altogether and replace it by HTML. At least that way we'd be using a
standard mark up system.

Let's not do any tag design just to make implementation easy. The goal
should always be to aim at easy editing for authors, not easy code
implementation for developers.

Cheers

Derek