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 [email protected] http://tug.org/mailman/listinfo/latex2html
------------------------------------------------------------------------ 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
