Version 3 of Embedding Images in the Wiki

Updated 2001-10-09 16:42:39

'There are two issues: getting the image to show up in the HTML (not that hard), and fetching the image and store it locally for when the wiki is used in local Tk mode. That last one is slightly trickier, because of the need to re-check and update somehow, and to clean up images which are no longer being used. Nothing earth-shattering, but that sort of explains why it's not there yet... -jcw''

Bryan Oakley writes... perhaps one solution is to have a special wiki page for managing images. Much like there is a magic "recent changes" page and "search" page, there could be an "images" page. It could present a list of known images with buttons to resubmit, rename or delete. And, of course, a New button. This page would be easy to write in the Tk version, and in the HTML version could be done using forms.

Another issue is how to represent embedded images in the markup. One suggestion is to overload with some additional markup. So, for example [[MyImage]] or [:MyImage:] would embed MyImage. Of course, if you added the restriction that images share their namespace with pages, and thus you can't have page and an image with the same name, a simple [MyImage] would suffice, as the software would know that it is an image and Do The Right Thing.

FWIW, some of the users of my personal wiki are also asking for this feature. What's the liklihood of it happening in the near future?

Define "near future"... :o) -jcw

(yesterday? --bdo :-)

Actually, if getting it right on the web is good enough for now, then I'd be willing to have a go at it. After all, external web links don't work in local Tk mode either (yet), so it's no more dramatic than that. I want to upgrade TclKit to a new release soon anyway, this would be an excuse to mess with the Tcl'ers Wiki, I suppose...


Bryan Oakley: If there were an official syntax for saying "embed this image", that would be a fabulous first step. Beyond that, it would be even better to have a way to submit static files to the wiki. Surely that's fairly easy (?). The mechanics can be simple -- click on the embedded image (or on the broken link for newly created references to images) and get a page with a field for entering in a physical file name on the client's machine and a button that says "store it!". Click the button and the wiki grabs the file, internalizes it, and makes it available to anyone who wants to use it. For the web this can use the standard way of submitting files via forms. For tk, you can just use the standard file open dialog box.

JC: How's this... http://www.equi4.com/images/wikit.png

To do this, I changed these lines in scripts/format.tcl:

    508             if {[string first x $mode] >= 0} {
    509                 if {[regexp {\.(gif|jpg|png)$} $q]} {
    510                     append pre "<img src=\""
    511                     set post "\">$post"
    512                 } else {
    513                     set pre "\[<a href=\"$q\">$pre"
    514                     append post </a>\]
    515                     set q [incr count]
    516                     lappend urls $text $q
    517                 }
    518             }

Then "tclkit wikit.tkd -scripts/format.tcl=./format.tcl" or something like that...


Thanks JC! Of course, now we need a little control over it so we can wrap text properly around images (and conversely be able to stop wraps). - DL

Just noticed, wonderful. Thanks - AK

To avoid wrapping, save as: text - empty_line - bracketed_image_url - empty_line - text -jcw


It would also be nice to have an option to turn off inlining. For example, I may actually want to create a link to an image versus inlining it. How hard would it be to overload [] somehow; for example, maybe to inline an image we do [<http://...foo.gif>] , so that [.http://...foo.gif ] does what it does now (I had to add a dot before the http, or wiki would have changed it to a ref even though I doubled up on the ['s)

Sheesh, we're not picky :-)

--Bryan Oakley

Sheesh, you said it... :o)

That's why I avoided image inlining of URL's mentioned without brackets: http://www.equi4.com/images/wikit.gif ... isn't that good enough? -jcw

