How to link to image and set alt= with wiki markup ? IMG has been banned in phase 3.
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
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
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
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
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
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
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
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
wikitech-l@lists.wikimedia.org