Unicode subscripts not displaying correctly

N

Norman Swartz

I dislike using <sub></sub> in HTML: it affects the line-spacing. I
prefer to use small Unicode characters (viz. "₀" through "₉")
for numerals, "0"-"9". These Unicodes leave the line-spacing unaffected.

These Unicodes display correctly in Firefox 3.6.13 and in Safari 5.0.3.
But they do not display correctly in Internet Explorer IE 8.0.76… In IE,
the browser inserts a blankspace immediately following each of these
characters.

Here is a sample of the problematic HTML code:

if the new law were not <tt>f</tt><b>₁</b>

The style command for "tt" is:
tt
{margin-top:0in;
margin-right:0in;
margin-bottom:10.0pt;
margin-left:0.0in;
line-height:115%;
font-size:11.0pt;
font-family:'Times', serif;
font-style:italic;}

The Doctype is:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

And the content-type is:

<meta http-equiv=content-type content="text/html;
charset=utf-8" />

How can I get IE to display the Unicode characters without the unwanted
whitespace?

Thanks.
Norman Swartz <[email protected]>
 
J

Jukka K. Korpela

Norman said:
I dislike using <sub></sub> in HTML: it affects the line-spacing.
Click to expand...

Dorayme already pointed out that such issues can be handled with style
sheets.
I prefer to use small Unicode characters (viz. "₀" through
"₉") for numerals, "0"-"9". These Unicodes leave the
line-spacing unaffected.
Click to expand...

There is much to be said in favor of such an approach _if_ it is feasible.
On the web, it is not feasible. Using subscript (or superscript) characters
is typographically good, because they have been designed by a typographer to
match the over all design of the font, whereas <sub> (and <sup>) may indeed
mess up line-spacing (though there is usually cure for that) and position
the indices oddly (mostly curable too) and produce the digits in size and
stroke width that are not suitable (mostly not curable except via rewrite of
some rendering algorithms in browsers).

But it's not feasible, and the main reason is limited font support; see
http://www.fileformat.info/info/unicode/char/2081/fontsupport.htm
These Unicodes display correctly in Firefox 3.6.13 and in Safari
5.0.3. But they do not display correctly in Internet Explorer IE
8.0.76… In IE, the browser inserts a blankspace immediately
following each of these characters.
Click to expand...

Not on my desktop. But our mileages vary, and there are other problems. The
subscript looks more or less awful on IE with my basic settings, though
there is no "blankspace". Is there on your screen? Can you copy&paste the
text from IE window to see what characters it really contains?

When the subscript character is not present in the basic text font that the
browser is using (by its defaults, or by user settings, or by CSS provided
by the page author), then it tries to pick it up from another font. And
anything may happen then. For example, the substitute font might be some
special where the glyph contains spacing on the right (not probable, but
possible).

There is something extra odd in IE 8, since it seems to be unable to find
subscript 1 in the Palatino Linotype font: if I set the text font to that
and use ₁, the subscript is displayed in some sans-serif font, not
Palatino Linotype. Oh, it seems to have the same problem with Cambria. Maybe
IE does not correctly read the information in a font about its character
coverage?

This is just a small example of the phenomenon that special characters cause
special problems.
Here is a sample of the problematic HTML code:

if the new law were not <tt>f</tt><b>₁</b>
Click to expand...

There is nothing on the right of the subscript, so how can you see the
blankspace after it?
Why the grossly illocal <tt> element instead of the most apparent <i>?
Why <b>? In mathematical notations, bolding has a special meaning (different
meanings in different contexts) and should not be used for other purpose. I
can't imagine a situation where a subscript digit would properly appear in
bold. Besides, bolding causes extra problems, because e.g. Arial Unicode MS
(one of the rather few commonly used fonts that contain subscript digits)
does not exist as a bold version, so any bolding you might see is
"mechanical", algoritmic, and typographically wrong.
The style command for "tt" is:
tt
{margin-top:0in;
margin-right:0in;
margin-bottom:10.0pt;
margin-left:0.0in;
line-height:115%;
font-size:11.0pt;
font-family:'Times', serif;
font-style:italic;}
Click to expand...

How is that relevant? It looks odd, but why do you expect it to relate to
the subscript rendering at all?
The Doctype is:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Click to expand...

Calling the dark demons of Quirks Mode. Probably irrelevant to this topic,
but generally a bad move for any new page.
 
T

Tim Streater

The Doctype is:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Click to expand...

Calling the dark demons of Quirks Mode. Probably irrelevant to this topic,
but generally a bad move for any new page.[/QUOTE]

Are you asserting that this statement applies to all latest-version
browsers? Such as e.g. Safari 5.0.3 ?
 
J

Jukka K. Korpela

Tim said:
Are you asserting that this statement applies to all latest-version
browsers? Such as e.g. Safari 5.0.3 ?
Click to expand...

