Mailing List Archive

Tomasz Wegrzanowski wrote:
> How to link to image and set alt= with wiki markup ?
> IMG has been banned in phase 3.

[[image:foo.png|alt text]]

-- brion vibber (brion @ pobox.com)

On Thu, Nov 28, 2002 at 10:02:17PM -0800, Brion VIBBER wrote:
> Tomasz Wegrzanowski wrote:
> >How to link to image and set alt= with wiki markup ?
> >IMG has been banned in phase 3.
>
> [[image:foo.png|alt text]]

Not that thing !
External image.

I thought we decided that external images are evil (TM)?

Magnus


Tomasz Wegrzanowski wrote:

>On Thu, Nov 28, 2002 at 10:02:17PM -0800, Brion VIBBER wrote:
>
>
>>Tomasz Wegrzanowski wrote:
>>
>>
>>>How to link to image and set alt= with wiki markup ?
>>>IMG has been banned in phase 3.
>>>
>>>
>>[[image:foo.png|alt text]]
>>
>>
>
>Not that thing !
>External image.
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l@wikipedia.org
>http://www.wikipedia.org/mailman/listinfo/wikitech-l
>
>
>

Tomasz Wegrzanowski wrote:
> On Thu, Nov 28, 2002 at 10:02:17PM -0800, Brion VIBBER wrote:
>>Tomasz Wegrzanowski wrote:
>>
>>>How to link to image and set alt= with wiki markup ?
>>>IMG has been banned in phase 3.
>>
>>[[image:foo.png|alt text]]
>
>
> Not that thing !
> External image.

Upload the image to the Wikipedia server and link as above.

Non-local inline images are inherently unreliable; the source may move
or delete the image without warning, may consider us to be bandwidth
thieves and block anything with a referrer from Wikipedia, may just be
down when we're up, may not be copyright-compatible, and could be
unhelpful to attempts to set up offline mirrors.

(IMHO)

-- brion vibber (brion @ pobox.com)

On Fri, Nov 29, 2002 at 12:53:33AM -0800, Brion VIBBER wrote:
> Tomasz Wegrzanowski wrote:
> >Not that thing !
> >External image.
>
> Upload the image to the Wikipedia server and link as above.
>
> Non-local inline images are inherently unreliable; the source may move
> or delete the image without warning, may consider us to be bandwidth
> thieves and block anything with a referrer from Wikipedia, may just be
> down when we're up, may not be copyright-compatible, and could be
> unhelpful to attempts to set up offline mirrors.

Well, images I want won't rally be external, but won't be uploaded either.
In any case, linking to external images should be policy issue,
not something that is forced by software.

I was trying to put Math parsing somewhere into 15-passes Wikipedia
markup parsing. Because there is no way to protect math markup from
interpretation by Wiki, I had to put it before removeHTMLtags.
But then, removeHTMLtags breaks <img src="" alt=""> tag.
Even if I tell removeHTMLtags to accept IMG ALT and SRC,
replaceExternalLinks would kill url in src="".

Any ideas ?

And some day we should make that parser a single-pass LALR ...

On Fri, Nov 29, 2002 at 03:51:21PM +0100, Tomasz Wegrzanowski wrote:
>I was trying to put Math parsing somewhere into 15-passes Wikipedia
>markup parsing. Because there is no way to protect math markup from
>interpretation by Wiki, I had to put it before removeHTMLtags.
>But then, removeHTMLtags breaks <img src="" alt=""> tag.
>Even if I tell removeHTMLtags to accept IMG ALT and SRC,
>replaceExternalLinks would kill url in src="".
>
>Any ideas ?
>
>And some day we should make that parser a single-pass LALR ...

Feel free to contribute to the mod_wiki design document; since it is
written in C, you can use lex and yacc for the parser. I assumed
Clutch was going to use a simple state machine; no overhead from regex
libraries, and lex and yacc have always been fairly finicky. But if
they are copacetic to your way of coding, by all means, bring it on.

Beginnings of the design document:

http://www.wikipedia.org/wiki/User:Clutch/mod_wiki

Jonathan

--
Geek House Productions, Ltd.

Providing Unix & Internet Contracting and Consulting,
QA Testing, Technical Documentation, Systems Design & Implementation,
General Programming, E-commerce, Web & Mail Services since 1998

Phone: 604-435-1205
Email: djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC V5R2W2

