[l2h] Width & Height of GIF images creating problems with IE

[Ross Moore]

Hi Bruce,

> Alex W Twisleton-Wykeham-Fiennes wrote:
> [...]
> > \includegraphics[  width=0.75\columnwidth,
> >   keepaspectratio]{zones.gif}
> > 
> > the file zones.gif is in the same directory as the .tex file.
> 
> 
> Hmm, worked for me. I rechecked after installing 2002-2 to make
> sure, and it still works [*].
> 
> BTW: it wont actually recognize things like \columnwidth
> I was already going out on a limb enough, interpretting points, etc,
>   but what columnwidth would be appropriate for a user's browser?
>   Would you want/expect width="75%" here ?  Is that worth a couple
>   of special cases, Ross ?

Not at all clear.
The biggest problem is that sizes appropriate to a printed version
need not translate easily to something suitable for on-screen viewing.
 
> At any rate, in your example, the current code would treat the `requested
> size' as 0x0, so should default to the image's natural size.
> It looks as if it didn't succeed in getting the size.
> Running with --verbosity=2 should print out something like:
>    Reuse somewhere/zones.gif scaled to www x hhh
> and I guess in your case, www and hhh are probably ''
> 
> >>To have no width or height should mean that LaTeX2HTML was unable to find
> >>the image and read the beginning of the file to determine these values.
> >>This failure should have resulted in a message to the screen log.
> 
> Should have, but get_image_size doesn't actually bother although it 
> would be
> a handy enhancement :> As it stands, it'll return effectively 0x0.

> Hmm, neither the original in l2h, nor the modified one in getimagesize.perl,
> prints any messages if the file can't be opened.  In fact, it doesn't
> complain if it can't interpret the file, either --- only if it doesn't
> recognize the type.  We should do something here....

Yes; we should.

> --- incidentally, that latter version could probably be swapped into the
> main program safely to avoid having to patch in 2 places
> although it would be a handy enhancement :>

Agreed.
 
> >>Finding the images during processing would depend upon knowing exactly
> >>where they are in the file-system, at the time when LaTeX2HTML runs.
> >>The name ./<name>  suggests in the same directory as the HTML files,
> >>but that location is usually created on-the-fly, so is not a normal place
> >>to find pre-existing graphics.
> 
> Actually, that's the normal form that graphics-support would use when it
> copies the file into the destination directory.

Since I use \htmladdimg more than \includegraphics for pre-existing images,
I wasn't sure about this.
 
> > The graphics in question are in the same directory as the source file.  
> > latex2html must find the images because it succeeds in copying them into the 
> > generated html directory (giving a correct path of "./zones.gif" inside the 
> > generated html).
> 
> Must have `found' it, and apparently had permission to read it, but
> apparently it didn't _understand_ it!

Yes; so it seems.
Maybe there's a variant of GIF that we haven't programmed for ?
In any case, some checking should be added to LaTeX2HTML, so that
bad attributes are not produced. 


Thanks for looking at this.

Cheers

	Ross