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

Bruce Miller bruce.miller@nist.gov
Wed, 25 Sep 2002 22:39:50 -0400

Ross Moore wrote:
> Hi Bruce,

Hi Ross!

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

Exactly!  Percentage sizes are very useful, but imho should be used
very intentionally; stretching a small image to a 1000 pixels ....

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

I just took another look at it, and it does rather specifically set
  $width=$height=0 when it fails to interpret the image, as if it
were expecting the caller to handle it.  OTOH, it isn't clear that
the callers are doing much special when the size comes back empty,
much less, reporting an error.

Does l2h use get_image_size speculatively? (ie. to see if there's
an image at all, and if so, what's it size?  You wouldn't want
messages coming from within get_image_size, then).

If not, I'll patch it up, and send it to you in a few days.
I don't know much about the image formats, but it's pretty clear
where things can fail.

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

You're just a hard-core TeXie! :>

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

Yeah; if Alex can't find any obvious reason why l2h couldn't peek into 
the file
maybe he can send it to me so I can look into it.

> Thanks for looking at this.

Somehow I feel responsible... after prodding you so long to put the stuff
in, since you were trying to avoid exactly this sort of stuff ... :>

> Cheers
> 	Ross