[l2h] Workarounds for two bugs (equations with white margins, and more)

Ross Moore ross at ics.mq.edu.au
Mon Mar 28 01:53:02 CEST 2005

Hello Daniel,

On 28/03/2005, at 5:19 AM, Daniel Clemente wrote:

>    Hi,
>    I have studied more this case, and yes, it's a browser bug. For
> Mozilla it's bug 192077,
> https://bugzilla.mozilla.org/show_bug.cgi?id=192077
>    I think there are other solutions, which I have briefly analyzed:
> (there's a lot of information about the margins problem here):
>    http://www.danielclemente.com/linux/l2h.html

Thank you for looking into this, and writing-up your conclusions
so clearly...
>    I also have some proposal (also in the web), namely: Why not add
> padding to all images, as if they had a letter with a descendent?

  ... but this is not a satisfactory solution.

You are assuming that there is only one possible value for
the depth of an image, coming only from descenders on letters.
This is completely forgetting about things like fractions,
integral signs, summation operators and other mathematical
notations. Indeed simply adding a subscript can create a larger
depth than that of a letter such as 'y'.

As for the "problem" of the padding beneath an image causing
lines to spread unduly, this is easily solved using a CSS rule:
    P  { line-height : 18pt }

This is described in an example in the LaTeX Web Companion.
The effect can be seen here:


compared with:


Of course it is better to use a scaleable value, based on
the x-height rather than a constant.

Now let's discuss these, from your webpage:

>>   img[align="bottom"] { vertical-align: baseline !important; }
>>   img[align="middle"] { vertical-align: middle !important; }
>> 	• 	The first line says that an equation which doesn't have 
>> descendent should align its baseline with the baseline of the parent 
>> box, according to the CSS specification. And it works. The !important 
>> is really important; it's to assure that the HTML value gets 
>> overridden.

Isn't this the default behaviour anyway,
when there is no descender, depth or padding ?

Which browsers get this wrong, if any ?

>>   img[align="middle"] { vertical-align: middle !important; }
>> 	• 	The second one says that equations which have descendents (these 
>> were our problem) should have their vertical midpoint aligned with [ 
>> the baseline of the parent box plus half the x-height of the parent 
>> ]. This happens to work very well in all browsers, even for big 
>> fonts.

Isn't this what the "bad" browsers do currently ?
So now you are making those that currently "get it right" to change
behaviour to match those that do it incorrectly.

For this to work properly, the images must be prepared with less padding
than at present; i.e. removing the amount of x-height, so that the 
appears to be raised by .5 x-height within the contents of the image.

Unfortunately, this is not practical, since the x-height is a variable
that the user can set when choosing the font-size to view the webpages.

One possible solution is to have a CSS rule that fixes the font-size,
and image calculations then use this value, assuming that the CSS rules
will apply when the page is viewed.
Of course this now removes the user's convenience of selecting an
appropriate font-size to view the HTML pages.

Another possibility is to scale images in the browser when the font-size
changes. This can be done with CSS rules, but the scaling really
upsets the bitmapped images. They are not vector-graphics.
We would need to be using SVG format to have this work OK.
But conversion of TeX output to SVG is really hard, and would require
subsetting fonts for inclusion. That's really not practical at present.
Besides, PDF is a much better format for this anyway.

>    Well, thanks for your time and for guiding us into the problem.

You're welcome.

BTW, did you experiment with the rule:

         img[align="middle"] {vertical-align: -.5ex}

This ought to mean "lower the image by 1ex from where you would
otherwise put it", namely using 'middle' alignment.

Or maybe it needs to be one of:

       img[align="middle"] {vertical-align: middle -.5ex}
       img[align="middle"] {vertical-align: middle -.5ex !important}

What do different browsers do with these rules?

>    BTW, what about the first bug?
> http://www.danielclemente.com/linux/l2h.html#within_preamble

You mean this ?

>>   +          # added by DCL (patch from Ross Moore).
>>   +         # See 
>> http://www.tug.org/pipermail/latex2html/2004-February/002640.html
>>   +         #
>>   +         # after the first segment we should no longer be in the 
>> preamble.
>>   +         $within_preamble = 0;

That comment about "should no longer be in the preamble" may be
appropriate for your situation, but cannot be assumed to be true
in general.

It will not be true for any job structured as follows:


  ... some preamble stuff ...

  \input myheaders.tex

  ... other preamble stuff


There will be segment boundaries before and after the
contents of   myheaders.tex  .

So I need to understand your situation better and devise
a robust fix that will not break other people's documents,
before applying such a patch to the LaTeX2HTML repository.

>    Daniel

Hope this helps,


Ross Moore                                         ross at maths.mq.edu.au
Mathematics Department                             office: E7A-419
Macquarie University                               tel: +61 +2 9850 8955
Sydney, Australia                                  fax: +61 +2 9850 8114

More information about the latex2html mailing list