Stylesheets - Preventing italics text from hitting the next character

Author

Preventing italics text from hitting the next character

Jukka K. Korpela

2006-11-05, 11:32 pm

I recently noticed, once again, how the common implementation of italics can
really disturb. I'm referring to the common phenomenon that there is by
default too little spacing after italics text, so that if you have, say,
Bill Watterson
then the last "l" of "Bill" hits the "W" - they may even slighly overlap. I
noticed this long ago, and I discuss it briefly at
http://www.cs.tut.fi/~jkorpela/math/#it
in the context of mathematical notations like f(0).

But the program is general and common and doesn't seem to go away. I don't
know its origins; word processors don't seem to have similar problems.
Anyway, it can be really disturbing e.g. when it makes quite unclear whether
there is a space between words or whether a part of a word has been
italized. This is particularly bad if the text happens to discuss the proper
use of spaces.

Now it seems to me that something like
i, em, cite, dfn, var { padding-right: 0.25em; margin-right: 0; }
would be needed, in general. That's a based on a more of less worst-case
scenario, as with the final "l" and initial "W". It seems to give still
reasonable spacing in other cases as well.

But this approach fails when an italized word is _immediately_ followed by
some non-space character, like ".". It then looks like there's a space
between when there is none. In principle, this is easy: just add
i.n, em.n, cite.n, dfn.n, var.n { padding-right: 0; }
and use class="n" as needed, e.g.
... this is really important.

Yet, this is quite a lot of work, and rather awkward because what we simply
_want_ to say is "don't use right padding for these elements when followed
by a non-space content character". There's of course no way to say that
general rule in CSS as currently defined an implemented.

So is it reasonable to worry about the issue and use the clumsy workaround?
(There's also the risk that if browsers start implementing italics properly,
we would get too much spacing with the workaround.)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Thomas Mlynarczyk

2006-11-05, 11:32 pm

Also sprach Jukka K. Korpela:

> So is it reasonable to worry about the issue and use the clumsy
> workaround?

I would say that rendering text with appropriate spacing between italic and
non-italic words/characters is entirely the user agent's responsibility. To
work around the problem of unwanted space between an italic word and a
following full stop, colon or similar character when applying an extra
padding, one could (should?) include that character in the italic text:

This is italic! This is not.
em { padding-right: .25em; }