On Fri, Nov 29, 2002 at 03:51:21PM +0100, Tomasz Wegrzanowski wrote:
> On Fri, Nov 29, 2002 at 12:53:33AM -0800, Brion VIBBER wrote:
> > Tomasz Wegrzanowski wrote:
> > >Not that thing !
> > >External image.
> >
> > Upload the image to the Wikipedia server and link as above.
> >
> > Non-local inline images are inherently unreliable; the source may move
> > or delete the image without warning, may consider us to be bandwidth
> > thieves and block anything with a referrer from Wikipedia, may just be
> > down when we're up, may not be copyright-compatible, and could be
> > unhelpful to attempts to set up offline mirrors.
>
> Well, images I want won't rally be external, but won't be uploaded either.
> In any case, linking to external images should be policy issue,
> not something that is forced by software.
>
> I was trying to put Math parsing somewhere into 15-passes Wikipedia
> markup parsing. Because there is no way to protect math markup from
> interpretation by Wiki, I had to put it before removeHTMLtags.
> But then, removeHTMLtags breaks <img src="" alt=""> tag.
> Even if I tell removeHTMLtags to accept IMG ALT and SRC,
> replaceExternalLinks would kill url in src="".
>
> Any ideas ?
>
Did you look into the code I sent you? It parses math formulas as
internal links, but instead of an <A HREF= it generates an
<IMG SRC= -Tag. The PHP-Code can generate IMG-Tags of course, it's
just the wikie markup that can't.

Regards,

JeLuF

On Fri, Nov 29, 2002 at 03:51:21PM +0100, Tomasz Wegrzanowski wrote:
>I was trying to put Math parsing somewhere into 15-passes Wikipedia
>markup parsing. Because there is no way to protect math markup from
>interpretation by Wiki, I had to put it before removeHTMLtags.
>But then, removeHTMLtags breaks <img src="" alt=""> tag.
>Even if I tell removeHTMLtags to accept IMG ALT and SRC,
>replaceExternalLinks would kill url in src="".
>
>Any ideas ?

Ah! Well, that's a different matter then.

Worst case, use a placeholder string; replace all math sections with the
placeholder, store them in a stack, then dump in the interpreted code
after user-supplied tags are dealt with. I believe some pass or another
currently works like this. Ugly, but...

Yes, we need to rewrite the parser sometime! Preferably something that
can guarantee well-formed XHTML, since we keep making noises about
MathML and SVG.

-- brion vibber (brion @ pobox.com)

Tomasz Wegrzanowski wrote:
> Well, images I want won't rally be external, but won't be uploaded either.
> In any case, linking to external images should be policy issue,
> not something that is forced by software.

Well, some policy issues should be forced by software.

What images are you talking about that won't really be external but
won't be uploaded either?

--Jimbo

On Tue, Dec 03, 2002 at 06:37:10AM -0800, Jimmy Wales wrote:
> Tomasz Wegrzanowski wrote:
> > Well, images I want won't rally be external, but won't be uploaded either.
> > In any case, linking to external images should be policy issue,
> > not something that is forced by software.
>
> Well, some policy issues should be forced by software.

I don't think this should be one of them.

> What images are you talking about that won't really be external but
> won't be uploaded either?

Math generated from pseudo-TeX.
See other threads on wikitech-l.

Tomasz Wegrzanowski wrote:

>>What images are you talking about that won't really be external but
>>won't be uploaded either?
>>
>>
>
>Math generated from pseudo-TeX.
>See other threads on wikitech-l.
>
>
External images are Evil(TM). Either a [[tex:]] namespace, or you
generate them in the upload directory somewhere and use [[image:]].

Magnus

On Die, 2002-12-03 at 16:20, Magnus Manske wrote:
> External images are Evil(TM). Either a [[tex:]] namespace, or you
> generate them in the upload directory somewhere and use [[image:]].

What's the point? The TeX can be directly edited, it doesn't need its
own namespace or to be stored in an image namespace => waste of space
and user confusion.

External images are evil because they can be abused or disappear. Here
the files are local, and the LocalSettings.php contains the path where
the autogenerated TeX images are stored, so this can be easily made an
allowed URL for "external" (i.e. non-namespaced) images.

Regards,

Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de

On Tue, Dec 03, 2002 at 04:53:07PM +0100, Erik Moeller wrote:
>What's the point? The TeX can be directly edited, it doesn't need its
>own namespace or to be stored in an image namespace => waste of space
>and user confusion.

I notice that a TeX namespace is nicely supported in Clutches new
scheme; the actual TeX would go in the comment field, and the
PNG generated from it would go into the data field. It would be like a
special kind of image.

I personally am in favor of a [[tex:]] namespace.

Jonathan

--
Geek House Productions, Ltd.

Providing Unix & Internet Contracting and Consulting,
QA Testing, Technical Documentation, Systems Design & Implementation,
General Programming, E-commerce, Web & Mail Services since 1998

Phone: 604-435-1205
Email: djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC V5R2W2

