[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
replaced
by the same pixel image.
However, in general you're right. In fact, even w/o considering the
pixel
image: You might want to transform the eps file into a gif differently
than
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
wraps)
an \includegraphics could do the following:
* provide a set of options to replace the ones of the
\includegraphics.
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
'none'),
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
approach.
It still might be a more concise alternative. Maybe calling it
\htmlgraphicspath
would be more consistent.
Does the following logic sound right:
Given:
\includegraphics[ltx_options]{ltx_file}
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/