But I wouldn't bother. I find it much more annoying when IE produces an
unnecessary horizontal scrollbar or when parts of the italic characters get
cut off (see
http://www.positioniseverything.net...alicbug-ie.html).

> (There's also the risk that if browsers start implementing italics
> properly,

There's also the risk that if I win a million in the lottery... ;-)

Greetings,
Thomas

Ben C

2006-11-05, 11:32 pm

On 2006-10-12, Jukka K. Korpela <jkorpela@cs.tut.fi> wrote:
> I recently noticed, once again, how the common implementation of italics can
> really disturb. I'm referring to the common phenomenon that there is by
> default too little spacing after italics text, so that if you have, say,
>Bill Watterson
> then the last "l" of "Bill" hits the "W" - they may even slighly overlap.

[snip]

> So is it reasonable to worry about the issue and use the clumsy workaround?
> (There's also the risk that if browsers start implementing italics properly,
> we would get too much spacing with the workaround.)

Some of them already implement italics if not properly at least
differently.

If you try your example Bill Watterson and also set a
background-color on the , you can see exactly where the UA has
decided the right edge of the inline box generated by the should
be.

Firefox uses the advance box of the rightmost glyph, which doesn't quite
completely enclose the 'l'; but Konqueror uses its bounding box, which
does. This also has the effect that you don't get the overhang.

As far as I know CSS 2.1 doesn't specify one way or the other. But using
the bounding box seems to make more sense.

Markus Ernst

2006-11-05, 11:32 pm

Jukka K. Korpela schrieb:
> I recently noticed, once again, how the common implementation of italics
> can really disturb. I'm referring to the common phenomenon that there is
> by default too little spacing after italics text, so that if you have, say,
> Bill Watterson
> then the last "l" of "Bill" hits the "W" - they may even slighly
> overlap. I noticed this long ago, and I discuss it briefly at
> http://www.cs.tut.fi/~jkorpela/math/#it
> in the context of mathematical notations like f(0).
>
> But the program is general and common and doesn't seem to go away. I
> don't know its origins; word processors don't seem to have similar
> problems.
I believe to remember having seen the same (not too many years ago) in
MS Word and even QuarkXPress screen display, while the printed rendering
was ok.

> Anyway, it can be really disturbing e.g. when it makes quite
> unclear whether there is a space between words or whether a part of a
> word has been italized. This is particularly bad if the text happens to
> discuss the proper use of spaces.
In this case I suggest a special markup for the example spaces rather
than for the surrounding text - such as coloring them or surrounding
them by [ ] or whatever.

> Now it seems to me that something like
> i, em, cite, dfn, var { padding-right: 0.25em; margin-right: 0; }
> would be needed, in general. That's a based on a more of less worst-case
> scenario, as with the final "l" and initial "W". It seems to give still
> reasonable spacing in other cases as well.
>
> But this approach fails when an italized word is _immediately_ followed
> by some non-space character, like ".". It then looks like there's a
> space between when there is none. In principle, this is easy: just add
> i.n, em.n, cite.n, dfn.n, var.n { padding-right: 0; }
> and use class="n" as needed, e.g.
> ... this is really important.
I would consider this as breaking the concept of separating contents
from presentation.

> Yet, this is quite a lot of work, and rather awkward because what we
> simply _want_ to say is "don't use right padding for these elements when
> followed by a non-space content character". There's of course no way to
> say that general rule in CSS as currently defined an implemented.
>
> So is it reasonable to worry about the issue and use the clumsy
> workaround? (There's also the risk that if browsers start implementing
> italics properly, we would get too much spacing with the workaround.)

I agree with you that the effect you describe is ugly and annoying.
Although I agree with Thomas that text rendering should be completely
left to the user agent. In order to do a proper microtypography it is
essential to know the rendering situation. As stated by others and by
yourself in the above paragraph, any trickery done for today's average
visual browsers could possibly break in browsers with better rendering,
or in any browser using a font you did not include in your tests. It is
yet likely to break when printing.

I used to do high quality print typography, and it is my experience that
microtypographical adjustments usually only work for the special
situation they are done for. Change the font face and the perfectly
adjusted headline looks crappy, change the size and your decent spacing
results in looking too wide or too compact. In web pages these effects
can even be multiplied by the fact that all measuring might be rounded
up or down to entire pixels.

That's why I think that for web authoring, relying on the OS, browser
and font defaults is least likely to break, though in some cases you may
be able to get better results for an average situation.

--
Markus

Keith Baird

2006-11-05, 11:32 pm

"Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote:
> i, em, cite, dfn, var { padding-right: 0.25em; margin-right: 0; }
>
> But this approach fails when an italized word is _immediately_ followed by
> some non-space character, like ".". It then looks like there's a space
> between when there is none. In principle, this is easy: just add
> i.n, em.n, cite.n, dfn.n, var.n { padding-right: 0; }
> and use class="n" as needed, e.g.
> ... this is really important.
>
> Yet, this is quite a lot of work, and rather awkward because what we simply
> _want_ to say is "don't use right padding for these elements when followed
> by a non-space content character". There's of course no way to say that
> general rule in CSS as currently defined an implemented.
>
> So is it reasonable to worry about the issue and use the clumsy workaround?

Generally, punctuation immediately following italicized text is also
italicized (at least in traditional typesetting), so the situation would
be handled solely by markup placement with no need for a second selector:

.... this is really important.

While this markup is structurally more correct (or at least more
traditional), presentationally the right-padding increases whitespace
between sentences, so perhaps a second selector is needed after all.

--/<eith

Joe (GKF)

2006-11-05, 11:32 pm

In article <cXwXg.4858$951.1514@reader1.news.jippii.net>,
jkorpela@cs.tut.fi says...
> I recently noticed, once again, how the common implementation of italics can
> really disturb. I'm referring to the common phenomenon that there is by
> default too little spacing after italics text, so that if you have, say,
> Bill Watterson

>
>
My usual method is to code italics like this - with the gap
inside the tags. If I don't want a gap, I leave it out. Sometimes
there's a danger in overthinking a problem. Of course, I've never
written a discussion paper on the proper use of spaces.

Jukka K. Korpela

2006-11-05, 11:32 pm

Scripsit Keith Baird:

> Generally, punctuation immediately following italicized text is also
> italicized (at least in traditional typesetting), so the situation
> would be handled solely by markup placement with no need for a second
> selector:
>
> ... this is really important.

It's structurally illogical, since the intent is not to emphasize the
period, just the word. Besides, traditional typesetting does not always
italicize the punctuation that follows an italicized word; commonly, a
parenthesis is _not_ italicized (even if it logically belongs to the
fragment of text that is being emphasized or otherwise made special).

Moreover, there are several cases, like
1) foo.
2) foo bar
3) f(0)
and your suggestion only deals with case 1. Assuming we generally add right
padding to elements that appear in italics, then 2 is no problem (that's a
case where we really want the extra spacing), but 3 is. Case 1 could be
fixed using your method, since the spacing would appear after the period,
which is OK, but I don't like this idea of using slightly illogical markup.
I'd rather use honestly presentational markup in the sense that I add
attributes that lack semantic meaning byt will be used for presentational
purposes.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jukka K. Korpela

