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
_______________________________________________
latex2html mailing list
[EMAIL PROTECTED]
http://tug.org/mailman/listinfo/latex2html
