[l2h] graphicx.perl

[Ross Moore]

> "Ulrich G. Wortmann" wrote:
> > ...   what about having a
> > modification to graphicspath called \l2hgraphicspath.
> 
> That sounds like it might be part of the solution...
 
> Hi Uli, Ross; 
> Your comments, and Ross' offline got me thinking that although the
> basic idea is good, a bit more is needed to do it robustly.
> 
> First, the Easy stuff:
>  1) Once it's sorted out, we can handle graphics as well as graphicx.
>  2) The way I coded it, we'll ultimately need get_image_size to support
> jpegs.
>     I've patched it, but I borrowed a code snippet to extract jpeg sizes
>     -- I'd like to ask permission from the author before submitting it,
>      unless we've already got such code in-house?

That would be useful more generally.

Then we could have:  
   \htmladdimg[width=50\%, height=50\%]{......}
and have LaTeX2HTML calculate the actual sizes.
Currently the width and height need to be pre-calculated
and included in the source.


>  3) The code has two general purpose subs find_file & maybe_copy_image
> that 
>     are perhaps a bit too `Unixy' for general consumption. 
>     OTOH, they are reasonable candidates for general use in l2h, perhaps
> even
>     part of L2hos?  A feature I'm fond of is that the copy only gets
> done if the
>     src file is newer, and it preserves timestamps.

Yes, this probably should be in  L2Hos.
Alternatively, can it be inherited from a standard Perl module ?


> As for the ALT attribute:
>   Ross was suggesting a way of using \htmlimage to pass the info.
>   This is probably necessary for some cases, but my general philosophy
> of l2h 
>   is to extract as much from `standard latex markup' as possible.
>   Would it be feasable, at least in figure env, to infer which \caption
>   applies and use that text for the alt?

Feasible, but not not desirable, IMHO.
The main purpose of the ALT text is for screen-readers, used by
the visually impaired. It doesn't help to have the same material
as in the \caption to be repeated as ALT text.

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.")

The ALT tag adds meaning that is *not* already in the LaTeX source.
It should be used to convey meaning that a normally-sighted person
does not need to have spelled-out in words --- but the visually-impaired
person does need this extra info.
Thus it is most appropriate to use a mechanism such as \htmlimage ,
which is completely ignored by normal LaTeX processing.




> Now for the harder stuff;
>   I read more carefully through \includegraphics' options and tried to
> imagine the scenarios.  It really simplifies to just two cases of
> `Authors intent' (assuming both types of images are found):
> 
>   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.
Thus you'll need something like the \htmlimage mechanism for this,
else conditional code, using \htmladdimg[<options>]{...}.

 
> Case 2: If the options can be handled [*], we'd generate a 
> modified <IMG> tag and/or a modified image. Otherwise, fall back to
> LaTeX.
> Of course, an author may also want to forbid us from even trying.

The "forbid" will require existence of a new macro to say this.
I don't think that the alternative, of new options for \includegraphics
to say ignore other options, is at all feasible.

So if you are going to use a new macro anyway, then surely it is
best to have it give "all" the effects that you want in HTML,
rather than just some of them, and instructions to ignore things.


BTW, I just realised that using \htmlimage is probably not best at all.
This is because the surrounding {figure} environment may have already
detected it, and removed it from further processing.

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.



 
> So, how does the author express his/her intent?
> Maybe something like:
>      perl               latex
>   @GRAPHICS_PATH    \graphicspath    : where to look for images.
>   @LTHGRAPHICS_PATH \lthgraphicspath : where to look for `as-is' images.

Suppose the LaTeX document has the same image, but with different
sets of options to  \includegraphics .
There are 2 "as-is" .jpg files pre-prepared for this.
Clearly these 2 JPEGs have different names, but how are those names
to be deduced from the LaTeX source code, where \includegraphics
allows only one filename ?

Surely using conditional code is the easiest way to cope.


>   $GRAPHICX_IMAGE_MODE 
>       'latex' : always pass to latex.
>       'asis'  : use them as-is (case 1) search in both paths.
>       '????'  : images in graphicspath are treated as case 2
>                        in l2hgraphicspath are treated as case 1
> 
> Perhaps that covers most cases, but it's as clear as mud!
> Any better suggestions?

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

When that is not appropriate (e.g. a .jpg has the right name,
but is not the correct image) then conditional code
(with \htmladdimg) "must" be written into the LaTeX source.


The other $GRAPHICX_IMAGE_MODE values can be available;
but I doubt that they'll ever get much use --- prove me wrong ;-).




> ---------
> [*] A note on handling the options:  
>    Some are simple (eg. scale,width,height).  Others are not doable w/o 
> transforming the image itself (eg. clip, rotate).  And, since the
> options 
> are essentially transformation operations, you've got to handle the 
> entire sequence of options, in order, if you handle any.
> Worse, some options can't reasonably be simulated in HTML whether we do
> it
> in perl, or pass to latex.  For example, setting the bounding boxes,
> w/o clipping can cause the image to overlap neighboring text (unless we
> go
> to layers... ugh)

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 ?


> My inclination would be to decline handling any options in version 1,
> or at most handle cases where only the trivial ones are used, and leave
> it to a pbm wiz to implement the extra operations later.

:-)



Cheers,

	Ross

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