2006-11-05, 11:32 pm

Scripsit Joe (GKF):

> My usual method is to code italics like this - with the gap
> inside the tags. If I don't want a gap, I leave it out. Sometimes
> there's a danger in overthinking a problem.

That's simple indeed, and it relies on a widespread browser bug, so it may
look safe. (The bug is inappropriate handling of whitespace; consecutive
whitespace characters should be collapsed into a single space.) Of course,
it would be awkward to remove the trick later (as opposite to removing an
extra CSS rule).

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Joe (GKF)

2006-11-05, 11:32 pm

In article <0dxYg.6937$%34.5494@reader1.news.jippii.net>,
jkorpela@cs.tut.fi says...
> Scripsit Joe (GKF):
>
>
> That's simple indeed, and it relies on a widespread browser bug, so it may
> look safe. (The bug is inappropriate handling of whitespace; consecutive
> whitespace characters should be collapsed into a single space.) Of course,
> it would be awkward to remove the trick later (as opposite to removing an
> extra CSS rule).
>
I don't understand what you're telling me. The method I outlined doesn't
need or use consecutive spaces; rather the space is placed before the
 rather than after it.
Like this example shows. One space.
For words requiring punctuation immediately after, I use this.
No following space. I disagree with whoever it was who advocated putting
the punctuation inside the , that is hardly ever appropriate.

By the way, if I want to make something that looks like f(0), I
usually use &#fnof; but I could use ƒ or even or ƒ if I
wanted.

Andy Dingley

2006-11-05, 11:32 pm

Joe (GKF) wrote:

> I don't understand what you're telling me. The method I outlined doesn't
> need or use consecutive spaces;

Ask yourself this: Is "space" "space" a pair of consecutive
spaces?
As doesn't generate any content, what happens to those two spaces
?
Do they become consecutive ?

Harlan Messinger

2006-11-05, 11:32 pm

Andy Dingley wrote:
> Joe (GKF) wrote:
>
>
> Ask yourself this: Is "space" "space" a pair of consecutive
> spaces?

He didn't have "space" "space". He had "space" "not-a-space".

> As doesn't generate any content, what happens to those two spaces
> ?
> Do they become consecutive ?
>

Jukka K. Korpela

2006-11-05, 11:32 pm

Scripsit Joe (GKF):

> I don't understand what you're telling me. The method I outlined doesn't
> need or use consecutive spaces; rather the space is placed before the
> rather than after it.
> Like this example shows. One space.

I see. But you wrote: "My usual method is to code italics like
this - with the
gap inside the tags." That looked a bit vague to me - you surely don't have
any gap inside tags but _between_ tags.

