info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: HTML and Unicode notations
3 views
Skip to first unread message
Stewart Robert Hinsley
Mar 30, 2023, 2:32:42 PM3/30/23
to
On 30/03/2023 11:13, Stefan Ram wrote:
> Is there be a reason to prefer one over the other notation?
The original philosophy was for HTML to be used for semantics, not for
formatting. Under that philosophy, in both cases the first form is
preferred. (The argument strikes me as stronger for MATHEMATICAL ITALIC
CAPITAL P.)
Wikipedia has descriptions, with appropriate references.
>
> "x²" versus "x<sup>2</sup>"
https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
>
> "𝑃" versus "<i>P</i>" for a mathematical variable
>
> ("𝑃" is U+1D443 "MATHEMATICAL ITALIC CAPITAL P".)
>
https://en.wikipedia.org/wiki/Mathematical_Alphanumeric_Symbols
Before UNICODE became prevalent that was an argument for using
superscript markup, rather than superscript characters, as only square
and cube were available as characters, and they often formatted
differently from other powers implemented as markup. (It's seems that I
have some pages that I have to go through and change to use UNICODE
superscripts.)
--
SRH
> Is there be a reason to prefer one over the other notation?
The original philosophy was for HTML to be used for semantics, not for
formatting. Under that philosophy, in both cases the first form is
preferred. (The argument strikes me as stronger for MATHEMATICAL ITALIC
CAPITAL P.)
Wikipedia has descriptions, with appropriate references.
>
> "x²" versus "x<sup>2</sup>"
https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
>
> "𝑃" versus "<i>P</i>" for a mathematical variable
>
> ("𝑃" is U+1D443 "MATHEMATICAL ITALIC CAPITAL P".)
>
https://en.wikipedia.org/wiki/Mathematical_Alphanumeric_Symbols
Before UNICODE became prevalent that was an argument for using
superscript markup, rather than superscript characters, as only square
and cube were available as characters, and they often formatted
differently from other powers implemented as markup. (It's seems that I
have some pages that I have to go through and change to use UNICODE
superscripts.)
--
SRH
Jukka K. Korpela
Mar 31, 2023, 3:34:17 AM3/31/23
to
Stefan Ram wrote:
> Is there be a reason to prefer one over the other notation?
>
> Is there be a reason to prefer one over the other notation?
>
> "x²" versus "x<sup>2</sup>"
The former results in an essentially better rendering, since a
superscript glyph, as created by a font designed, is used for ², as
opposite to using a glyph for 2 in some superscript style (which is poor
by browser defaults and difficult to tune), normally causing uneven line
spacing when used inside a paragraph.
For complicated mathematical expressions, often with nested
superscripts, use neither. Instead, choose between different non-HTML
methods for rendering expressions. (These include MathML, which can be
embedded into HTML, but not necessary the best solution.I
> "𝑃" versus "<i>P</i>" for a mathematical variable
>
> ("𝑃" is U+1D443 "MATHEMATICAL ITALIC CAPITAL P".)
the <i> markup, partly because it is simpler to create and works more
robustly, without requiring fonts that have glyphs for Mathematical
Alphanumeric Symbols.
For more complicated mathematical expressions, this will be among the
smallest problems you’ll face, and the choice of the tool will normally
solve it. (It’ll let you type just P and have it rendered in italic,
unless you do something special to have it rendered upright.)
Yucca, https://jkorpela.fi
Jukka K. Korpela
Mar 31, 2023, 8:11:01 AM3/31/23
to
Stefan Ram wrote:
> Actually, in the fonts in which I have seen it so far, the
> "MATHEMATICAL ITALIC SMALL ALPHA" 𝛼 from Unicode looks more like what
> I imagine an alpha would look like than "GREEK SMALL LETTER ALPHA" α.
That’s probably because you are used to seeing alpha in mathematics and
other special usage rather than as a letter in Greek words. In
mathematics, variables are written in italic by convention, and this
applies to Greek letters, too. Even though Greek letters may look
“italic-like” as such, there is a difference between upright and italic
for them.
Mathematical italic letters in Unicode are supposed to look like normal
letters in an italic font, but they need not be identical. For example,
mathematical italic small alpha can be expected to display much like
<i>α</i>, but there can be differences. When you use mathematical
italic letters, you effectively force the browser to (try to) use one of
the few fonts that contain them, such as Cambria Math, and not the font
it normally uses for the text. This may result in a better appearance,
because such fonts are designed with the mathematical usage in mind. But
when I tested this a little, I saw very small differences. But I was
using just Cambria and Cambria Math.
> It is also possible that the "MATHEMATICAL ITALIC" symbols
> already have some italic correction built-in.
They are effectively font variants of normal letters, though encoded as
separate characters. It’s not a matter of correction but of design, by a
typographer. These characters should not be italicized, as it would only
be possible with algorithmic slanting, which produces poor results.
Yucca
> Actually, in the fonts in which I have seen it so far, the
> "MATHEMATICAL ITALIC SMALL ALPHA" 𝛼 from Unicode looks more like what
> I imagine an alpha would look like than "GREEK SMALL LETTER ALPHA" α.
That’s probably because you are used to seeing alpha in mathematics and
other special usage rather than as a letter in Greek words. In
mathematics, variables are written in italic by convention, and this
applies to Greek letters, too. Even though Greek letters may look
“italic-like” as such, there is a difference between upright and italic
for them.
Mathematical italic letters in Unicode are supposed to look like normal
letters in an italic font, but they need not be identical. For example,
mathematical italic small alpha can be expected to display much like
<i>α</i>, but there can be differences. When you use mathematical
italic letters, you effectively force the browser to (try to) use one of
the few fonts that contain them, such as Cambria Math, and not the font
it normally uses for the text. This may result in a better appearance,
because such fonts are designed with the mathematical usage in mind. But
when I tested this a little, I saw very small differences. But I was
using just Cambria and Cambria Math.
> It is also possible that the "MATHEMATICAL ITALIC" symbols
> already have some italic correction built-in.
They are effectively font variants of normal letters, though encoded as
separate characters. It’s not a matter of correction but of design, by a
typographer. These characters should not be italicized, as it would only
be possible with algorithmic slanting, which produces poor results.
Yucca
Jukka K. Korpela
Mar 31, 2023, 8:49:38 AM3/31/23
to
Stefan Ram wrote:
> Here's a clarification, but it requires a Newsreader that
> renders all spaces verbatim (even a sequence of several
> spaces at the beginning of a line) and a monospaced font.
I was able to tune Thunderbird to display your message that way, but I
am unable to recognize the difference.
I tested
𝛼 <i>α</i>
using a large font size and could see only very small differences. They
both differ, of course, considerably from plain α. (I used Cambria
as the basic font. Declaring e.g. Arial as the basic font would have a
drastic effect, since then <i>α</i> is very different whereas
𝛼 still comes from Cambria Math font (on my computer).
Yucca
> Here's a clarification, but it requires a Newsreader that
> renders all spaces verbatim (even a sequence of several
> spaces at the beginning of a line) and a monospaced font.
I was able to tune Thunderbird to display your message that way, but I
am unable to recognize the difference.
I tested
𝛼 <i>α</i>
using a large font size and could see only very small differences. They
both differ, of course, considerably from plain α. (I used Cambria
as the basic font. Declaring e.g. Arial as the basic font would have a
drastic effect, since then <i>α</i> is very different whereas
𝛼 still comes from Cambria Math font (on my computer).
Yucca
Jukka K. Korpela
Apr 1, 2023, 6:43:29 AM4/1/23
to
Stefan Ram wrote:
> An "alpha" is a line that describes a kind of semicircle on
> the left side.
>
> On the right sight, the two ends of that line meet in an
> intersection.
>
> I prefer them to intersect forming an angle of about 120
> to 150 degrees (on the left side of their intersection),
> not about 180 degrees.
This sounds like a font issue. The shape of α varies greatly by font,
and in some fonts, it looks much the same as the Latin letter a in an
italic typeface. I don’t think you can do much about this except select
the fonts in your list accordingly. Generally, for mathematical
expressions, you should in any case use a serif font with a rich
repertoire of characters (so that you won’t need to mix fonts), and this
restricts your choices a lot.
In fonts like Cambria, Times New Roman, FreeSerif, and Noto Serif, the
difference between italic a and italic alpha looks quite sufficient to
my eyes.
Yucca
> An "alpha" is a line that describes a kind of semicircle on
> the left side.
>
> On the right sight, the two ends of that line meet in an
> intersection.
>
> I prefer them to intersect forming an angle of about 120
> to 150 degrees (on the left side of their intersection),
> not about 180 degrees.
This sounds like a font issue. The shape of α varies greatly by font,
and in some fonts, it looks much the same as the Latin letter a in an
italic typeface. I don’t think you can do much about this except select
the fonts in your list accordingly. Generally, for mathematical
expressions, you should in any case use a serif font with a rich
repertoire of characters (so that you won’t need to mix fonts), and this
restricts your choices a lot.
In fonts like Cambria, Times New Roman, FreeSerif, and Noto Serif, the
difference between italic a and italic alpha looks quite sufficient to
my eyes.
Yucca
Helmut Richter
Apr 1, 2023, 7:15:58 AM4/1/23
to
On Sat, 1 Apr 2023, Jukka K. Korpela wrote:
> This sounds like a font issue. The shape of α varies greatly by font, and in
> some fonts, it looks much the same as the Latin letter a in an italic
> typeface. I don’t think you can do much about this except select the fonts in
> your list accordingly. Generally, for mathematical expressions, you should in
> any case use a serif font with a rich repertoire of characters (so that you
> won’t need to mix fonts), and this restricts your choices a lot.
>
> In fonts like Cambria, Times New Roman, FreeSerif, and Noto Serif, the
> difference between italic a and italic alpha looks quite sufficient to my
> eyes.
The same problem arises with IPA phonetic symbols: An italic character is
> This sounds like a font issue. The shape of α varies greatly by font, and in
> some fonts, it looks much the same as the Latin letter a in an italic
> typeface. I don’t think you can do much about this except select the fonts in
> your list accordingly. Generally, for mathematical expressions, you should in
> any case use a serif font with a rich repertoire of characters (so that you
> won’t need to mix fonts), and this restricts your choices a lot.
>
> In fonts like Cambria, Times New Roman, FreeSerif, and Noto Serif, the
> difference between italic a and italic alpha looks quite sufficient to my
> eyes.
not the same as a slanted modern-form Antiqua character, and also
conversely, an antiqua character is not just an unslanted italic
character. In particular, an Antiqua “a” has an open roof over the circle,
an italic “a” has not; an Antiqua “g” has often – not always – a closed
oval below the closed circular body on the line, an italic “g” has never;
an Antiqua “f” has no descender, an italic “f” has one. Whenever, for
instance with phonetic symbols, the difference of shape implies a
difference in meaning, these are indeed different characters and not only
different shapes of the same character:
U+0251 ɑ vs. U+0061 a (which is a different sound)
U+0361 ɡ vs. U+0067 g (which does not represent a sound in the other variant)
If one uses italic character for any purpose, e.g. for emphasis or for
designating proper names or foreign-language words, one should use a basic
script where the characters are definitely different from unslanted
italics.
--
Helmut Richter
Helmut Richter
Apr 1, 2023, 7:34:53 AM4/1/23
to
On Sat, 1 Apr 2023, Helmut Richter wrote:
> U+0251 ɑ vs. U+0061 a (which is a different sound)
> U+0361 ɡ vs. U+0067 g (which does not represent a sound in the other variant)
Corr.: U+0261 ɡ
> U+0251 ɑ vs. U+0061 a (which is a different sound)
> U+0361 ɡ vs. U+0067 g (which does not represent a sound in the other variant)
--
Helmut Richter
Helmut Richter
Apr 6, 2023, 3:58:40 AM4/6/23
to
On Sat, 1 Apr 2023, Jukka K. Korpela wrote:
> In fonts like Cambria, Times New Roman, FreeSerif, and Noto Serif, the
> difference between italic a and italic alpha looks quite sufficient to my
> eyes.
I am offering information on web space (thus “authoring”) and I know that
> In fonts like Cambria, Times New Roman, FreeSerif, and Noto Serif, the
> difference between italic a and italic alpha looks quite sufficient to my
> eyes.
there are many fonts and many ways to specify fonts in stylesheets or perhaps
elsewhere. I have still refrained from using that very much, because there
are too many choices and I do not know where to begin. I would be grateful
for any advice you may have from your experience.
I have the following choices:
(1) how to provide the font to the reader
(2) which properties of the font to consider required or preferable
(1a) The easiest way is to use a font that is already installed on all
reasonably expected systems and to provide a general specification of its
features, e.g. „font-family: Georgia, serif;“: that is Georgia if installed,
otherwise another serif font. Now Georgia, which I do like, is not installed
everywhere. How could I find out enough names of fonts so that on most
systems at least one of them is installed? If I specify features (like
serif), how many of them can I specify without running the risk that there
are systems where no font matches all of them?
(1b) Another way is to provide a free – proprietary or not – font on my
server and specify in the style sheets that it shall be downloaded from my
site prior to use. Does the time for downloading matter until the user sees
the contents? Are there any other drawbacks of this approach? What have I to
do (up to now, I have not yet seen a straightforward recipe)?
(1c) I rule out solutions which require the reader to manually install fonts
or anything else before reading my web content.
(1d) I rule out solutions where the reader’s browser loads a font from
a server other than mine. What my readers read is no concern of
third-party companies. (Probably required by the European General Data
Protection Regulation GDPR)
(1e) I rule out solutions which I have to pay for, except perhaps a moderate
one-time payment for an unlimited-time licence.
(1f) A possible solution could also be to specify two of three fonts that are
widely installed (=1a), and one for download (=1b) as fallback when none of
the first group is installed.
Required and desired features of fonts to be used are:
(2a) support of a reasonable subset of Unicode, at least the European and
Middle-East scripts and the symbols in the basic plane – for seldom-used
foreign scripts I could live with special fonts that must be explicitly
specified (e.g. by :lang(...) in CSS)
(2b) one clearly readable serif font for body text; preferably with wide
characters (e.g. Georgia); required to have a matching set of italic
characters thoroughly distinct from non-italics; preferably support of
medieval numbers (which, as I find, fit typographically better in serif
fonts).
(2c) one clearly readable sans-serif font for headlines
(2d) I have no reqirements of “corporate design” in the sense that a Web page
must look exactly the same on every system. But the basic features as
described above should be similar.
Now, when I try to satisfy both (1) and (2) simultaneously, I run into the
problem of determining which fonts come into consideration and what
requirement each of them satisfies. Mostly, a description specifies only a
few of the features mentiones above.
Thanks for any assistance.
--
Helmut Richter
Jukka K. Korpela
Apr 7, 2023, 10:01:39 AM4/7/23
to
Helmut Richter wrote:
> I have the following choices:
>
> (1) how to provide the font to the reader
> (2) which properties of the font to consider required or preferable
>
> (1a) The easiest way is to use a font that is already installed on all
> reasonably expected systems and to provide a general specification of its
> features, e.g. „font-family: Georgia, serif;“: that is Georgia if installed,
> otherwise another serif font. Now Georgia, which I do like, is not installed
> everywhere. How could I find out enough names of fonts so that on most
> systems at least one of them is installed?
I’m afraid there is no general procedure for that. There used to be web
> I have the following choices:
>
> (1) how to provide the font to the reader
> (2) which properties of the font to consider required or preferable
>
> (1a) The easiest way is to use a font that is already installed on all
> reasonably expected systems and to provide a general specification of its
> features, e.g. „font-family: Georgia, serif;“: that is Georgia if installed,
> otherwise another serif font. Now Georgia, which I do like, is not installed
> everywhere. How could I find out enough names of fonts so that on most
> systems at least one of them is installed?
pages that listed commonly available fonts, but they were based on
questionable methodology, and they seem to have disappeared. The
situation has become more complicated e.g. due to mobile devices that
may have their own, limited font repertoires – which might be specially
designed for them.
Using “font-family: Georgia, serif” may well be the right way when you
have a reason to suggest Georgia when available. If you add alternative
fonts, there is no guarantee that the result is better than the generic
fallback to “serif”.
> If I specify features (like
> serif), how many of them can I specify without running the risk that there
> are systems where no font matches all of them?
feature; it refers to an implementation-defined serif font (and possibly
user-defined, as a browser may let the user specify how the name “serif”
is mapped to an actual font).
> (1b) Another way is to provide a free – proprietary or not – font on my
> server and specify in the style sheets that it shall be downloaded from my
> site prior to use. Does the time for downloading matter until the user sees
> the contents?
circumstances.
> Are there any other drawbacks of this approach?
document, it may happen that the page is loaded without the font. In
this case, a default font (as defined in font-family or the browser
configuration) will be used instead.
If the download of the font is slow, it may happen that the browser
first renders the page without it, using a default font, then redraws
the page when it gets the font. Somewhat disturbing.
> What have I to
> do (up to now, I have not yet seen a straightforward recipe)?
reference to it hosted on a Google server. From this simple approach you
can then move to other, perhaps more effective and more efficient
solutions, if suitable.
Here’s a simple example from a page of mine, where I wish to display
some texts in a Fraktur font, and it does not matter much which Fraktur,
so I use the Google font UnifrakturMaguntia: On the <head> I have
<link href=
"https://fonts.googleapis.com/css?family=UnifrakturMaguntia&subset=all"
rel="stylesheet">
<style>
.fr {
font-family: UnifrakturMaguntia;
}
/* change Fraktur to default serif on mouseover: */
span.fr:hover { font-family: serif }
</style>
And in <body> I use class=fr for texts to be displayed in Fraktur, e.g.
<span class=fr>abc</a>.
If you find a suitable font at https://fonts.google.com/ you will see
instructions on using it that way, with some extra stuff suggested there.
> (1d) I rule out solutions where the reader’s browser loads a font from
> a server other than mine.
could still use it for testing (the suitability of a font etc.) and then
move to the approach where you download a font family and prepare it for
use on your own server. (I don’t know how good Google instructions for
that are. You might need to use a “Download family” button, unzip the
package and study its contents.
> (1f) A possible solution could also be to specify two of three fonts that are
> widely installed (=1a), and one for download (=1b) as fallback when none of
> the first group is installed.
than the downloadable font. And with suitable use of CSS, it’s almost as
simple as using just a downloadable font.
> Required and desired features of fonts to be used are:
>
> (2a) support of a reasonable subset of Unicode
modest basic repertoire of about 1,000 “European” characters (like the
old MEs-2 subset), there is a rather limited set of fonts that contain
all of them. On the other hand, most web pages in European languages
probably have a much more limited character repertoire.
> (2b) one clearly readable serif font for body text; preferably with wide
> characters (e.g. Georgia); required to have a matching set of italic
> characters thoroughly distinct from non-italics;
regular and italic typeface. For serif fonts, they tend to be different
enough.
It’s different for sans-serif fonts and for fonts that lack an italic
typeface,
so that the “italic” you get from them e.g. by using <i>...</i> is
“false italic”,
i.e. regular characters slanted algorithmically.
> preferably support of
> medieval numbers (which, as I find, fit typographically better in serif
> fonts).
like lowercase letters do. Most fonts used on web pages do not have them.
Some, like Georgia and Constantia, have them as default glyphs for digits.
Some, like Cambria, have them as optional alternatives, i.e. you need to do
something special to get them. In CSS, you would use the font-variant
property or the older, possibly better supported font-feature-settings
property. This means that you can use, say, Georgia for different texts
so that oldstyle numbers are used in normal text but the other design,
lining figures, e.g. in numerical tables or with text in capital letters.
> (2c) one clearly readable sans-serif font for headlines
font family, though sometimes a serif font family and a sans-serif font
family are available as members of a “superfamily”, such as Noto Serif
and Noto Sans, As for Georgia for example, there is no such concept; you
need to decide which sans-serif font to use with it.
Yucca
Stan Brown
Apr 7, 2023, 11:03:44 AM4/7/23
to
On Fri, 7 Apr 2023 17:01:30 +0300, Jukka K. Korpela wrote:
> Helmut Richter wrote:
> > (1b) Another way is to provide a free ? proprietary or not ? font on my
folks, AARP is an organization for persons over 50, and it has
millions of members.) Every single page -- every one that I've seen,
anyway -- paints, then blanks and repaints. I figured it was bad
scripting, but maybe it's this font thingy.
--
Stan Brown, Tehachapi, California, USA
https://BrownMath.com/
> Helmut Richter wrote:
> > (1b) Another way is to provide a free ? proprietary or not ? font on my
> > server and specify in the style sheets that it shall be downloaded from my
> > site prior to use. Does the time for downloading matter until the user sees
> > the contents?
>
> It may, but this is probably not a big issue these days in most
> circumstances.
>
> > Are there any other drawbacks of this approach?
>
> If the downloadable font is on a server different from that of the HTML
> document, it may happen that the page is loaded without the font. In
> this case, a default font (as defined in font-family or the browser
> configuration) will be used instead.
>
> If the download of the font is slow, it may happen that the browser
> first renders the page without it, using a default font, then redraws
> the page when it gets the font. Somewhat disturbing.
I wonder if this is what's happening with aarp.org. (For non-US
> > site prior to use. Does the time for downloading matter until the user sees
> > the contents?
>
> It may, but this is probably not a big issue these days in most
> circumstances.
>
> > Are there any other drawbacks of this approach?
>
> If the downloadable font is on a server different from that of the HTML
> document, it may happen that the page is loaded without the font. In
> this case, a default font (as defined in font-family or the browser
> configuration) will be used instead.
>
> If the download of the font is slow, it may happen that the browser
> first renders the page without it, using a default font, then redraws
> the page when it gets the font. Somewhat disturbing.
folks, AARP is an organization for persons over 50, and it has
millions of members.) Every single page -- every one that I've seen,
anyway -- paints, then blanks and repaints. I figured it was bad
scripting, but maybe it's this font thingy.
--
Stan Brown, Tehachapi, California, USA
https://BrownMath.com/
Arno Welzel
Apr 7, 2023, 11:34:41 AM4/7/23
to
Helmut Richter, 2023-04-06 09:58:
> On Sat, 1 Apr 2023, Jukka K. Korpela wrote:
>
>> In fonts like Cambria, Times New Roman, FreeSerif, and Noto Serif, the
>> difference between italic a and italic alpha looks quite sufficient to my
>> eyes.
>
> I am offering information on web space (thus “authoring”) and I know that
> there are many fonts and many ways to specify fonts in stylesheets or perhaps
> elsewhere. I have still refrained from using that very much, because there
> are too many choices and I do not know where to begin. I would be grateful
> for any advice you may have from your experience.
Very simple: no font at all. Just decide wether you want to use "serif"
or "sans-serif" and let the user choose in their Browser setting
whatever they like to have for that. By default Browsers already support
these generic font families and users can configure which font to use then.
> I have the following choices:
>
> (1) how to provide the font to the reader
WOFF and WOFF2 like this:
@font-face {
font-family: "Lato";
src: url("/fonts/Lato/Lato-Regular.woff2") format("woff2"),
url("/fonts/Lato/Lato-Regular.woff") format("woff");
font-display: swap;
}
@font-face {
font-family: "Lato";
font-style: italic;
src: url("/fonts/Lato/Lato-Italic.woff2") format("woff2"),
url("/fonts/Lato/Lato-Italic.woff") format("woff");
font-display: swap;
}
@font-face {
font-family: "Lato";
font-style: normal;
font-weight: bold;
src: url("/fonts/Lato/Lato-Bold.woff2") format("woff2"),
url("/fonts/Lato/Lato-Bold.woff") format("woff");
font-display: swap;
}
@font-face {
font-family: "Lato";
font-style: italic;
font-weight: bold;
src: url("/fonts/Lato/Lato-BoldItalic.woff2") format("woff2"),
url("/fonts/Lato/Lato-BoldItalic.woff") format("woff");
font-display: swap;
}
There are other formats as well like EOT (Embedded OpenType) by
Microsoft or SVG Fonts used by older version of iOS. But nowadays just
using WOFF2 with a fallback to WOFF should be sufficent for most
visitors. If you then define the font family with a fall back as well,
the visitors will still have a text without any confusing change from
serif to sans-serif:
html,
button,
input,
select,
option,
optgroup,
textarea {
font-family: "Lato", sans-serif;
font-size: 1em;
The only way to check this is to use the devices and test it. But
usually there are some well-known fonts which already work quite well
like Lato or Roboto.
Otherwise consult a graphic designer who is specialized for online media.
> (1a) The easiest way is to use a font that is already installed on all
> reasonably expected systems and to provide a general specification of its
> features, e.g. „font-family: Georgia, serif;“: that is Georgia if installed,
[...]
No, that's not the easiest way since you then have to decide what
systems can be expected *and* what fonts there are. Also keep in mind
that over time the font stacks may change as well and older versions of
a system may not provide the same fonts as newer versions.
Providing webfonts is much easier. Even if you add the fonts in your
stylesheet Browsers will only load the fonts they really need for
rendering. And even 1-2 MB for the font files is not a big deal nowadays
where even mobile devices often have more than 10 MBit/s connection
speed and downloading 1 MB of data takes often less than 1 second.
> (1b) Another way is to provide a free – proprietary or not – font on my
> server and specify in the style sheets that it shall be downloaded from my
> site prior to use. Does the time for downloading matter until the user sees
> the contents? Are there any other drawbacks of this approach? What have I to
> do (up to now, I have not yet seen a straightforward recipe)?
No, see above. I maintain websites of which some have millions of
visitors each year and I never had any issue with performance because of
webfonts.
--
Arno Welzel
https://arnowelzel.de
> On Sat, 1 Apr 2023, Jukka K. Korpela wrote:
>
>> In fonts like Cambria, Times New Roman, FreeSerif, and Noto Serif, the
>> difference between italic a and italic alpha looks quite sufficient to my
>> eyes.
>
> I am offering information on web space (thus “authoring”) and I know that
> there are many fonts and many ways to specify fonts in stylesheets or perhaps
> elsewhere. I have still refrained from using that very much, because there
> are too many choices and I do not know where to begin. I would be grateful
> for any advice you may have from your experience.
or "sans-serif" and let the user choose in their Browser setting
whatever they like to have for that. By default Browsers already support
these generic font families and users can configure which font to use then.
> I have the following choices:
>
> (1) how to provide the font to the reader
@font-face {
font-family: "Lato";
src: url("/fonts/Lato/Lato-Regular.woff2") format("woff2"),
url("/fonts/Lato/Lato-Regular.woff") format("woff");
font-display: swap;
}
@font-face {
font-family: "Lato";
font-style: italic;
src: url("/fonts/Lato/Lato-Italic.woff2") format("woff2"),
url("/fonts/Lato/Lato-Italic.woff") format("woff");
font-display: swap;
}
@font-face {
font-family: "Lato";
font-style: normal;
font-weight: bold;
src: url("/fonts/Lato/Lato-Bold.woff2") format("woff2"),
url("/fonts/Lato/Lato-Bold.woff") format("woff");
font-display: swap;
}
@font-face {
font-family: "Lato";
font-style: italic;
font-weight: bold;
src: url("/fonts/Lato/Lato-BoldItalic.woff2") format("woff2"),
url("/fonts/Lato/Lato-BoldItalic.woff") format("woff");
font-display: swap;
}
There are other formats as well like EOT (Embedded OpenType) by
Microsoft or SVG Fonts used by older version of iOS. But nowadays just
using WOFF2 with a fallback to WOFF should be sufficent for most
visitors. If you then define the font family with a fall back as well,
the visitors will still have a text without any confusing change from
serif to sans-serif:
html,
button,
input,
select,
option,
optgroup,
textarea {
font-family: "Lato", sans-serif;
font-size: 1em;
}
> (2) which properties of the font to consider required or preferable
It should be readable on all devices you expect your visitors to use.
> (2) which properties of the font to consider required or preferable
The only way to check this is to use the devices and test it. But
usually there are some well-known fonts which already work quite well
like Lato or Roboto.
Otherwise consult a graphic designer who is specialized for online media.
> (1a) The easiest way is to use a font that is already installed on all
> reasonably expected systems and to provide a general specification of its
> features, e.g. „font-family: Georgia, serif;“: that is Georgia if installed,
No, that's not the easiest way since you then have to decide what
systems can be expected *and* what fonts there are. Also keep in mind
that over time the font stacks may change as well and older versions of
a system may not provide the same fonts as newer versions.
Providing webfonts is much easier. Even if you add the fonts in your
stylesheet Browsers will only load the fonts they really need for
rendering. And even 1-2 MB for the font files is not a big deal nowadays
where even mobile devices often have more than 10 MBit/s connection
speed and downloading 1 MB of data takes often less than 1 second.
> (1b) Another way is to provide a free – proprietary or not – font on my
> server and specify in the style sheets that it shall be downloaded from my
> site prior to use. Does the time for downloading matter until the user sees
> the contents? Are there any other drawbacks of this approach? What have I to
> do (up to now, I have not yet seen a straightforward recipe)?
visitors each year and I never had any issue with performance because of
webfonts.
--
Arno Welzel
https://arnowelzel.de
Arno Welzel
Apr 7, 2023, 11:39:54 AM4/7/23
to
Jukka K. Korpela, 2023-04-07 16:01:
[...]
Also see
<https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display>
However keep in mind that using "font-display: block;" may cause overall
delays. Also if a font was ever downloaded once it should be in the
cache and there effect of font swapping should not occur any longer.
With this in mind, using stuff like Google fonts - besides potential
privacy issues - may even be preferrable since many sites just load the
same fonts and it is very likely that visitors may already have the
desired font in their browser cache.
[...]
> If the download of the font is slow, it may happen that the browser
> first renders the page without it, using a default font, then redraws
> the page when it gets the font. Somewhat disturbing.
You can force the browser to wait a bit before displaying anything.
> first renders the page without it, using a default font, then redraws
> the page when it gets the font. Somewhat disturbing.
Also see
<https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display>
However keep in mind that using "font-display: block;" may cause overall
delays. Also if a font was ever downloaded once it should be in the
cache and there effect of font swapping should not occur any longer.
With this in mind, using stuff like Google fonts - besides potential
privacy issues - may even be preferrable since many sites just load the
same fonts and it is very likely that visitors may already have the
desired font in their browser cache.
Arno Welzel
Apr 7, 2023, 11:44:39 AM4/7/23
to
Stan Brown, 2023-04-07 17:03:
> On Fri, 7 Apr 2023 17:01:30 +0300, Jukka K. Korpela wrote:
>> Helmut Richter wrote:
>>> (1b) Another way is to provide a free ? proprietary or not ? font on my
>>> server and specify in the style sheets that it shall be downloaded from my
>>> site prior to use. Does the time for downloading matter until the user sees
>>> the contents?
>>
>> It may, but this is probably not a big issue these days in most
>> circumstances.
>>
>>> Are there any other drawbacks of this approach?
>>
>> If the downloadable font is on a server different from that of the HTML
>> document, it may happen that the page is loaded without the font. In
>> this case, a default font (as defined in font-family or the browser
>> configuration) will be used instead.
>>
>> If the download of the font is slow, it may happen that the browser
>> first renders the page without it, using a default font, then redraws
>> the page when it gets the font. Somewhat disturbing.
>
> I wonder if this is what's happening with aarp.org. (For non-US
[...]
Maybe - but the way how that site behaves is really weird. I have never
since shuch a strong font swapping effect. And even if the font is
already cached, font swapping still happens. To me this looks like the
result of the CMS they use.
For comparison see my own website: <https://arnowelzel.de/en/>
The very first time you load it, you *may* notice font swapping. But
when reloading the site or opening any article, this should not happen
again since the font is then cached and does not need to be swapped again.
> On Fri, 7 Apr 2023 17:01:30 +0300, Jukka K. Korpela wrote:
>> Helmut Richter wrote:
>>> (1b) Another way is to provide a free ? proprietary or not ? font on my
>>> server and specify in the style sheets that it shall be downloaded from my
>>> site prior to use. Does the time for downloading matter until the user sees
>>> the contents?
>>
>> It may, but this is probably not a big issue these days in most
>> circumstances.
>>
>>> Are there any other drawbacks of this approach?
>>
>> If the downloadable font is on a server different from that of the HTML
>> document, it may happen that the page is loaded without the font. In
>> this case, a default font (as defined in font-family or the browser
>> configuration) will be used instead.
>>
>> If the download of the font is slow, it may happen that the browser
>> first renders the page without it, using a default font, then redraws
>> the page when it gets the font. Somewhat disturbing.
>
> I wonder if this is what's happening with aarp.org. (For non-US
Maybe - but the way how that site behaves is really weird. I have never
since shuch a strong font swapping effect. And even if the font is
already cached, font swapping still happens. To me this looks like the
result of the CMS they use.
For comparison see my own website: <https://arnowelzel.de/en/>
The very first time you load it, you *may* notice font swapping. But
when reloading the site or opening any article, this should not happen
again since the font is then cached and does not need to be swapped again.
Jukka K. Korpela
Apr 8, 2023, 1:25:32 PM4/8/23
to
Stan Brown wrote:
> On Fri, 7 Apr 2023 17:01:30 +0300, Jukka K. Korpela wrote:
– –
> On Fri, 7 Apr 2023 17:01:30 +0300, Jukka K. Korpela wrote:
>> If the download of the font is slow, it may happen that the browser
>> first renders the page without it, using a default font, then redraws
>> the page when it gets the font. Somewhat disturbing.
>
> I wonder if this is what's happening with aarp.org. (For non-US
> folks, AARP is an organization for persons over 50, and it has
> millions of members.) Every single page -- every one that I've seen,
> anyway -- paints, then blanks and repaints. I figured it was bad
> scripting, but maybe it's this font thingy.
It isn’t scripting: with JavaScript disabled, the font flash is still there.
>> first renders the page without it, using a default font, then redraws
>> the page when it gets the font. Somewhat disturbing.
>
> I wonder if this is what's happening with aarp.org. (For non-US
> folks, AARP is an organization for persons over 50, and it has
> millions of members.) Every single page -- every one that I've seen,
> anyway -- paints, then blanks and repaints. I figured it was bad
> scripting, but maybe it's this font thingy.
The problem is probably caused by the placement of the <link> element
that refers to the Google font Lato. It is placed near the end of the
<body> element, violating HTML syntax. Browsers still interpret such
misplaced elements, but when the browser reaches that element, it has
already processed the <head> part and started rendering the document
body, using font-family: Lato, sans-serif and therefore the browser’s
default sans-serif font, since no Lato font is available at that point.
Yucca
Arno Welzel
Apr 8, 2023, 3:18:04 PM4/8/23
to
Jukka K. Korpela, 2023-04-08 19:25:
> Stan Brown wrote:
>
>> On Fri, 7 Apr 2023 17:01:30 +0300, Jukka K. Korpela wrote:
> – –
>>> If the download of the font is slow, it may happen that the browser
>>> first renders the page without it, using a default font, then redraws
>>> the page when it gets the font. Somewhat disturbing.
[...]
webmaster of <https://www.aarp.org>. Hopefully they fix that.
> Stan Brown wrote:
>
>> On Fri, 7 Apr 2023 17:01:30 +0300, Jukka K. Korpela wrote:
> – –
>>> If the download of the font is slow, it may happen that the browser
>>> first renders the page without it, using a default font, then redraws
>>> the page when it gets the font. Somewhat disturbing.
> The problem is probably caused by the placement of the <link> element
> that refers to the Google font Lato. It is placed near the end of the
> <body> element, violating HTML syntax. Browsers still interpret such
> misplaced elements, but when the browser reaches that element, it has
> already processed the <head> part and started rendering the document
> body, using font-family: Lato, sans-serif and therefore the browser’s
> default sans-serif font, since no Lato font is available at that point.
Nice find. Yes, this is the problem. I'll write about this to the
> that refers to the Google font Lato. It is placed near the end of the
> <body> element, violating HTML syntax. Browsers still interpret such
> misplaced elements, but when the browser reaches that element, it has
> already processed the <head> part and started rendering the document
> body, using font-family: Lato, sans-serif and therefore the browser’s
> default sans-serif font, since no Lato font is available at that point.
webmaster of <https://www.aarp.org>. Hopefully they fix that.
Stan Brown
Apr 9, 2023, 3:20:45 PM4/9/23
to
On Sat, 8 Apr 2023 21:18:01 +0200, Arno Welzel wrote:
>
> Jukka K. Korpela, 2023-04-08 19:25:
>
> > Stan Brown wrote:
> >
> >> On Fri, 7 Apr 2023 17:01:30 +0300, Jukka K. Korpela wrote:
> > ? ?
>
> Jukka K. Korpela, 2023-04-08 19:25:
>
> > Stan Brown wrote:
> >
> >> On Fri, 7 Apr 2023 17:01:30 +0300, Jukka K. Korpela wrote:
> >>> If the download of the font is slow, it may happen that the browser
> >>> first renders the page without it, using a default font, then redraws
> >>> the page when it gets the font. Somewhat disturbing.
> [...]
> > The problem is probably caused by the placement of the <link> element
> > that refers to the Google font Lato. It is placed near the end of the
> > <body> element, violating HTML syntax. Browsers still interpret such
> > misplaced elements, but when the browser reaches that element, it has
> > already processed the <head> part and started rendering the document
> > body, using font-family: Lato, sans-serif and therefore the browser?s
> >>> first renders the page without it, using a default font, then redraws
> >>> the page when it gets the font. Somewhat disturbing.
> [...]
> > The problem is probably caused by the placement of the <link> element
> > that refers to the Google font Lato. It is placed near the end of the
> > <body> element, violating HTML syntax. Browsers still interpret such
> > misplaced elements, but when the browser reaches that element, it has
> > already processed the <head> part and started rendering the document
> > default sans-serif font, since no Lato font is available at that point.
Thanks, Jukka! This has been an annoyance for as long as I can
remember, and it's nice at least to know the cause.
> Nice find. Yes, this is the problem. I'll write about this to the
> webmaster of <https://www.aarp.org>. Hopefully they fix that.
hope. Please let us know what kind of reply you get, if any.
0 new messages