This is musing about a possible extension to TWiki's handling of attachments; it may be doable within a plugin.

My group - my community of people using wiki - would like to be able to see more attachments "inline".

TWiki currently allows GIFs to be viewed inline. That's pretty much all that HTML supports.

Many browsers, e.g. Internet Explorer, allow other file types to be viewed - perhaps not actually "inline" within the twiki page, but inside a browser/frame. E.g. Powwerpoint, Word, Excel, Visio, documents. TWiki pages can link to such pages stored elsewhere, but then you lose the ease of manipulation that attachments provide.

My group tends to work with a lot of pictures and diagrams. Many of which we automatically generate. Many of which we want to be hyperlinked themselves - click on the circle on this diagram, and jump to another diagram that expands that subsystem, etc.

I do not see how to create clickable image maps for GIF attachments to TWiki. Or rather, you can, but it's painful.

Overall, atttachments are somewhat second class - you have to do a bit more clicking to get to them.

I am wondering about extending TWiki to, e.g., place some attachments in frames. The TWiki text in one frame, easily editable as always; the non-TWiki text attachment visible in another frame, at the same time as the TWiki text. The non-TWiki text attachment would still live in the TWiki attachments area.

This might be accomplished by

1. a modified view script
2. possibly a plugin that generates the appropriate HTML for ordinary TWiki view

I know that there are many problems with frames. E.g. when I described how I am currently using a frames based skin (to keep the buttons at the top while scrolling), many folks said I should use CSS or XSLT instead. I do not see how to use these alternative approaches to view non-HTML, non-TWiki, based attachments, but I would be happy to be enlightened.

-- AndyGlew - 08 Aug 2003

I do not think that you need to add Frames to the pictures. Why not just use the same method as for images: have them just embedded via an IMG tag in the page to view/use them, and click on the attachment part to edit them.

You will want thus some graphic clickable format understood by browsers (with client-side plugins): I can think of many:

• SVG, of course
• Flash
• PDF
• Powerpoint...

One enhancement could be to define "converters" to convert the attachement to a page-embeddable clickable representation. E.G,

• you attach a Visio document to a TWiki page
• you save, asking to put a link in the page to it
• the system see that it is a visio doc, and thus calls a converter to convert it into a clickage graphic representation (html image map, svg?). I know that some of these converters exists already
• The included image is the converted data

Thus the part to code into TWiki would be , a "wrapping" to call site-defined and site-installed converters (The visio->image maps will surely be some non-free app, and whether you accept SVG or image maps is site-dependent), and will use the relevant tag to embed: IMG, EMBED, OBJECT, ... see http://www.svgfaq.com/Starting.asp#3 It could also optionally add a link ("edit") to an editor for the source attached document too.

-- ColasNahaboo - 10 Aug 2003

I wasn't aware that you could do an image map for something like PowerPoint. I'll test it here, in TestingPowerPointInlining. ... It does not work.

I tentatively conclude that viewing PowerPoint as an image is not something that works out of the box with IE6. Whereas viewing PowerPoint as a page of its own, or in a frame, is supported by IE6 (and, so far as I know, at least back to IE4). On UNIX it's more problematic, but I believe that Opera and Mozilla all have reasonable MIME type handling, and can bounce to OpenOffice.

I tentatively conclude that an image viewer for PowerPoint would have to be separately installed as a browser pluginb. And, since I do not want my users to have to install anything extra, unacceptable for my purposes.

Doing it server side via a converter might be acceptable. But

1. I do not know of such converters, at least not freeware (and I am unlikely to bother with payware for this)
2. even if I knew of such converters that can run on the fly, they probably lose the nice browsing, etc., capabilities of using an application that is properly aware of the file type (like PowerPoint or OpenOffice)

And overall

• Doing it via frames just plain works now, for at least the browsers that I care about, without requiring any extra software to be purchased, installed, or maintained. Like we say in Portland, Oregon: "Free is a very good price". There has to be a compelling reason not to take advantage of a freebie like this.

-- AndyGlew - 11 Aug 2003

Andy, that's why I wrote "site-defined and site-installed converters". These converters must be installed on the server, not the client. And since you mentioned only expensive software ("Powerpoint, Word, Excel, Visio, documents"), it is logical that you pay for additional converters.

On imagemaps, they will consist of HTML, see Client-side image map examples at http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.6.1

TWiki will have to generate all the HTML you see in example from results by the converters...

-- ColasNahaboo - 12 Aug 2003