So it's a _different_ browser misbehavior that you are relying on. In HTML,
spaces are supposed to be separators between words, so it's illogical that
it matters whether a space is inside some markup or not, as regards to
rendering the space.

> By the way, if I want to make something that looks like f(0), I
> usually use &#fnof; but I could use ƒ or even or ƒ if I
> wanted.

If you do that, you're doing the wrong thing. Those references denote U+0192
LATIN SMALL LETTER F WITH HOOK. Although it is also known as "function
symbol" (as well as "Florin currency symbol"), it is not at all the same as
letter f in italics.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Markus Ernst

2006-11-05, 11:32 pm

Jukka K. Korpela schrieb:
> So it's a _different_ browser misbehavior that you are relying on. In
> HTML, spaces are supposed to be separators between words, so it's
> illogical that it matters whether a space is inside some markup or not,
> as regards to rendering the space.

Not if the markup affects type rendering, as the width of a space is
defined in the typeface, and also affected by possible style suggestions
such as font-size, font-weight, font-stretch or letter-spacing. Thus,
differences in the rendering of Text and Text are (or
should be in my nit-picking typographers's oppinion):

- Possible in normal cases (em element rendered as italic), as the with
of a space in a roman and an italic typeface can differ in a decently
designed font family

- Very likely if extra font styling is applied to the em element;
imagine some super-interpretation of "emphasis", such as:
em {
font:bolder 150% monospace;
font-stretch:ultra-expanded;
letter-spacing:1em
}

--
Markus

Joe (GKF)

2006-11-05, 11:32 pm

In article <YrcZg.8332$aX.3448@reader1.news.jippii.net>,
jkorpela@cs.tut.fi says...
> Scripsit Joe (GKF):
>

[color=darkred]
>
> So it's a _different_ browser misbehavior that you are relying on. In HTML,
> spaces are supposed to be separators between words, so it's illogical that
> it matters whether a space is inside some markup or not, as regards to
> rendering the space.
>
Many things seem illogical until you realise what is actually going on.

Because of the way computers do such things, it is possible for an
'italicised' character to lean out of its assigned space.

The method I use is repeatable and works everywhere I have tried it,
which is enough for me.
I consider it more an 'undocumented feature' than a misbehaviour. In
any event, if it's not enough for you, so be it.

>
> If you do that, you're doing the wrong thing. Those references denote U+0192
> LATIN SMALL LETTER F WITH HOOK. Although it is also known as "function
> symbol" (as well as "Florin currency symbol"), it is not at all the same as
> letter f in italics.

Quite so, and I would only use it as such.
Whenever I have seen f(0), it's always meant 'function of'(0),
and your original post (where you say ..."in the context of mathematical
notations like f(0)...") led me to believe that is what it meant
in this case.

Harlan Messinger

2006-11-05, 11:32 pm

Joe (GKF) wrote:
> In article <YrcZg.8332$aX.3448@reader1.news.jippii.net>,
> jkorpela@cs.tut.fi says...
>
>
> Many things seem illogical until you realise what is actually going on.
>
> Because of the way computers do such things, it is possible for an
> 'italicised' character to lean out of its assigned space.

A character's "assigned space" ought to be the space it takes up, so
that by definition it can't lean out of it. ("Assigned" is a loose term,
of course, since kerning will result in the overlap of two characters'
assigned spaces.)

Ben C

2006-11-05, 11:32 pm

On 2006-10-19, Harlan Messinger <hmessinger.removethis@comcast.net> wrote:
> Joe (GKF) wrote:
>
> A character's "assigned space" ought to be the space it takes up, so
> that by definition it can't lean out of it. ("Assigned" is a loose term,
> of course, since kerning will result in the overlap of two characters'
> assigned spaces.)

In font terminology, a glyph has a "bounding box", and an "advance box".

No part of the glyph is ever outside the bounding box by definition, but
parts of it may be outside the advance box. This is common with italic
glyphs.

When you lay out some text, you place the advance boxes next to one
another. This means that glyph bounding boxes may overlap.

Keith Baird

