Re: [csswg-drafts] [css-fonts] Specifying changes to parameters for fallback fonts

One difficulty here is that there is no way in CSS to say whose 
version of a font with a given name you want. In most cases all 
Baskerville fonts are the same - but what if there's one with pictures
 of dogs in it? Traditionally the font vendor would be named, e.g. 
Adobe Baskerville, and often these days include vendor names in the 
font name, but for example on my system I have 228 variants of 
Helvetica, many installed by different programs. The per-glyph 
fallback on a site that uses Helvetica means I start with a 
randomy-chosen Helvetica, then might get e.g. fi ligatures from a 
different one. I quite often see Web sites with the fi/fl/ff ligatures
 obviously in a different font, for example bolder when the font names
 didn't fit into the CSS 100-step boldness categories.

So there are several steps,
(1) choosing a base font family, which as Tab says needs some 
high-level work, e.g. to choose the first font family from a list, 
where that family has fonts to support roman and italic for a given 
character range along with specific other features, such as having a 
condensed variant, or having true small capitals;
(2) choosing a base font within that font family, without wandering 
off into some unrelated font that happens to have the same font name 
but came from a different vendor or foundry
(3) potentially modifying that chosen font, e.g. to simulate bold or 
oblique (ugh but there we go) or to condense or stretch it (some 
implementations do this if font-stretch is specified; others will only
 select a font that already exists with a corresponding font matrix 
(!) and at least one will simply leave blank gaps in the output where 
hte text shold be if font-stretch doesn't match)
(4) per-character and per-glyph fallback as needed, going back to step
 (2) and then repeating step (3).

Right now CSS fonts doesn't seem to give clear control over these 
steps, leading to some odd effects such as those you (Richard) see.

Selecting based on platform is not the right approach though - e.g. 
Richard left out Linux or Android, and desktop macs have different 
fonts perhaps than iphones, as do differing versions of Microsoft 
Windows. And many users have fonts that are from different platforms, 
whether from dual booting or (probably much more often) from 
installing applications that in turn installed fonts.  The test should
 be for specific versions of fonts, or at the least specific foundries
 an capabilities (just like writing portable C or C++ tests for 
features, not for platform).

GitHub Notification of comment by liamquin
Please view or discuss this issue at 
using your GitHub account

Received on Sunday, 29 May 2016 02:11:21 UTC