Re: [css3-fonts] Behdad's Feedback on CSS Fonts Module Level 3 Editor's Draft 5 April 2010

Hi Behdad,

Thanks for the comments!

> To reduce confusion I suggest adding Arabic specimen to the serif,
> sans-serif, and monospace generic samples.  

Sounds good, but what's the confusion you're referring to?  What
generic names might map to in non-Latin fonts?

> Under monospace, it may be worth talking about CJK.  Most CJK
> monospace fonts have ideographs that take twice the space of
> non-ideograph glyphs, and I think those are acceptable "monospace"
> fonts.

Sort of.  CJK fonts typically contain both half-width and full-width
versions of Latin letters.  The half-width versions are mapped to the
ASCII range, the full-width versions to U+FF00-FFEF range.  A
"monospace" CJK font usually implies the half-width versions are
monospaced rather than proportionally spaced.  The full-width versions
are always a fixed width.  

> 3.3 Font width: the font-stretch property
> 
> Add a hint that agents may synthesize stretch?

I don't think user agents should synthesize stretch.  With CSS
transforms, authors can stretch or squish text if like this if they
like but I don't think it should be something done automagically by
user agents.

> 3.6 Relative sizing: the font-size-adjust property
> 
> I think this is a big hack.  To begin with, there's no x-height for
> most non-Western scripts.  How is that supposed to work?

In some sense, yes, it's trying to add a feature in a way that doesn't trip up
older user agents.  And it's clearly Western-centric.