It applies to the majority of browsers, counted by number of users, and
that's quite sufficient a reason to avoid using such a doctype on new pages.
Unless you really, really know what you are doing, and most people using
such doctypes don't.

For the same reason, on _old_ pages that contain such a doctype, it should
_not_ be changed, unless you really, really etc.

The details of doctype sniffing are an ugly and quirky business and usually
not worth knowing. Just don't change old pages that work, and for new pages,
use a doctype _exactly_ as written in HTML Recommendations (or the HTML5
draft).
 
T

Tim Streater

"Jukka K. Korpela said:
It applies to the majority of browsers, counted by number of users, and
that's quite sufficient a reason to avoid using such a doctype on new pages.
Unless you really, really know what you are doing, and most people using
such doctypes don't.

For the same reason, on _old_ pages that contain such a doctype, it should
_not_ be changed, unless you really, really etc.

The details of doctype sniffing are an ugly and quirky business and usually
not worth knowing. Just don't change old pages that work, and for new pages,
use a doctype _exactly_ as written in HTML Recommendations (or the HTML5
draft).
Click to expand...

Thank you, I wasn't aware that Transitional allowed quirky behaviour.
When I posted, I was dealing with a long thin horizontal <div>, with a
tiny image (same height as div) in the middle. This was not quite
rendered properly in Safari 5.0.3 (image about 3 pixels too low),
whereas FF, iCab, Chrome, and Opera all rendered it correctly.

I noticed that using Transitional made it render correctly, but Strict
causes the error, so I deduce a bug in Safari. I've made the image be
the background for the <div> and its all OK now - and I can get rid of
the Transitional doctype. I expect to be submitting a bug report to
Apple.
 
C

C A Upsdell

Thank you, I wasn't aware that Transitional allowed quirky behaviour ...
Click to expand...
Transitional can trigger quirks mode, but it depends on the DOCTYPE.
Without the URL, it triggers quirks mode; with the URL, it triggers a
standards mode.
 
D

dorayme

Tim Streater said:
I was dealing with a long thin horizontal <div>, with a
tiny image (same height as div) in the middle. This was not quite
rendered properly in Safari 5.0.3 (image about 3 pixels too low),
whereas FF, iCab, Chrome, and Opera all rendered it correctly.

I noticed that using Transitional made it render correctly, but Strict
causes the error, so I deduce a bug in Safari.
Click to expand...

What makes you so sure it is an "error"?

It is unclear what it really means to say an image is same height
as div unless you nail it down by giving both the same height. An
image in the wild and untouched by author css is an *inline*
creature and is treated as a sort of letter, space being provided
for descenders etc. Inline images usually sit on the baseline of
text whether or not text is there). For more
consistent/author-controlable positioning of images, it is often
a good idea to display them as block.

About your interesting puzzle. Go to Safari 5.0.3 and preferences
and note or make sure the fonts are what you want. Do the same
for FF but make sure the settings are *the same as for Safari*.
The size of fonts affects inline images. You might find that the
rendering is then consistent between the two browsers with Strict
doctype.
 
T

Tim Streater

dorayme said:
What makes you so sure it is an "error"?
Click to expand...

Only that the other four browsers behaved in the way I expected.
It is unclear what it really means to say an image is same height
as div unless you nail it down by giving both the same height.
Click to expand...

I use JavaScript to set the height of the div to 7px. When I created the
image I set it to be 7px high and this is confirmed by Preview.
An image in the wild and untouched by author css is an *inline*
creature and is treated as a sort of letter, space being provided
for descenders etc. Inline images usually sit on the baseline of
text whether or not text is there). For more
consistent/author-controlable positioning of images, it is often
a good idea to display them as block.
Click to expand...

OK, thanks for that clarification. That may be why my avoidance
technique of moving the image be the div's background worked.
About your interesting puzzle. Go to Safari 5.0.3 and preferences
and note or make sure the fonts are what you want. Do the same
for FF but make sure the settings are *the same as for Safari*.
The size of fonts affects inline images. You might find that the
rendering is then consistent between the two browsers with Strict
doctype.
Click to expand...

Ah! Now then. In testing I reduced my page exhibiting the problem from
348 lines down to 32. I added some text there as a cheap way of moving
the div down the window and hence away from its top. I did notice that
Safari was using a different font from all the others for that text.
I'll go back and look at that aspect in my test example. If Safari was
making space for a larger font that could account for it.

Thanks. I always appreciate a pertinent clue.
 
D

dorayme

Tim Streater said:
Only that the other four browsers behaved in the way I expected.
Click to expand...

An understandable assumption. But treat with caution! Sophie
Tucker:

They say the French are naughty
They say the French are bad
They all declare that over there
The French are going mad.
They have a reputation of being very gay
I just got back from Paris, and I just want to say:

