Re: No IMG in FIG

Michael Johnson ([email protected])
Fri, 14 Jul 95 14:23:35 EDT


Benjamin Sittler wrote:
>It would be really nice if the content model on FIG were changed to allow
>IMG's inside... the justification being that one could provide three
>levels of complexity with a single block of HTML, i.e. for a clickable
>image map situation:

[Good example deleted]

>Any comments?

Yes. That sounds like a good idea to me. I can't think of any REALLY good
reason to disallow IMG inside of a FIG. The worst that can happen is the
images don't get fetched and their alternate text is used instead. For
that matter, there's no technical reason why FIG should not be allowed
inside of a FIG. Sure, there's no current reason why disallowing it is
a problem, but future expansions of FIG functionality may make it an
unreasonable restriction.

Actually, I can think of a (slightly contrived) example right now where a
nested FIG could be useful. Let's say you have browsers that substitute the
FIG content for the image if they can't fetch the image or can't understand the
image format. The author of a document might want to use an obscure image
format that (s)he knows some browsers don't understand, and could use a
construct like this to avoid having to write a script:

<FIG src="graphic.oif"><FIG src="graphic.jpg"></FIG></FIG>

A browser that didn't understand Obscure Image Format would then format the
inner FIG and would be able to deal with the JPEG image.

This would be a much more useful behavior than simply giving up on the outer
FIG and substituting a default icon.

In the future, something like this might be desirable:

<FIG src="graphic.pdf">
Text that approximates the PDF contents and includes a
<FIG align=right src="fig1.jpg"><CAPTION>Figure 1</CAPTION></FIG>
More text that comes after the figure.
</FIG>

This would allow the figure to be displayed using an OLE type mechanism to
format the PDF file if support is there for it, but would format the alternate
content (which includes a FIG) if no PDF helper was available.

Michael Johnson
Relay Technology, Inc.