2006-11-05, 11:33 pm

"Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote:
>
> It's structurally illogical, since the intent is not to emphasize the
> period, just the word.

Punctuation is part of the logical content of a sentence; marking it up
jointly with the text is, therefore, structurally logical.

--/<eith

Chris F.A. Johnson

2006-11-05, 11:33 pm

On 2006-10-20, Keith Baird wrote:
> "Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote:
>
> Punctuation is part of the logical content of a sentence; marking it up
> jointly with the text is, therefore, structurally logical.

As you say, it "is part of the logical content of a sentence"; it
is not part of the content (logical or otherwise) of the word, and
therefore it is _not_ structually logical to include it.

--
Chris F.A. Johnson <http://cfaj.freeshell.org>
===================================================================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

Joe (GKF)

2006-11-05, 11:33 pm

In article <slrnejf5c0.1al.spamspam@bowser.marioworld>,
spamspam@spam.eggs says...
> On 2006-10-19, Harlan Messinger <hmessinger.removethis@comcast.net> wrote:
>
> In font terminology, a glyph has a "bounding box", and an "advance box".
>
> No part of the glyph is ever outside the bounding box by definition, but
> parts of it may be outside the advance box. This is common with italic
> glyphs.
>
> When you lay out some text, you place the advance boxes next to one
> another. This means that glyph bounding boxes may overlap.
>
Thanks Ben - I don't know the correct terminology.You're right, of
course. I meant to convey that when converting a character to "italic",
the computer assigns space (the advance box), puts the character in it
and then pushes it over a bit, causing it to possibly fall out of the
box.
Anyway, it seems Mr Korpela has lost interest and I was never all that
fussed.

Keith Baird

2006-11-05, 11:33 pm

NNTP-Posting-Host: adm122.reg.XXXXXX.edu
X-Trace: geraldo.cc.XXXXXX.edu 1161624836 1752 146.6.110.122 (23 Oct 2006 17:33:56 GMT)
X-Complaints-To: abuse@XXXXXX.edu
NNTP-Posting-Date: Mon, 23 Oct 2006 17:33:56 +0000 (UTC)
User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X)
Xref: number1.nntp.dca.giganews.com comp.infosystems.www.authoring.stylesheets:101681

Keith Baird wrote:
> Punctuation is part of the logical content of a sentence; marking it up
> jointly with the text is, therefore, structurally logical.

Chris F.A. Johnson wrote:
> As you say, it "is part of the logical content of a sentence"; it
> is not part of the content (logical or otherwise) of the word, and
> therefore it is _not_ structually logical to include it.

There is a logical relationship between a sentence's terminal
punctuation and the *last* word in a sentence, therefore it is
structually logical to apply the same presentation to both because
together they end the sentence (which neither can do in isolation).

This is an issue long-solved in traditional practice, a fact unaltered
by historically recent notions of separation of meaning and
presentation. Punctuation is, after all, a form of logical text markup
(vastly) predating HTML/XML/CSS, and there is no need to fabricate or
rationalize new practice. The question only concerned physical
presentation of text, so it is reasonable to apply established text
conventions.

--/<eith

Chris F.A. Johnson

2006-11-05, 11:33 pm

On 2006-10-23, Keith Baird wrote:
> Keith Baird wrote:
>
> Chris F.A. Johnson wrote:
>
> There is a logical relationship between a sentence's terminal
> punctuation and the *last* word in a sentence, therefore it is
> structually logical to apply the same presentation to both because
> together they end the sentence (which neither can do in isolation).

There is a positional relationship, nothing more.

> This is an issue long-solved in traditional practice, a fact unaltered
> by historically recent notions of separation of meaning and
> presentation. Punctuation is, after all, a form of logical text markup
> (vastly) predating HTML/XML/CSS, and there is no need to fabricate or
> rationalize new practice. The question only concerned physical
> presentation of text, so it is reasonable to apply established text
> conventions.

In 20 years of graphic design and typesetting, I never saw the
punctuation included like that.

--
Chris F.A. Johnson <http://cfaj.freeshell.org>
===================================================================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)