On Die, 2002-12-03 at 17:07, Jonathan Walther wrote:
> On Tue, Dec 03, 2002 at 04:53:07PM +0100, Erik Moeller wrote:
> >What's the point? The TeX can be directly edited, it doesn't need its
> >own namespace or to be stored in an image namespace => waste of space
> >and user confusion.
>
> I notice that a TeX namespace is nicely supported in Clutches new
> scheme; the actual TeX would go in the comment field, and the
> PNG generated from it would go into the data field. It would be like a
> special kind of image.
>
> I personally am in favor of a [[tex:]] namespace.

Again, what's the point? Users don't want to create separate TeX pages,
they want to use TeX as part of their regular articles. So they want to
write, as Tomasz' scheme allows them to, stuff like

<math>
\pi * 4 / 2
</math>

They don't want to do

[[TeX:My formula]]

then create the TeX page, then go back to the page and continue writing.
So should the <math> .. </math> pair transparently create a new page?
That sounds like an awful idea.

If you want an application where namespaces would be useful, take a look
at the poll scheme described here:
http://www.wikipedia.org/wiki/Wikipedia%3ADecision_Making_Process

Tomasz' TeX scheme is already quite well thought out. It only needs some
tweaks to be useful IMHO.

Regards,

Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de

On Tue, Dec 03, 2002 at 05:31:24PM +0100, Erik Moeller wrote:
>They don't want to do
>
> [[TeX:My formula]]
>
>then create the TeX page, then go back to the page and continue writing.
>So should the <math> .. </math> pair transparently create a new page?
>That sounds like an awful idea.

Although that is a possibility, it wasn't what I had in mind. I was
thinking something like [[tex:\pi * 2]], and the image and page would be
generated when you saved your edit, if they didn't already exist. Every
day or so, "orphaned" articles in the tex namespace could be deleted
entirely with a single simple, non-cpu-intensive, non-database-lagging
query. These "objects" would only exist in the current and pages tables;
they'd never reach the deleted or previous tables.

>Tomasz' TeX scheme is already quite well thought out. It only needs some
>tweaks to be useful IMHO.

If we ever start getting the content and daily hits that PlanetMath is
getting, watch server performance drop into the toilet. tex itself is
not fast to run. Stick 10 of these tex invocations in, and the page
will take a long time to load.

Jonathan

--
Geek House Productions, Ltd.

Providing Unix & Internet Contracting and Consulting,
QA Testing, Technical Documentation, Systems Design & Implementation,
General Programming, E-commerce, Web & Mail Services since 1998

Phone: 604-435-1205
Email: djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC V5R2W2

On Die, 2002-12-03 at 17:34, Jonathan Walther wrote:

> If we ever start getting the content and daily hits that PlanetMath is
> getting, watch server performance drop into the toilet. tex itself is
> not fast to run. Stick 10 of these tex invocations in, and the page
> will take a long time to load.

Tomasz' texvc generates the images in a directory and re-uses them on
demand (the TeX strings are hashed and stored in a table). I doubt it
would be a performance hit at all, but if it would,
texvc->latex->dvips->convert could easily be executed on a remote
machine.

Regards,

Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de

On Tue, Dec 03, 2002 at 06:01:23PM +0100, Erik Moeller wrote:
>Tomasz' texvc generates the images in a directory and re-uses them on
>demand (the TeX strings are hashed and stored in a table). I doubt it
>would be a performance hit at all, but if it would,
>texvc->latex->dvips->convert could easily be executed on a remote
>machine.

Well, that is fine, but I'd prefer having the TeX text and resulting
images in the database. Makes internal coding a lot easier. We have
namespaces; there is no reason not to use them. Having it in-database
lets us check for orphaned equations trivially.

Jonathan

--
Geek House Productions, Ltd.

Providing Unix & Internet Contracting and Consulting,
QA Testing, Technical Documentation, Systems Design & Implementation,
General Programming, E-commerce, Web & Mail Services since 1998

Phone: 604-435-1205
Email: djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC V5R2W2

Jonathan Walther wrote:

>I notice that a TeX namespace is nicely supported in Clutches new
>scheme;

You *notice*???


-- Toby

On Tue, Dec 03, 2002 at 09:06:18AM -0800, Jonathan Walther wrote:
> On Tue, Dec 03, 2002 at 06:01:23PM +0100, Erik Moeller wrote:
> >Tomasz' texvc generates the images in a directory and re-uses them on
> >demand (the TeX strings are hashed and stored in a table). I doubt it
> >would be a performance hit at all, but if it would,
> >texvc->latex->dvips->convert could easily be executed on a remote
> >machine.
>
> Well, that is fine, but I'd prefer having the TeX text and resulting
> images in the database. Makes internal coding a lot easier. We have
> namespaces; there is no reason not to use them. Having it in-database
> lets us check for orphaned equations trivially.
>
There is no reason to have the image in the DB. All you need is the
meta-information to do what you want to do. And that's what's already
going to be put into the DB. You can check for orphaned images without
having the actual image in the database.

Regards,

JeLuF