Problem in auto-generated HTML

Jack Crenshaw wrote:

Jonathan N. Little wrote:
Jack Crenshaw wrote:
I've encountered a problem with HTML files generated by Mathcad using
the "save as HTML" option. Among other things, Mathcad allows for
text, math, and graph objects. When I try to display the generated
file in Firefox, the equations overlay the preceding text.

Also not mentioned is that "style" properties created by this Mathcad
are invalid as well


The problem seems to be the use of constructs like this:

div style="position:absolute;top:96;left:20"
^^ ^^
Position 96 what? Bananas? Left what?

Pixels. Which right off the bat seems like a Bad Idea, right?

NOT pixels. This is a absolutely crucial point: with CSS, the units
*must* be specified unless the value is zero, and if the units are
omitted with a non-zero value, the CSS is invalid, and should (according
to the standards) be ignored.

The problem is that IE traditionally does NOT ignore such CSS:
traditionally IE has assumed that the units are pixels if the units are
not specified, but this is simply wrong, and has resulted in IE
*apparently* displaying pages correctly when standards compliant
browsers do not.

The bottom line here is that MathCAD is apparently emitting seriously
defective code: code that will, in reality, appear to work only with
old versions of IE, or with modern versions of IE when quirks mode is
enabled.

You have every right to go back to MathCAD and to give them hell for
being so incompetent that it emits such terrible, defective code.

In article <4A46DEEE.8010207 (AT) earthlink (DOT) net>,
Jack Crenshaw <jcrens (AT) earthlink (DOT) net> wrote:

Jukka K. Korpela wrote:

(I'd like to trim followups, as crossposting to three groups is seldom a
good idea. However, as usual in crossposted threads, _none_ of the
groups is the right one...)

Sigh. What would we do without etiquette police?

Let me guess: you and many others would run riot and be unetiqual.

--
dorayme

F'up set to comp.infosystems.www.authoring.html

On Sat, 27 Jun 2009 16:19:50 -0400, Jack Crenshaw wrote:

C A Upsdell wrote:
Jack Crenshaw wrote:
I've encountered a problem with HTML files generated by Mathcad using
the "save as HTML" option. Among other things, Mathcad allows for
text, math, and graph objects. When I try to display the generated
file in Firefox, the equations overlay the preceding text.

The problem seems to be the use of constructs like this:

div style="position:absolute;top:96;left:20"
layer
img src="./Test File_images/IMG0003_62826203.PNG" border="0"/
/layer
/div

It's the absolute address that seems to be the problem.

Do you mean that the img you've mentioned is the "equations," or "the
preceding text?" Is it overlapping by 20px? Where's the URL? Etc.

And I wouldn't call that an absolute address. Hmm, but see my comment at
the end about nomenclature.

I'd appreciate
comments and suggestions for a way to fix the problem. For example,
why not just substitute <p>...</p> blocks for the div sections?

For reasons I don't understand, Firefox and IE8 render the page
differently.

I don't fully understand it either, because you haven't provided a sample
page. My bet is on the missing units, as mentioned by Jonathan, but it
could be other things, or some combination thereof.

....

A second aspect is that the absolute block should be inside another
block that is positioned, e.g. using position:relative. The code you
cite does not indicate such an outer block exists.

Well, it's not. The hierarchy is

html/body/div/span/layer

The absolute addresses are inside the <span> tag, as I showed.

Actually, you've shown that there *isn't* a span element. (I know you meant
"element" even though you said "tag.")

And the
addresses really do seem to be absolute, not relative. As I progress
through the file, the top address continues to increase monotonically.