'Nother comment: lest you think I'm making this convention up as we go... not so, this was in one of the other wiki designs I looked at (long ago, don't ask mw which one, please).


(July 11, 2000) FWIW, I installed the above code snippet and it worked like a charm. Makes for a fine addition to the wiki. Thanks, JC! --Bryan Oakley


(July 17, 2000) I've been mucking about in the code, trying to figure out how to support storing images in the wiki database. That part I've figured out, and I've learned in the process that metakit is pretty cool. I figured out how to create a "view" for images (ie: a database table), and how to insert and extract the data. I've also figured out how to get wikit to serve images which have their raw data stored in the wiki database.

What I'm struggling with is how to seemlessly integrate my changes into the wiki code base. The data path through the code isn't exactly obvious :-| (You were so kind to leave my name out, but I'll confess that is really is a bit messy and way too complex - all I can say is that it was written when I knew less about Tcl than I do now... JC)

Anyway, what I'm thinking is that images should work pretty much like normal pages in that if you embed a reference to an image that doesn't exist you'll get a special "look" (I'm thinking of a special "unknown image" -type image). Click on it and it takes you to a page to edit the image. Only, instead of a text area you get a file input button.

I think I've figured out how to do forms within the wiki, so to some degree it's just a matter of putting it all together. The only sticky point (I think...) is that throughout the code the wiki kinda assumes everything it serves is text -- there's no real provision for passing around the page type in addition to the page data. So, support for self-contained images might be a slight hack. Perhaps once I get it done JC can better integrate it with his stuff..

[time passes]

Hmmm. I'm almost of the opinion this won't be a very big hack afterall. I can just add special processing in the final rendering of the page based on the name of the page. if it's a .gif, .jpg or .png we simply inline the image. For editing, instead of a textarea we get a file submission box. Hmmmmm.... sounds simple. I'm motivated to make this work and might have an afternoon to see what I can do.

Stay tuned.

--Bryan Oakley

Thanks Bryan, for persevering - I am tracking every move you make and will try to help where possible. True: WiKit was never written with forms in mind... (nor even images, to be honest) -- JC


ok, here's a question: should the image data be stored in the same field in the database as a page (ie: in the pages view) or in its own table? I see that the pages view uses a type of "memo" rather than "binary", but image, I would think, should use "binary"?

I'm leaning toward a separate table, which is what I have now. I'm tossing about the idea of having a text page for every image, so something like foo.gif would be synonymous with, say, 99.html (the text page, with the image instead of a bunch of text, but with the same links at the bottom to edit, expand, etc. Though it could *also* have text, such as random notes by the person who added the image). A reference to 99.gif would serve the actual image itself (so, internally, the code generated would look like <img src=99.gif>). There would also be a record in the "images" view with a name of "foo.gif" (and/or 99 as a sort-of foreign key).

Sadly, I've run out of free time to work on it, but I still have it back-burnered. I have a proof-of-concept working (I can view and edit images) but it's too hackish. I need to reimplement it before making it public.


JC: please use a separate table/view, that way WiKit's text searches will not be affected. As for (M) vs. (B) - these are semantically equivalent (M is better for large amounts of data, but the latest MetaKit 2.3.x now decides itself how to store data - M is about to be deprecated, everything will eventually be converted to B).

I suggest keeping image storage very minimal: i.e. no text, since that can be handled by existing Wiki mechanisms (let people add comments *around* the image, on a normal wiki page) and benefits from all the infrastructure there is already. Perhaps a view with just name and image? The "name" could be the entire URL, to avoid problems with duplicate image names. In a way, this name/URL + image-data view then becomes nothing more or less than a cache (maybe a date could be added - note that MetaKit makes it easy to add such extra fields later). Taking this idea further, the wiki page could continue to contain the URL it currently holds - the cache would merely cause the generated HTML page to refer to another wiki page, of the special form "N.{gif,png,jpg}", perhaps.

I agree completely -- I've already got the image view with the two fields you suggest, and it is working just dandy. We'll see how this turns out... (Bryan Oakley)

The benefit and purpose of all this is that the one-file wiki becomes self-contained w.r.t. images as well, and that it would not be hard to support local Tk display as well, right?

Right. (Bryan Oakley)

For a very different approach to self-contained scripted documents with HTML and embedded images, see [L1 ] - it is based on Richard Hipp's Tkhtml widget. I'm mentioning it, because it could be a way to make WiKit properly support HTML locally one day.


-EE (2001/Jun/14) Corrected the URL reference to dok. Do any of the people who held the above discussion (nearly a year ago) feel like summarising the current state of affairs?


Category Wikit