When they go parley-vee and parley-vou,
This for me, zat for you,
Fifty million Frenchmen can't be wrong.
When they go Ohh la la la la la la la
On the bully boulevard
Fifty million Frenchmen can't be wrong.

They shake-a the hand
They shake-a the feet
They roll ze eyes and qu'est-ce que c'est right on the street
Even though the Irish and the Dutch
Say it don't amount to much
Fifty million Frenchmen can't be wrong.


I use JavaScript to set the height of the div to 7px. When I created the
image I set it to be 7px high and this is confirmed by Preview.
Click to expand...

If you do set the height of the image and the div the same, that
leaves no room for descenders. The descender space for the text
(the bottom bit of the y) will be under the div and while the y
will generally show, the empty descender space below the image (a
'faux letter'!) will naturally be invisible.

To see more of what is going on, try with a bit of text in there:

<div style="height:100px; color: black; background:
yellow;">layout<img ... height="100"></div>

To see more clearly, enlarge the text. The bottom of the y in
layout will descend below the div, what is the poor thing to do?
The pic will jut out the div if it is *naturally* taller than
100px and you specify the natural height or leave out the height.

There are couple of things I have on this business:

<http://dorayme.netweaver.com.au/alt/inlinePicWithDescenderSpace.h
tml>

And there is a bit of discussion that might be helpful at:

<http://netweaver.com.au/floatHouse/page2.php>

Never mind that it is in the context of pages on floats, there is
some stuff about pure inline text (top of page) and images
(bottom of page) on page 2. There is a movie to help along, get
some chips and popcorn and a milkshake handy.
 
L

Lewis

In message said:
Are you asserting that this statement applies to all latest-version
browsers? Such as e.g. Safari 5.0.3 ?
Click to expand...

Transitional should not be used. Has nothing to do with the browser. It
was a DOCTYPE for moving from 3.2 to HTML4. When was that?

You should not be 'moving' to HTML4, so strict is the proper DOCTYPE for
all new content.
Click to expand...
 
T

Tim Streater

dorayme said:
An understandable assumption. But treat with caution! Sophie
Tucker:

They say the French are naughty
They say the French are bad
They all declare that over there
The French are going mad.
They have a reputation of being very gay
I just got back from Paris, and I just want to say:

When they go parley-vee and parley-vou,
This for me, zat for you,
Fifty million Frenchmen can't be wrong.
When they go Ohh la la la la la la la
On the bully boulevard
Fifty million Frenchmen can't be wrong.

They shake-a the hand
They shake-a the feet
They roll ze eyes and qu'est-ce que c'est right on the street
Even though the Irish and the Dutch
Say it don't amount to much
Fifty million Frenchmen can't be wrong.
Click to expand...

Oh no! You are spinoza1111 and ICM5P.
If you do set the height of the image and the div the same, that
leaves no room for descenders. The descender space for the text
(the bottom bit of the y) will be under the div and while the y
will generally show, the empty descender space below the image (a
'faux letter'!) will naturally be invisible.

To see more of what is going on, try with a bit of text in there:

<div style="height:100px; color: black; background:
yellow;">layout<img ... height="100"></div>

To see more clearly, enlarge the text. The bottom of the y in
layout will descend below the div, what is the poor thing to do?
The pic will jut out the div if it is *naturally* taller than
100px and you specify the natural height or leave out the height.
Click to expand...

Yes, when I went back and fiddled with fonts and point sizes I started
noticing these effects. The style="display: block" addition does sort
out the vertical positioning of the image, and I could use
margin-left/right: auto; to centre it.
There are couple of things I have on this business:

<http://dorayme.netweaver.com.au/alt/inlinePicWithDescenderSpace.h
tml>

And there is a bit of discussion that might be helpful at:

<http://netweaver.com.au/floatHouse/page2.php>

Never mind that it is in the context of pages on floats, there is
some stuff about pure inline text (top of page) and images
(bottom of page) on page 2. There is a movie to help along, get
some chips and popcorn and a milkshake handy.
Click to expand...

Chips? Popcorn!? Milkshake!?! Forbidden by Edict 27 Subpara 12 of SWMBO.
But otherwise very readable and useful - thanks.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Text does not display correctly to glow 2
Align img inside nav tabs section 5
Justify-content not working 1
Not sure why drop-down is not working. 2
Uncaught ReferenceError: item is not defined at HTMLButtonElement.onclick in the: <button onclick="item.inserir()">Inserir dados</button> 1
How can I add arrows to my FAQ 0
Having difficulty with the layout of these images / video for this web page 2
How to position the *tooltip* comment on these buttons? 9

Members online

No members online now.
Total: 37 (members: 1, guests: 36)
Robots: 448

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top