After spending some time studying your posts and replies, I now think
there's a bit of a nomenclature problem. You keep talking about "absolute
addresses" as opposed to "relative addresses." Such terms seem to me to
have to do with URIs, like your "./Test File_images/IMG0003_62826203.PNG"
in the pasted code snipplet above. (That'd be a relative address, AFAIAC,
since it's relative to whatever domain the page is in.)

The *addresses* are however different from *positioning*, which Mr. Upsdell
is trying to point you to. The div you've shown us is claiming to be
absolutely positioned (you've declared position:absolute; inline), but as
Brother Upsdell says, that'll only have an effect if the absolutely
positioned block is inside a relatively positioned block. Based on your
statements about hierarchy, that'd mean you want to declare

body {position:relative;}

in the CSS.

Does any of that help?

--
John

On 2009-06-28, C A Upsdell <cupsdell (AT) nospam (DOT) not> wrote:

Jack Crenshaw wrote:
Jonathan N. Little wrote:
Jack Crenshaw wrote:
I've encountered a problem with HTML files generated by Mathcad using
the "save as HTML" option. Among other things, Mathcad allows for
text, math, and graph objects. When I try to display the generated
file in Firefox, the equations overlay the preceding text.

Also not mentioned is that "style" properties created by this Mathcad
are invalid as well


The problem seems to be the use of constructs like this:

div style="position:absolute;top:96;left:20"
^^ ^^
Position 96 what? Bananas? Left what?

Pixels. Which right off the bat seems like a Bad Idea, right?

NOT pixels. This is a absolutely crucial point: with CSS, the units
*must* be specified unless the value is zero, and if the units are
omitted with a non-zero value, the CSS is invalid, and should (according
to the standards) be ignored.

The problem is that IE traditionally does NOT ignore such CSS:
traditionally IE has assumed that the units are pixels if the units are
not specified, but this is simply wrong, and has resulted in IE
*apparently* displaying pages correctly when standards compliant
browsers do not.

I think they mostly allow that to mean pixels in quirks mode, which my
guess is this content is going to be in (if you're clueless enough to
emit crap like that you probably don't emit a DOCTYPE at all).

So although it's wrong, my money is on it not being the cause of the
problem here.

On 2009-06-28, John Hosking <john-nin2 (AT) bluemail (DOT) ch> wrote:
[...]

The *addresses* are however different from *positioning*, which Mr. Upsdell
is trying to point you to. The div you've shown us is claiming to be
absolutely positioned (you've declared position:absolute; inline), but as
Brother Upsdell says, that'll only have an effect if the absolutely
positioned block is inside a relatively positioned block.

It will have an effect, just the wrong effect. If there are no
positioned ancestors, they'll be positioned relative to the viewport.

Based on your
statements about hierarchy, that'd mean you want to declare

body {position:relative;}

in the CSS.

That will move things by about 8px usually (body has 8px margins, and
these things are positioned with top and left).

But this containing block thing could well be the problem. Firefox for
example doesn't allow table cells to be containing blocks for positioned
descendents.

We're guessing though without a URL.

Jack Crenshaw wrote:

Sigh. What would we do without etiquette police?

We could surely do without a [censored] who fullquotes and then adds an
AOL-class one-liner pointless stupidity, and both posts and emails without
saying that.

F'ups set.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

On 27 June, 16:41, Jack Crenshaw <jcr... (AT) earthlink (DOT) net> wrote:

I've encountered a problem with HTML files generated by Mathcad using
the "save as HTML" option.

The problem seems to be the use of constructs like this:

div *style="position:absolute;top:96;left:20"
layer
img src="./Test File_images/IMG0003_62826203.PNG" border="0"/
/layer
/div

I've got a similar problem, although with Jasper Reports and BIRT,
rather than MathCAD. Our fix is to post-process with XSLT, stripping
out all the cruft (style attributes, dodgy markup elements) and also
to add some auto-generated class names. Simple static CSS can then
present the page in a reasonable manner. This page is incidentally far
simpler afterwards, and a much more fluid layout.

John Hosking wrote:

F'up set to comp.infosystems.www.authoring.html

On Sat, 27 Jun 2009 16:19:50 -0400, Jack Crenshaw wrote:

C A Upsdell wrote:
Jack Crenshaw wrote:
I've encountered a problem with HTML files generated by Mathcad using
the "save as HTML" option. Among other things, Mathcad allows for
text, math, and graph objects. When I try to display the generated
file in Firefox, the equations overlay the preceding text.

The problem seems to be the use of constructs like this:

div style="position:absolute;top:96;left:20"
layer
img src="./Test File_images/IMG0003_62826203.PNG" border="0"/
/layer
/div

It's the absolute address that seems to be the problem.

Do you mean that the img you've mentioned is the "equations," or "the
preceding text?"

Ok, I'll try to get the nomenclature right. Mathcad files typically
contain text and equations, mixed. When you do a "Save As" an HTML file,
Mathcad saves the equations as either jpeg or (the default) png files.
They're not img files.


Is it overlapping by 20px?

Hard to say, but that seems about right. I don't think that's relevant,
however. The 20px mentioned in the example <div> tag is the horizontal,
not vertical, positioning. The error is in the vertical.

Where's the URL? Etc.

No URL. The file is not on the web, it's on my disk.

And I wouldn't call that an absolute address. Hmm, but see my comment at
the end about nomenclature.

Yeah, Ok. It's a position, if you prefer, apparently measured from the
top left corner, in pixels.

I'd appreciate
comments and suggestions for a way to fix the problem. For example,
why not just substitute <p>...</p> blocks for the div sections?

For reasons I don't understand, Firefox and IE8 render the page
differently.

I don't fully understand it either, because you haven't provided a sample
page. My bet is on the missing units, as mentioned by Jonathan, but it
could be other things, or some combination thereof.

I doubt you really want the sample page. It's very long -- the vertical
positions go on to over 10,000 px. I thought I was showing the relevant
code.

A second aspect is that the absolute block should be inside another
block that is positioned, e.g. using position:relative. The code you
cite does not indicate such an outer block exists.
Well, it's not. The hierarchy is

html/body/div/span/layer

The absolute addresses are inside the <span> tag, as I showed.

Actually, you've shown that there *isn't* a span element. (I know you meant
"element" even though you said "tag.")

Pardon me. I'm new to HTML-speak, though old to everything else. In a
programming language I'd say "if-block" or "while-block." I would NOT
normally use "element" to refer to a block of code, but whatever helps
the communication channel works for me.

And the
addresses really do seem to be absolute, not relative. As I progress
through the file, the top address continues to increase monotonically.

After spending some time studying your posts and replies, I now think
there's a bit of a nomenclature problem. You keep talking about "absolute
addresses" as opposed to "relative addresses." Such terms seem to me to
have to do with URIs, like your "./Test File_images/IMG0003_62826203.PNG"
in the pasted code snipplet above. (That'd be a relative address, AFAIAC,
since it's relative to whatever domain the page is in.)

But since the "top" positions seem to increase monotonically through the
entire file, I'm persuaded that they really mean absolute position,
measured from the top left of the page.

The *addresses* are however different from *positioning*, which Mr. Upsdell
is trying to point you to. The div you've shown us is claiming to be
absolutely positioned (you've declared position:absolute; inline), but as
Brother Upsdell says, that'll only have an effect if the absolutely
positioned block is inside a relatively positioned block. Based on your
statements about hierarchy, that'd mean you want to declare

body {position:relative;}

in the CSS.

Does any of that help?

Yeah, it does, but I'm not sure this is worth pursuing any further. This
"save as" feature seems to be hopelessly broken or, in plain English,
fubarred.

Yesterday I upgraded from version 13.0 to 13.1, in hopes that they'd
fixed the problems. Now the files aren't readable at all <!> Reason
seems to be, now they're writing them in Unicode. Sigh.

Jack

C A Upsdell wrote:

Jack Crenshaw wrote:
Jonathan N. Little wrote:
Jack Crenshaw wrote:
I've encountered a problem with HTML files generated by Mathcad
using the "save as HTML" option. Among other things, Mathcad allows
for text, math, and graph objects. When I try to display the
generated file in Firefox, the equations overlay the preceding text.

Also not mentioned is that "style" properties created by this Mathcad
are invalid as well


The problem seems to be the use of constructs like this:

div style="position:absolute;top:96;left:20"
^^ ^^
Position 96 what? Bananas? Left what?

Pixels. Which right off the bat seems like a Bad Idea, right?

NOT pixels. This is a absolutely crucial point: with CSS, the units
*must* be specified unless the value is zero, and if the units are
omitted with a non-zero value, the CSS is invalid, and should (according
to the standards) be ignored.

Ok, I get that the units are always supposed to be specified. But
they're not. What more can I say?

The problem is that IE traditionally does NOT ignore such CSS:
traditionally IE has assumed that the units are pixels if the units are
not specified, but this is simply wrong, and has resulted in IE
*apparently* displaying pages correctly when standards compliant
browsers do not.

Ok, that explains things a _LITTLE_ bit. Looking at the rendered page,
it seems that the degree of overlap in Firefox is about half-an-image
vertical. This would make sense if Firefox is ignoring the positioning,
as you say, but IE is interpreting it as pixels.

In other words, Firefox is putting the _CENTER_ of the equation/picture
right after the text, but the equation is too tall and so overlaps. Does
that make sense?

Only problem with that theory is, the horizontal positioning seems to be
working.

The bottom line here is that MathCAD is apparently emitting seriously
defective code: code that will, in reality, appear to work only with
old versions of IE, or with modern versions of IE when quirks mode is
enabled.

Yep, we certainly agree on that. My purpose in the original post was to
see if there was some easy edit I could make, to fix things. This now
seems hopeless, so I've given up on that idea, and am reduced to saving
the file as PDF.

You have every right to go back to MathCAD and to give them hell for
being so incompetent that it emits such terrible, defective code.

Smile. Don't get me started. I have screamed so much about Mathcad -- in
both print, email, and phone -- that they hate to see me coming. I hate
everything about Mathcad EXCEPT the lovely results that I can get.

Which is another way of saying, I feel about Mathcad the same way I feel
about Word, Excel, and Windows itself.

Thanks for all your advice, but I think the situation is hopeless, don't
you?

Jack

C A Upsdell wrote:

Jack Crenshaw wrote:
Jonathan N. Little wrote:
Jack Crenshaw wrote:
I've encountered a problem with HTML files generated by Mathcad
using the "save as HTML" option. Among other things, Mathcad allows
for text, math, and graph objects. When I try to display the
generated file in Firefox, the equations overlay the preceding text.

Also not mentioned is that "style" properties created by this Mathcad
are invalid as well


The problem seems to be the use of constructs like this:

div style="position:absolute;top:96;left:20"
^^ ^^
Position 96 what? Bananas? Left what?

Pixels. Which right off the bat seems like a Bad Idea, right?

NOT pixels. This is a absolutely crucial point: with CSS, the units
*must* be specified unless the value is zero, and if the units are
omitted with a non-zero value, the CSS is invalid, and should (according
to the standards) be ignored.

You know what? This problem seems to have resolved itself. Let me explain:

I have been use Mathcad version 13.0. Current version is now 14.0. The
file we've been talking about was generated with 13.0. When I had the
troubles, I updated to 13.1 (a free patch). That made things worse,
because the new file is in Unicode.

But a friend generated a test file in 14.0. _THAT_ file works. I can't
say that there are now no errors, but the positioning thing is fixed.
Now they specify units (pt) for all positions.

Reading between the lines, I'm betting that the 13.0 translation was
tested only in IE.

FWIW, I can post the zip file for my friend's test case. It might make
interesting reading if you like to work puzzles. But I now know what I
have to do: Upgrade to 14.0.

Also FWIW, I'll bet I could have just gone in and added the units to all
those <div> elements. Hindsight is 20/20.

I can't thank you enough for all your help, and your patience. Same
goes for all others who responded.

Jack