Unicode subscripts not displaying correctly

Discussion in 'HTML' started by Norman Swartz, Jan 29, 2011.

  1. 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 <>
    Norman Swartz, Jan 29, 2011
    #1
    1. Advertising

  2. Norman Swartz

    dorayme Guest

    In article <Xns9E7C86048AA7Fswartzsfuca@69.16.185.250>,
    Norman Swartz <> 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
    dorayme, Jan 29, 2011
    #2
    1. Advertising

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


    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/
    Jukka K. Korpela, Jan 29, 2011
    #3
  4. Norman Swartz

    Tim Streater Guest

    In article <vl01p.4900$>,
    "Jukka K. Korpela" <> 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
    Tim Streater, Jan 30, 2011
    #4
  5. 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/
    Jukka K. Korpela, Jan 30, 2011
    #5
  6. Norman Swartz

    Tim Streater Guest

    In article <WJe1p.5099$>,
    "Jukka K. Korpela" <> 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
    Tim Streater, Jan 30, 2011
    #6
  7. Norman Swartz

    C A Upsdell Guest

    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.
    C A Upsdell, Jan 30, 2011
    #7
  8. Norman Swartz

    dorayme Guest

    In article
    <>,
    Tim Streater <> 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
    dorayme, Jan 30, 2011
    #8
  9. Norman Swartz

    Tim Streater Guest

    In article <ii4bl9$9p2$-september.org>,
    C A Upsdell <> 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
    Tim Streater, Jan 30, 2011
    #9
  10. Norman Swartz

    Tim Streater Guest

    In article <>,
    dorayme <> wrote:

    > In article
    > <>,
    > Tim Streater <> 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
    Tim Streater, Jan 30, 2011
    #10
  11. Norman Swartz

    dorayme Guest

    In article
    <>,
    Tim Streater <> wrote:

    > In article <>,
    > dorayme <> wrote:
    >
    > > In article
    > > <>,
    > > Tim Streater <> 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.
    >


    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.



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


    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.

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

    >


    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.

    --
    dorayme
    dorayme, Jan 31, 2011
    #11
  12. Norman Swartz

    Lewis Guest

    In message <>
    Tim Streater <> wrote:
    > In article <vl01p.4900$>,
    > "Jukka K. Korpela" <> 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 ?


    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.

    --
    I WILL NOT EXPOSE THE IGNORANCE OF THE FACULTY Bart chalkboard Ep. 8F15
    Lewis, Jan 31, 2011
    #12
  13. Norman Swartz

    Lewis Guest

    In message <>
    Tim Streater <> wrote:
    > In article <>,
    > dorayme <> wrote:


    >> In article
    >> <>,
    >> Tim Streater <> 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.


    yes, but how did those other four do on the Acid2 test?


    --
    The King of Marigold was in the kitchen cooking breakfast for the Queen
    The Queen was in the parlor playing piano for the children of the King
    Lewis, Jan 31, 2011
    #13
  14. Norman Swartz

    Tim Streater Guest

    In article <>,
    dorayme <> wrote:

    > In article
    > <>,
    > Tim Streater <> wrote:
    >
    > > In article <>,
    > > dorayme <> wrote:
    > >
    > > > In article
    > > > <>,
    > > > Tim Streater <> 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.
    > >

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


    Oh no! You are spinoza1111 and ICM5P.

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

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


    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.

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

    > >

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


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

    --
    Tim

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
    Tim Streater, Jan 31, 2011
    #14
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Cameron, Charles B.

    VHDL Subscripts

    Cameron, Charles B., Feb 26, 2004, in forum: VHDL
    Replies:
    2
    Views:
    623
    Cameron, Charles B.
    Feb 26, 2004
  2. Pete
    Replies:
    7
    Views:
    410
  3. Replies:
    25
    Views:
    686
    George Sakkis
    Jun 11, 2006
  4. William  Krick
    Replies:
    10
    Views:
    863
    Soren Kuula
    Aug 26, 2006
  5. order of array subscripts

    , Mar 25, 2008, in forum: C Programming
    Replies:
    9
    Views:
    367
Loading...

Share This Page