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: e.g. P { line-height : 18pt }
This is described in an example in the LaTeX Web Companion. The effect can be seen here:
http://www-texdev.ics.mq.edu.au/LWC/sampleMath-40styled/
compared with:
http://www-texdev.ics.mq.edu.au/LWC/sampleMath-default/
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 middle
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:
\documentclass{....}... some preamble stuff ...
\input myheaders.tex
... other preamble stuff
\begin{document}
...
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
------------------------------------------------------------------------ Ross Moore [EMAIL PROTECTED] Mathematics Department office: E7A-419 Macquarie University tel: +61 +2 9850 8955 Sydney, Australia fax: +61 +2 9850 8114 ------------------------------------------------------------------------
_______________________________________________ latex2html mailing list [email protected] http://tug.org/mailman/listinfo/latex2html