> On a related note, would be useful to allow scaling fonts defined in
> @font-face rules.  A syntax like:
> 
> @font-face {
>   font-family: Gentium;
>   src: url(http://site/fonts/Gentium.ttf) at 110%;
> }
> 
> for example.  When mixing Arabic and Latin fonts, such adjustments
> are typically desired.

I think this is an interesting idea, I know the same adjustments are often
needed for mixing CJK with Latin fonts.  But I think you want a different
descriptor for this, not additional src descriptor syntax.  Something like this?

  font-scale: normal | <number>

The value 'normal' would imply a scaling factor of 1.0, and <number>
would be a value greater than 0 representing a scale factor to be
applied to the font-size when the font is used.

> 4.3 Font reference: the src descriptor
> 
> This part of the text:
> 
>         Conformant user agents must skip downloading a font resource if the
>         format hints indicate only unsupported or unknown font formats.
> 
> I suggest using "may".  If the font is not skipped, it's downloaded,
> garbage found, and skipped.  So there is no need for the "must".

No, the 'must' is important here.  Basically if a format is supported
by a user agent, it downloads it, otherwise it moves to the next
format.  If user agents download and test everything in the src list,
there's no reason for the hint.  This allows a given user agent to
support a new font format without impacting the behavior of older
clients, authors can rely on the fact that older user agents will
*always* ignore the new format and not eat up server bandwidth.

> Moreover, the property mixes two different notions: the font
> container, and the smart font technology.  For example, what would
> one put in there for a AAT font in WOFF wrapper?

The format hint is simply asking the question "is this font format
supported?", it's not specifically identifying a "container" format.
You're right, the line is blurred with regard to AAT, adding
"truetype-aat" was the only way to make it possible to serve an AAT
font to OSX clients and an OpenType font to non-OSX clients, since OSX
still doesn't fully support OpenType shaping of some complex scripts.

It's simple enough to add "woff-att" but I doubt this will ever be
implemented since most user agents are moving towards full support of
OpenType.


> Issue: the src as it is designed right now, makes it impossible to
> use TrueType Collection fonts.

Yes, additional syntax would be needed to support fonts packaged in
TrueType collection format.  Some form of fragment id would need to be
defined (e.g. src: url(myfont.ttc#regular) or src: url(myfont.ttc#1)).

But I'm not sure I see much of a use case for this.  From what I've
seen, TrueType collections are used as (1) a way of sharing glyphs
across proportional and monospaced faces of Japanese fonts and (2) as
a simple container of multiple fonts.  The first case is no longer
really needed, since OpenType features allow control over proportional
vs. monospaced glyph selection. In the second case, I'm not sure I see
the advantage of downloading a container that simply has a set of
faces in it.  It will make the load time slower and won't really
change behavior.

> Issue: should @font-face rules be able to reference other @font-face's?

Ok, I'm stumped.  Why?

> 5 Font matching algorithm
> 
> This sentence:
> 
>         If two faces have the exact same style characteristics, one of
>         them is ignored.
> 
> should be removed IMO.  If two fonts have the same style properties
> but different coverages, they are both useful.  Indeed, Linux
> platforms do such things.

So you want to have lots of fonts in the same family with the same
style characteristics, each with a different cmap?  Hmmm, sounds kind
of sucky from a performance perspective but I think the wording can be
reworked to allow for this. There's also the problem that coverage can
vary across fonts within a family.  Older versions of Arial did this,
the italic face omitted glyphs for Arabic but the regular face had
them.  I think the STIX math fonts did some similar sort of thing.

> This part:
> 
>         2. If the family name is a generic family name, the user agent looks
>         up the appropriate font family name to be used. User agents may
>         choose the generic font family to use based on the language of the
>         containing element or the Unicode range of the character.
> 
> Why allow a per-Unicode-range selection but not per-character?  For
> example, what would happen of the per-language or per-Unicode-range
> family doesn't support the character at hand?  Currently, my reading
> suggests that the generic matching fails and we move to the next
> family.  Whereas I think the right thing to do would be to find a
> generic font that supports the character.

I don't think there's anything in the wording there that prevents
this.  Different user agents handle generics in a variety of ways.
Firefox has per-language definitions of these, Opera defines them
based on the code range.  If the defined fonts don't support a given
character, then system fallback occurs.  As part of that system
fallback, I think it's would make total sense to choose a font that
best matched the style and the generic type if that's possible.  This
is really up to the user agent to decide based on what's available on
a given platform, I don't see how the wording you've highlighted
disallows this.

> 6.9 Low-level font settings control: the font-feature-settings property
> 
> The main issue I see with this is that setting a feature breaks
> inheritance and essentially unsets any features set higher in the
> document hierarchy. Say, I can't enable a feature on <body> and have
> it affect the entire document if I also want to control a totally
> unrelated feature on some elements.  To resolve that, the "Computed
> value" needs to change to accumulate the specific feature setting to
> what's inherited.  A value setting of normal (possible followed by
> more settings) can be used to break the inheritance.  Most probably
> I don't understand how CSS inheritance really works.  Otherwise, I
> don't see why an 'inherit' value is not among the possible values
> for font-feature-settings.

Properties in CSS don't "accumulate".  For a given element a single
set of CSS rules apply, if both 'font-feature-settings' and other
font-variant settings are set to something other than 'normal', then
the rules defined in section 7 are used to resolve the exact feature
settings.  All properties implicitly define 'inherit' which simply
implies 'use the rule that applies to my parent'.  There's been some
back-and-forth as to whether specs should explicitly include 'inherit'
in property value lists or not, I will add that in for
'font-feature-settings' to be consistent with other properties.

> The text mentions:
>         For OpenType features that are boolean in nature, a value of 0
>         disables the feature and a non-zero value enables the feature.
> 
> I suggest using 1 for enabling boolean features and an undefined behavior if
> other values are used.

I think we want an explicit way to disable features, with the proviso
that other enabling/disabling other features may implicitly affect
that state.  Was that your concern here?

> Moreover, would be nice to have a way to specify that a specific
> setting is an OpenType feature tag, and have an extension mechanism
> for future additions of AAT and possibly other systems. 
> Alternatively, the current method can be used, and any engine just
> pickup whatever provided features that apply to the underlying font
> format.

I'm planning on revising the format here.  See the discussion here:

  http://lists.w3.org/Archives/Public/www-style/2010Jun/0500.html

Right now my thoughts are to make this match OpenType feature tags
with a defined syntax. Jonathan Kew thinks that if we do that, we
should make the property name be explicitly name xxx-opentype. 
Mapping AAT features is hard because they can be freely defined via
entries in the 'feat' table.

> 6.10 Font language override: the font-language-override property
> 
> In this sentence:
> 
>         The value of ‘normal’ implies that when rendering with OpenType fonts
>         the language of the document is used to infer the OpenType language
>         system
> 
> Is "document language" really what should be used, or the XML
> language of the element at hand?

This should be revised to indicate that the OpenType language must
be inferred from the value of the 'lang' attribute of the containing
element.

> Another way to address the issue this tag tried to address would be
> to register a BCP 47 Extension subtag for OpenType LangSys.

Could you describe this a bit more?

Again, thanks for taking the time to review the draft!

Regards,

John Daggett

Received on Friday, 13 August 2010 02:07:25 UTC