Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > HTML > Unicode subscripts not displaying correctly

Reply
Thread Tools

Unicode subscripts not displaying correctly

 
 
Norman Swartz
Guest
Posts: n/a
 
      01-29-2011
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 <(E-Mail Removed)>
 
Reply With Quote
 
 
 
 
dorayme
Guest
Posts: n/a
 
      01-29-2011
In article <Xns9E7C86048AA7Fswartzsfuca@69.16.185.250>,
Norman Swartz <(E-Mail Removed)> wrote:

> I dislike using <sub></sub> in HTML: it affects the line-spacing.


You better see a solution proposed by Korpela years back which I
thought more than sensible:

<http://www.cs.tut.fi/~jkorpela/www/linespacing.html>

--
dorayme
 
Reply With Quote
 
 
 
 
Jukka K. Korpela
Guest
Posts: n/a
 
      01-29-2011
Norman Swartz wrote:

> I dislike using <sub></sub> in HTML: it affects the line-spacing.


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.


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/unic...ontsupport.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.


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>


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;}


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">


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

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

 
Reply With Quote
 
Tim Streater
Guest
Posts: n/a
 
      01-30-2011
In article <vl01p.4900$(E-Mail Removed)>,
"Jukka K. Korpela" <(E-Mail Removed)> wrote:

> > The Doctype is:
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

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


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

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
 
Reply With Quote
 
Jukka K. Korpela
Guest
Posts: n/a
 
      01-30-2011
Tim Streater wrote:

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

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

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


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).

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

 
Reply With Quote
 
Tim Streater
Guest
Posts: n/a
 
      01-30-2011
In article <WJe1p.5099$(E-Mail Removed)>,
"Jukka K. Korpela" <(E-Mail Removed)> wrote:

> Tim Streater wrote:
>
> >>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> >>
> >> Calling the dark demons of Quirks Mode. Probably irrelevant to this
> >> topic, but generally a bad move for any new page.

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

>
> 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).


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.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
 
Reply With Quote
 
C A Upsdell
Guest
Posts: n/a
 
      01-30-2011
On 2011-01-30 10:53, Tim Streater wrote:
> >
> > 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).

>
> Thank you, I wasn't aware that Transitional allowed quirky behaviour ...

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.



 
Reply With Quote
 
dorayme
Guest
Posts: n/a
 
      01-30-2011
In article
<(E-Mail Removed)>,
Tim Streater <(E-Mail Removed)> wrote:

> 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.


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.

--
dorayme
 
Reply With Quote
 
Tim Streater
Guest
Posts: n/a
 
      01-30-2011
In article <ii4bl9$9p2$(E-Mail Removed)-september.org>,
C A Upsdell <(E-Mail Removed)> wrote:

> On 2011-01-30 10:53, Tim Streater wrote:
> > >
> > > 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).

> >
> > Thank you, I wasn't aware that Transitional allowed quirky behaviour ...

> 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.


Oh I had the URL alright. Now the doctype is:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">

previously it was:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
 
Reply With Quote
 
Tim Streater
Guest
Posts: n/a
 
      01-30-2011
In article <(E-Mail Removed)>,
dorayme <(E-Mail Removed)> wrote:

> In article
> <(E-Mail Removed)>,
> Tim Streater <(E-Mail Removed)> wrote:
>
> > 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.

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


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.


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.


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.


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.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
xsl -- using math in element subscripts? William Krick XML 10 08-26-2006 05:26 PM
Allowing zero-dimensional subscripts spam.noam@gmail.com Python 25 06-10-2006 11:53 PM
VHDL Subscripts Cameron, Charles B. VHDL 2 02-26-2004 03:07 PM
Question about some funky behavior with array subscripts Pete C++ 7 11-14-2003 02:02 PM
Unicode + jsp + mysql + tomcat = unicode still not displaying Robert Mark Bram Java 0 09-28-2003 05:37 AM



Advertisments