Enhance inline image handling

[daniel+trac@…]

It would be nice if the Trac wiki would support ways to:

• Inline attached images via straightforward syntax
• Inline images by relative URIs, without leading http:
• Force the inlining of images with arbitrary URLs, not necessarily beginning with http: and not necessarily ending in .png, .jpg, .gif

without falling back to inline HTML and WikiProcessors magic.

Possible syntax could be:

PageName/attached-image.png or PageName:attached-image.png
image:relative/path/to/image.png
image:/uri/to/image.png
image:http://foo.com/image.bmp
image:/cgi-bin/generated-image.cgi

Also compare with #691 where a similar issue is raised for hyperlinks, with solutions partially covering some of the above cases in a different way.

[tstivers@…]

The patches I made for #691 will auto-inline relative links to images but won't handle cgi generated
images (it inlines using extensions just like ​http:// links). I'd like to see some way of doing relative links, including
links to images included in the 0.8 release if at all possible. It would also be nice to reference attachments as
attachment:filename.ext and [attachment:filename.ext fancyname] with auto image inlining based on extension.

[Steven N. Severinghaus <sns@…>]

For what it's worth, I've made a minor change to source:/file/trunk/trac/WikiFormatter.py that allows us to put images inside links, e.g. [http://foo/bar.jpg http://foo/bar_thumb.jpg] could be used to create a thumbnail link. The complete source of the relevant function is below. I can supply a diff if desired, but the change is fairly obvious and localized to the last few lines.

    def _fancylink_formatter(self, match, fullmatch):
        link = fullmatch.group('fancyurl')
        name = fullmatch.group('linkname')

        module_link, t, missing, title = self._expand_module_link(link)
        if module_link and missing:
            return '<a class="missing" href="%s">%s?</a>' % (module_link, name)
        elif module_link:
            return '<a href="%s">%s</a>' % (module_link, name)
        elif name.endswith('.png') or name.endswith('.jpg') or name.endswith('.gif'):
            return '<a href="%s"><img src="%s" alt="%s" /></a>' % (link, name, name)
        else:
            return '<a class="ext-link" title="%s" href="%s">%s</a>' % (link, link, name)

An example of this in action can be found ​here.

[cboos]

I'll try to integrate the Image macro from Shun-ichi Goto.

[cboos]

Seems to work fine. Fixed in [1872] (source:trunk/wiki-macros/Image.py#latest)

An environment upgrade is needed for installing the new macro
(see [1871]).

[cmlenz]

cboos, I don't quite understand why you implemented this as a "classic" user macro. Why not put it, together with the other core macros, in trac.wiki.macros​? I really think this functionality is important/essential enough to be put in the core.

[cboos]

Well, ok, I'll do it tomorrow.

At least it helped me to discover a few issues with user macros :)

[cboos]

Hm, I think it would be better to leave this big macro
in its own file:

• source:trunk/trac/wiki/macros/image.py

The other default macros source:trunk/trac/wiki/macros.py​
could then either go in

• source:trunk/trac/wiki/macros/default.py

or be split up:

• source:trunk/trac/wiki/macros/title_index.py
• source:trunk/trac/wiki/macros/recent_changes.py
• source:trunk/trac/wiki/macros/page_outline.py
• source:trunk/trac/wiki/macros/macro_list.py
• source:trunk/trac/wiki/macros/user_macros.py

Besides being default macros, those macros are quite unrelated
to each other, so I think splitting them up is better.

[cmlenz]

Why? I just don't see the problem here.