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

[Ross Moore]

Hi Daniel,

On 04/04/2005, at 9:16 AM, Daniel Clemente wrote:

>    Hi,
>
>
>  dillo:
>
>> 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 ?
>
>    They are designed to be fast and efficient. I suppose that it's ok
> if they drop all the styling attributes and CSS rules... They give
> access only to the content of the pages, and are very good tools to
> check the accessibility of web pages. For example, Dillo has a "bug
> meter" which detects HTML errors. So they can be useful.

Fine; so it's mainly for checking accessibility and validity,
rather than giving a beautiful layout of the HTML pages.
It's more of a web-designer's tool than a surfer's browser.
Thus there's no reason why we should worry about what it does
  --- unless it reveals real errors in the HTML that LaTeX2HTML
produces.


>>>    So this would require a different value for each image; this is
>>> useless.
>>
>>  ... well, not really.
>>
>> Here are some examples where this is done:
>>
>>   
>> http://www-texdev.ics.mq.edu.au/LWC/MATHexamples/sampleMath-40styled/
>>
>>   http://www.maths.mq.edu.au/texdev/MATHS/MATH123/W6-2K5/Questions/
>>
>> 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.
>>
>
>    The first one hasn't got any CSS rule for that,

What I meant was:  there are <IMG..>s which have the
  ALIGN="MIDDLE"  attribute, for which there is a CSS rule
to match, based upon the  ID=...  attribute.

Not every such IMG has a rule, just 2 or 3 of them where
I was experimenting by hand.


> and the second, a
> different rule for each image (tagged with ID), which requires
> updating the CSS on each run and would be slow and hard to do.

Updating the CSS, yes; but that's not really slow.
The necessary information is available, and accessible
to LaTeX2HTML at the time the <IMG> tags are written out.
It just needs a bit of extra parsing to find the HEIGHT attribute,
add the ID attribute and store the half-height to be later written
into the CSS, as a rule associated to the ID.

In my 2nd example above, the ID was associated with the name of the 
file,
and the rules were generated at the time the image was generated.
This is actually wrong, as file-names of images can change as the
document is edited for changed content.
This means that to get the CSS rules right, all images need to be
remade, at least for the final run --- *that* certainly takes time.


I'm currently working on generating the CSS rules much later,
using (unique) IDs that LaTeX2HTML maintains internally anyway.
This meshes with the image-caching strategy, and doesn't make
any significant effect to the time taken by LaTeX2HTML
to process the document.

You can see an example of this at:

     http://www.maths.mq.edu.au/texdev/MATHS/MATH123/W6-2K5/Qtest/

which can be compared with the 2nd example from above.

As for how long it takes a browser to draw the resulting pages 
on-screen,
I don't believe that the extra CSS rules would affect this unduly.



>    But I think there's no general rule to say "lower each image by
> half its overall height"...

No; there is not.
But that's not what I said about the example pages.


>> 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.
>>
>
>    For objects inside tables, I haven't seen any extra problems. For
> aligned equations, for example, there are only equations inside the
> table (no HTML text), so they stay aligned in the middle.

In the example:
     http://www.maths.mq.edu.au/texdev/MATHS/MATH123/W6-2K5/Qtest/
the inline-math of most of the Questions is actually set within
<TABLE> tagging.
Cells containing numbering (i), (ii), ... are not aligned correctly
with the mathematics in adjoining cells --- e.g., the fractions.

Under both Safari and FireFox it looks like the middle of the
math-images (including padding) are aligned with the middle of
the numbering.

>    And vertical-align has a different meaning when it is applied to
> table cells: "middle" aligns the center of the cell with the center of
> the row, and percentages or relative positions are not considered in
> the standard.

It's the case of having text in one cell and images in adjacent cell(s)
that I'm worried about.
It should be possible to get the baselines to align, with a resulting
appearance of alignment, just as in the case of inline-math.

If you could do some experimentation, by editing the CSS and/or
the HTML source, to find out how to achieve the desired alignment,
then I'd be glad to program it into LaTeX2HTML.

There needs to be a 2005 release, in which many changes will be
included, arising from bug reports over the past couple of years.


>
>
>> Surely Amaya handles CSS correctly, so no problem here.
>
>   Hah! Amaya is probably the browser with most CSS bugs... :-) It's
> experimental, but it still lacks important CSS properties (position,
> alignment ones, etc).  Also I hope that they make it more stable in
> next versions.

OK; but then again it's not what many people would be using to view
web-pages created by LaTeX2HTML, for the sake of reading the content
of the pages. Again more of a programmer/developer tool.


>   I will post any new information; if
> https://bugzilla.mozilla.org/show_bug.cgi?id=192077 is solved then we
> will have fewer problems.

With the CSS specs the way they are, I have no confidence that this
bug will ever be fixed.
Even if it is for Mozilla/Firefox, etc., then there is still a problem
when using IE. That is unlikely to change, so a CSS solution is still
needed.


>
>    Thanks,
>
>    Daniel

Thank you for the motivation to revisit this old issue.


As for the other  $within_preamble  problem, affecting Lyx-generated
LaTeX coding, please ignore my previous comments on this.
On re-examining my proposed solution, it does indeed seem to be
quite robust, and worthy of inclusion without change.

My recent doubts were due to the way the term 'segment' is used within
the LaTeX2HTML coding using Perl. There are 3 separate places where
this word is used. Each case refers to a different strategy for breaking
a large document into separate pieces, for speed/memory considerations.
I was getting two of these mixed up.


All the best,

	Ross


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