Cairo had pub/icn/_filetypes.txt to map from icon name to icon file. This functionality is now missing. Test case using %ICON{...}%:

• jpg
• jpeg
• zip
• tz
• tar
• taz
• z
• xls
• xla
• xlb
• xlc

-- PTh

---

The functionality is still there - nothing has changed for attachments. The ICON syntax is based on name mapping, not on filetype mapping. -- AC

---

Fair point, ICON{} was never supported for file attachment icons. Wondering where is the mapping done now? There is no pub/icn directory anymore.

Since ICON{} can now be used to render file attachment icons it is natural to assume that %ICON{tar}% etc works since those extensions are very common. Re-classified as Enhancement.

-- PTh

---

• Render.filenameToIcon does the filetype mapping and reads _filetypes.txt
• Render.getIconHTML does the ICON name mapping

You could try to first map the name to a filetype. For instance %ICON{jpeg}% would lead to reading from _filetypes.txt that jpg should be used and creates html for jpg.gif. Only the defaulting to else.gif should be circumvented when no mapping name is found.

I was thinking about optimization - wouldn't caching be a good idea for this? Because the icon html is generated again and again.

AC

Performance is important. ICON{} is currently fast since it assumes that the icon file exists (and simply generates an image tag to a non-existing file if not). I do not want to initiate file exist check since this is slow. The _filetypes.txt content could be read once per script invocation (or once per compile in mod_perl) and cached in memory. If extension is not found ("else") one can assume that it is an existing attachment. The complete list of attachments can also be cached.

It looks like some more coding is needed, therefore better to defer this to Edinburgh.

-- PTh

Closing stale & obsolete item.

-- PeterThoeny - 2010-11-06