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

Ross Moore ross at ics.mq.edu.au
Sun Apr 3 01:52:27 CEST 2005

Hi Daniel,

On 03/04/2005, at 2:52 AM, Daniel Clemente wrote:

>    Hi,
>> 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'.
>    True... and computing the height of the tallest image in the
> document and making all images of the same height would only be worse.
> Some browsers can't don neither CSS nor HTML ALIGN and show all the
> padding, which can be messy. Example:
> http://www.danielclemente.com/linux/dillo-paddings.png

Well, I can't have any sympathy with a browser like that.
CSS technology has been the recommended way to handle styling
for years now, and HTML ALIGN has been around even longer.

Such a browser must have trouble displaying all sorts of web
content. What was it designed for ?

>> As for the "problem" of the padding beneath an image causing
>> lines to spread unduly, this is easily solved using a CSS rule:
>> e.g.
>>    P  { line-height : 18pt }
>    I have added it on my web. This should work for not very tall 
> images.


>   Well, that's the best I could achieve with CSS. I think CSS is the
> only way to solve the alignment issues in modern browsers

That's what I've said from the start ...

>> 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.
>   I think that writing them to a PNG works very well, better than
> MathML/CSS/SVG/Unicode at the moment.

I agree entirely.
Though there are some nice Math pages around that use the Symbol font.
Unfortunately that isn't rich enough for all of what can be done
with TeX, so would need a fall-back of images anyway.

>>       img[align="middle"] {vertical-align: middle -.5ex !important}
>    No, and {vertical-align: middle; vertical-align: -.5ex;} isn't
> accepted neither. Anyway, the middle of the line can be reached from
> the baseline with 0.5ex, I think, so this is not a problem.

Yep. In my testing, the 2nd specifier overrides the first.

>    So this would require a different value for each image; this is 
> useless.

  ... well, not really.

Here are some examples where this is done:



For these, have a look at the .css file that is used.
That has a rule for the images with ALIGN="MIDDLE" that
lowers the image by half it's overall height.

That places the intended baseline upon the baseline of the
surrounding text, at least for inline math images.

I'm not convinced that it does the right thing in tables;
e.g. for aligned equations.
Perhaps you could experiment a bit with that.

>> What do different browsers do with these rules?
>    Something similar to seeing the page with a CSS-disabled browser.
> Conclusions:
>  -Is it possible to always use "vertical-align: middle" with some
> images, adding only the required padding?
>  -HTML ALIGN="MIDDLE" is a very good solution. So it's easier to fix
> the browsers.

With a rule for each image, as in my examples above,
then the browser can do a good job if:

  a.   it uses the CSS rules;
  b.  it ignores CSS, but does the HTML according to the
      original recommendations.

If it does neither of those, then it must be either very
old and was always buggy --- so update it !
   the browser was designed for a special purpose, and LaTeX2HTML
pages with math images isn't part of that purpose.

>  -For Gecko, there's a patch, but someone has to check it in.
> Konqueror and Opera work well. IE might (I haven't tested it). Dillo,
> Links and Amaya don't support HTML ALIGN, so they will show all the
> padding of the images.

Surely Amaya handles CSS correctly, so no problem here.

>> 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.
>   Well, you explained the problem, see
> http://www.tug.org/pipermail/latex2html/2004-February/002640.html

Yep; just a quick fix to handle the specific problem in a fairly
robust way. I need to look at it again.

>   A testcase is this: http://www.danielclemente.com/linux/tabular.tex
>   Lyx generates similar files, with a command substitution which does
> not take place:
>   \providecommand{\tabularnewline}{\\}
>   I will try to look into this.


If I get some time today I'll have another look at these issues.



>   Thanks,
>   Daniel
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