[l2h] graphicx.perl

Bruce Miller bruce.miller@nist.gov
Wed, 24 Jan 2001 23:46:12 -0500

Ross Moore wrote:
> >  2) The way I coded it, we'll ultimately need get_image_size to support
> > jpegs.
> That would be useful more generally.
> >  3) The code has two general purpose subs find_file & maybe_copy_image
> > that [... preserve timestamps ...]
> Yes, this probably should be in  L2Hos.
> Alternatively, can it be inherited from a standard Perl module ?

There's a module Image::Size which actually uses the code from the
people I borrowed it
from!  And it understands gif, jpeg, tiff, png, xbm, xpm ppm and bmp.
And there's a File::NCopy which preserves timestamps (portably?).

Does the l2h installation easily allow to check for/install additional
perl modules?

> > As for the ALT attribute:
> Think of it this way;
>   the ALT text says briefly what the image "is"
>     (e.g.  "bar-chart of sales figures")
>   whereas the \caption is used to say something about what the image "means"
>     (e.g.  "This graph shows the slump in sales during the 3rd quarter.")

Yeah, I guess you're right; it just seemed better than what you get most
of the
time... [Tool Tips!!! Yay!!! pthbttt! :< ]

> >   1) The pixel image has been prepared by hand, or is in some other way
> >      preferable, _as_is_, to the converted eps image.  eg. size info is
> >      only there to fit it on paper.
> >   2) The pixel and eps images are equivalent, and the various
> >      scaling/clipping/etc options are essential to the `correct
> > presentation'.
> > [and both cases could be present in the same document!]
> > Case 1 is what I've implemented: _ignore_ any/all options and reuse the
> > existing pixel image.
> Even with this, you may want to apply a scaling or rotation
> that is different from what was specified for paper.

Not as I intended the `as is' case, since the author asserted that the
pixel image
is exactly what is wanted.  This also applies to an example you cited
further down
(now elided): If the author asserts that the pixel images can be used
as-is, then
if the same eps image is used twice w/diff options,  they'll both get
by the same pixel image.

However, in general you're right. In fact,  even w/o considering the
image:  You might want to transform the eps file into a gif differently
you would transform the eps file onto paper.

> So it would be better to have a new macro, say \htmlgraphics{...}
> to pass the ALT text, and other graphics options.  It would be
> processed similarly to \htmlimage, but within a different context.

Hmm, maybe you've got it! An \htmlgraphics{options..} that precedes (or
an \includegraphics could do the following:
   * provide a set of options to replace the ones of the
     You'd want to distinguish the case 'none' (implying As Is)
     from the case of not overriding the options.
   * name an alternative file to use (presumably a prepared pixel image)
   * provide the alt text.
And if you can supply global default values for the options (including
you'd handle a lot of simple situations w/o requiring
\htmlgraphics throughout the doc.

> Simplest is to have $GRAPHICX_IMAGE_MODE defaulting to the
> behaviour of case '????'.
> If an image exists in  \l2hgraphicspath  then use it.

Actually, it sounds like it's not really necessary with the above
It still might be a more concise alternative. Maybe calling it
would be more consistent.

Does the following logic sound right:
possibly preceded by
   \htmlgraphics[html_options][html_file]{alt text}
where html_options could be '', 'none' or 'width=....',
and html_file could be ''.
(if there is no preceding \htmlgraphics, all three are '')
Set of $HTML_GRAPHICS_OPTIONS = '' or 'none' or 'width=....'.
(and probably some \htmlgraphicsglobal...)

So now do_cmd_includegraphics will consider
  $file = $html_file || $ltx_file
If we find $file (in pixel format) in htmlgraphicspath, use it as-is. 
Otherwise, the options to be used will be:
  $options = $html_options || $HTML_GRAPHICS_OPTIONS || $ltx_options
If we can't (yet) handle $options, punt to LaTeX.
Otherwise, look for a pixel format $file in graphicspath. 
If found, use it by applying $options to it.
Else, punt to LaTeX.

Am I missing anything important?  Is this explainable to a user?
[Ask me tommorrow what it was I said!]

> So far as I've been able to tell, layers were a Netscape-only thing.
> Certainly they are not in any HTML spec.
> Indeed, haven't they been dropped from Netscape 6 ?

I believe so, but I thought they were followed by something similar
(in DOM, or ecmascript or _someplace_...)  
I forgot what it is, but whatever it was, I dont wanna go there! :>

Bruce Miller
<bruce.miller@nist.gov>  http://math.nist.gov/~BMiller/