info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Italic correction
1 view
Skip to first unread message
Stan Brown
Mar 30, 2023, 6:13:08 PM3/30/23
to
On 30 Mar 2023 10:25:40 GMT, Stefan Ram wrote:
> Therefore, the best thing would be for the browser to
> do this. The browser has all the information needed.
> But it does not seem to care.
>
"The" browser???
Last I looked, there were considerably more browsers than one.
If you're referring to some particular browser, you neglected to tell
us which one -- and which version number, on which operating system,
and rendering which page.
--
Stan Brown, Tehachapi, California, USA
https://BrownMath.com/
> Therefore, the best thing would be for the browser to
> do this. The browser has all the information needed.
> But it does not seem to care.
>
"The" browser???
Last I looked, there were considerably more browsers than one.
If you're referring to some particular browser, you neglected to tell
us which one -- and which version number, on which operating system,
and rendering which page.
--
Stan Brown, Tehachapi, California, USA
https://BrownMath.com/
Jukka K. Korpela
Mar 31, 2023, 6:45:59 AM3/31/23
to
Stefan Ram wrote:
> When a non-italic symbol follows an italic symbol, the
> distance betweeen them somtimes is too small. For example:
>
> <i>ƒ</i>)
>
> . The italicized ƒ may "touch" the parenthesis in some
> browsers.
This also happens (quite often) with the simpler and more common case
<i>f</i>)
and even more often with
<i>f</i>(
(I'm biting my fingers to not comment the use of LATIN SMALL LETTER F
WITH HOOK U+0192 ƒ except by stating that the character is rarely used
and has no standardized use, and since it is essentially a calligraphic
(or script) “f” taken to different uses, it is very slanted in many
fonts, and if you italicize it, you probably get very, very slanted
italics or faux italics.)
> To avoid this, one could introduce a small space:
>
> <i>ƒ</i> )
Yes, but   is U+200A HAIR SPACE, which is very thin, intended to
correspond to the thinnest space available in traditional typography. It
may well be insufficient here. Generally, you would need to select among
the fixed-width spaces in Unicode, depending on the content.
Moreover, fixed-width spaces are spaces and have line breaking property
value of BA (break opportunity after), so a program may decide to break
the line after it. (Whether this happens depends on adjacent characters
and other factors.) Using format control characters or CSS you might
prevent that, but this make approach more complicated.
There is a limited repertoire of fixed-width characters, and their
widths aren’t really fixed but depend on font. For more flexible and
more predictable tuning, you could use CSS, e.g.
<i class=pad>f</i>)
with
.pad { padding-right: 0.15em; }
> It would be very cumbersome to manually (or even
> programmatically) adjust all those character distances.
It is. But you could handle just the most disturbing cases with CSS,
using a pre-made set of class definitions for various sizes of padding.
> Therefore, the best thing would be for the browser to
> do this. The browser has all the information needed.
> But it does not seem to care.
Browsers, or programs in general, don’t do such things. For some years,
browsers have supported kerning (either by default or upon request with
the CSS property font-kerning) for character pairs. For example, if an
HTML document has the letter pair VA and it is rendered using an
OpenType font that has a kerning table entry for it, the odds are
probably that it will be shown as kerned closer to each other. But this
is not based on analysis of the glyphs for the character and the
author’s or viewer’s opinion on how close the characters should be but a
font designers idea of that and specific information (entered into the
kerning table of the font) how certain character pairs should be rendered.
So browsers don’t “think” about such things even for glyphs taken from
the same font and rendered with in the same font style. It would much
more to ask to do something with, say, an italic “f” followed by a
non-italic “)”.
Yucca, https://jkorpela.fi
> When a non-italic symbol follows an italic symbol, the
> distance betweeen them somtimes is too small. For example:
>
> <i>ƒ</i>)
>
> . The italicized ƒ may "touch" the parenthesis in some
> browsers.
This also happens (quite often) with the simpler and more common case
<i>f</i>)
and even more often with
<i>f</i>(
(I'm biting my fingers to not comment the use of LATIN SMALL LETTER F
WITH HOOK U+0192 ƒ except by stating that the character is rarely used
and has no standardized use, and since it is essentially a calligraphic
(or script) “f” taken to different uses, it is very slanted in many
fonts, and if you italicize it, you probably get very, very slanted
italics or faux italics.)
> To avoid this, one could introduce a small space:
>
> <i>ƒ</i> )
Yes, but   is U+200A HAIR SPACE, which is very thin, intended to
correspond to the thinnest space available in traditional typography. It
may well be insufficient here. Generally, you would need to select among
the fixed-width spaces in Unicode, depending on the content.
Moreover, fixed-width spaces are spaces and have line breaking property
value of BA (break opportunity after), so a program may decide to break
the line after it. (Whether this happens depends on adjacent characters
and other factors.) Using format control characters or CSS you might
prevent that, but this make approach more complicated.
There is a limited repertoire of fixed-width characters, and their
widths aren’t really fixed but depend on font. For more flexible and
more predictable tuning, you could use CSS, e.g.
<i class=pad>f</i>)
with
.pad { padding-right: 0.15em; }
> It would be very cumbersome to manually (or even
> programmatically) adjust all those character distances.
It is. But you could handle just the most disturbing cases with CSS,
using a pre-made set of class definitions for various sizes of padding.
> Therefore, the best thing would be for the browser to
> do this. The browser has all the information needed.
> But it does not seem to care.
browsers have supported kerning (either by default or upon request with
the CSS property font-kerning) for character pairs. For example, if an
HTML document has the letter pair VA and it is rendered using an
OpenType font that has a kerning table entry for it, the odds are
probably that it will be shown as kerned closer to each other. But this
is not based on analysis of the glyphs for the character and the
author’s or viewer’s opinion on how close the characters should be but a
font designers idea of that and specific information (entered into the
kerning table of the font) how certain character pairs should be rendered.
So browsers don’t “think” about such things even for glyphs taken from
the same font and rendered with in the same font style. It would much
more to ask to do something with, say, an italic “f” followed by a
non-italic “)”.
Yucca, https://jkorpela.fi
Jukka K. Korpela
Mar 31, 2023, 8:27:27 AM3/31/23
to
Stefan Ram wrote:
> I used it because - if I remember correctly, and at least in one
> browser - that very calligraphic variant was used to render the
> character U+0066 "LATIN SMALL LETTER F" in italic
Sounds very odd, because LATIN SMALL LETTER F WITH HOOK U+0192 ƒ isn’t
an italic variant at all but a script (calligraphic) letter based on the
letter f but without any decomposition. So it’s really a standalone
letter, with just an uppercase counterpart, U+0191 LATIN CAPITAL LETTER
F WITH HOOK Ƒ.
The oddity may relate to the appearance of U+0192 in the Windows Latin 1
character set (in position 0x83). When using a limited character
repertoire and with no way to use italics, you might be tempted into
using ƒ as a substitute for italic f.
> It is difficult for a writer of HTML and CSS to foresee whether a
> browser will use an "f" glyph or an "ƒ" glyph for an italic "f",
> which makes adding the best amount of italic correction hard.
The amount has to be estimated or guessed, but you get a good start if
you choose a suitable font and declare it in CSS and test it. It should
of course be a font that has an italic typeface, and then you can be
pretty sure that it will be used. Of course it is possible that the
declared font is not available in the user’s device or the user’s
browser for some reason overrides your font settings. Using a suitable
fallback font (say, declaring font-family: Cambria, Times New Roman) and
doing a little testing with it should be enough in practice.
Yucca
> I used it because - if I remember correctly, and at least in one
> browser - that very calligraphic variant was used to render the
> character U+0066 "LATIN SMALL LETTER F" in italic
Sounds very odd, because LATIN SMALL LETTER F WITH HOOK U+0192 ƒ isn’t
an italic variant at all but a script (calligraphic) letter based on the
letter f but without any decomposition. So it’s really a standalone
letter, with just an uppercase counterpart, U+0191 LATIN CAPITAL LETTER
F WITH HOOK Ƒ.
The oddity may relate to the appearance of U+0192 in the Windows Latin 1
character set (in position 0x83). When using a limited character
repertoire and with no way to use italics, you might be tempted into
using ƒ as a substitute for italic f.
> It is difficult for a writer of HTML and CSS to foresee whether a
> browser will use an "f" glyph or an "ƒ" glyph for an italic "f",
> which makes adding the best amount of italic correction hard.
The amount has to be estimated or guessed, but you get a good start if
you choose a suitable font and declare it in CSS and test it. It should
of course be a font that has an italic typeface, and then you can be
pretty sure that it will be used. Of course it is possible that the
declared font is not available in the user’s device or the user’s
browser for some reason overrides your font settings. Using a suitable
fallback font (say, declaring font-family: Cambria, Times New Roman) and
doing a little testing with it should be enough in practice.
Yucca
Jukka K. Korpela
Mar 31, 2023, 1:18:07 PM3/31/23
to
Stefan Ram wrote:
> I created a file "main.html" with just five characters: "f<i>f".
I can see a difference in your Ascii art, and it is a fairly normal
difference between normal f and italic f.
I think I now see your point: you are saying that (under some
circumstances) italic f looks a lot like f with hook, with a descender
that extends well below the baseline and turns leftwards. Well, this is
what happens in many fonts. For some fonts, it’s quite different: f with
hook is more or less upright. But in any case, there is no indication of
a glyph for f with hook being used to render an italic f. It’s just
similar glyphs, perhaps with just tiny differences.
The bottom line, I think, is that an italic f can have different shapes,
but it’s still predictable when the typeface is known. Both the
descenders and ascenders might extends so far vertically and
horizontally that you might want to put some spacing both before and
after it in a context like
|<i>f</i>(0)
Yucca
> I created a file "main.html" with just five characters: "f<i>f".
I can see a difference in your Ascii art, and it is a fairly normal
difference between normal f and italic f.
I think I now see your point: you are saying that (under some
circumstances) italic f looks a lot like f with hook, with a descender
that extends well below the baseline and turns leftwards. Well, this is
what happens in many fonts. For some fonts, it’s quite different: f with
hook is more or less upright. But in any case, there is no indication of
a glyph for f with hook being used to render an italic f. It’s just
similar glyphs, perhaps with just tiny differences.
The bottom line, I think, is that an italic f can have different shapes,
but it’s still predictable when the typeface is known. Both the
descenders and ascenders might extends so far vertically and
horizontally that you might want to put some spacing both before and
after it in a context like
|<i>f</i>(0)
Yucca
David E. Ross
Apr 2, 2023, 4:56:20 PM4/2/23
to
On 3/30/2023 3:25 AM, Stefan Ram wrote:
> Therefore, the best thing would be for the browser to
> do this. The browser has all the information needed.
> But it does not seem to care.
WHICH BROWSER? Or do you see this problem with several different
> Therefore, the best thing would be for the browser to
> do this. The browser has all the information needed.
> But it does not seem to care.
browsers? Do not tell us any browser without also indicating the version.
--
David E. Ross
<http://www.rossde.com/>
Beyond Meat and other such vegetarian meat substitutes
represent the ultimate in ultra-processed foods. Real
meat is natural. Beyond Meat is definitely not.
Stan Brown
Apr 3, 2023, 9:11:32 AM4/3/23
to
On 3 Apr 2023 12:58:40 GMT, Stefan Ram wrote:
> "David E. Ross" <nob...@nowhere.invalid> writes:
> > [quoted text muted]
>
When you're talking about browser behavior, that's staggeringly
unhelpful -- unless, of course, you're deliberately trying to be
obscure.
> "David E. Ross" <nob...@nowhere.invalid> writes:
> > [quoted text muted]
> >>do this. The browser has all the information needed.
> >>But it does not seem to care.
> >WHICH BROWSER? Or do you see this problem with several different
> >browsers? Do not tell us any browser without also indicating the version.
>
> When I was writing "the browser", I was using the generic "the".
> >>But it does not seem to care.
> >WHICH BROWSER? Or do you see this problem with several different
> >browsers? Do not tell us any browser without also indicating the version.
>
>
When you're talking about browser behavior, that's staggeringly
unhelpful -- unless, of course, you're deliberately trying to be
obscure.
Allodoxaphobia
Apr 3, 2023, 9:24:14 AM4/3/23
to
On 3 Apr 2023 12:58:40 GMT, Stefan Ram wrote:
>
> When I was writing "the browser", I was using the generic "the".
>
>|the
>
> When I was writing "the browser", I was using the generic "the".
>
> ...
>|definite article
> ...
>|4 used before a singular noun to show that you are talking
>|about that thing in general:
>|"The computer has changed our lives."
> ...
> quoted from an American dictionary
>
>
>|the
> ...
>|def.art.
> ...
>|2. Used before a singular noun
>|indicating that the noun is generic:
>|"The wolf is an endangered species."
> ...
> quoted from another American dictionary
So, *the* `lynx` browser perhaps?
Jukka K. Korpela
Apr 3, 2023, 1:54:30 PM4/3/23
to
Stan Brown wrote:
> On 3 Apr 2023 12:58:40 GMT, Stefan Ram wrote:
>> "David E. Ross" <nob...@nowhere.invalid> writes:
>>> [quoted text muted]
>>>> do this. The browser has all the information needed.
>>>> But it does not seem to care.
>>> WHICH BROWSER? Or do you see this problem with several different
>>> browsers? Do not tell us any browser without also indicating the version.
>>
>> When I was writing "the browser", I was using the generic "the".
>>
>
> When you're talking about browser behavior, that's staggeringly
> unhelpful -- unless, of course, you're deliberately trying to be
> obscure.
This was about knowing that some characters might come too close to each
> On 3 Apr 2023 12:58:40 GMT, Stefan Ram wrote:
>> "David E. Ross" <nob...@nowhere.invalid> writes:
>>> [quoted text muted]
>>>> do this. The browser has all the information needed.
>>>> But it does not seem to care.
>>> WHICH BROWSER? Or do you see this problem with several different
>>> browsers? Do not tell us any browser without also indicating the version.
>>
>> When I was writing "the browser", I was using the generic "the".
>>
>
> When you're talking about browser behavior, that's staggeringly
> unhelpful -- unless, of course, you're deliberately trying to be
> obscure.
other, and I think it has fair to say that the browser (generically) has
all the information it needs to avoid this. In order to be able to
render characters at all, the browser needs to know what glyphs from
which fonts it will use, and the font file (to which it must have
access) contains information about the metrics of the font and the
glyphs themselves, usually in the form of an algorithm to create a glyph.
So the browser (generically) has the information, but it does not use it
for that purpose, for several reasons.
Yucca
Stan Brown
Apr 3, 2023, 2:43:39 PM4/3/23
to
second clause I have trouble with.
Your knowledge of browsers may be more extensive than mine, but I
find it hard to believe that every single browser behaves the same in
this respect, or in any respect.
Had the OP said, "Chrome version X on operating system Y does Z",
that would be a different matter. It is the categorical statement
about the behavior of every browser that I find so hard to swallow.
0 new messages