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

On 08/12/10 22:06, John Daggett wrote:
> 
> Hi Behdad,
> 
> Thanks for the comments!

Hi John and others,

Thanks for all the feedback and sorry that I'm replying so late.


>> 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?

The confusion rising from the following sentence in the spec: "Some scripts,
such as Arabic, are almost always cursive."  This may suggest that the other
generic families are not applied to Arabic.  In fact, I suggest removing that
sentence and making rewriting the cursive paragraph to be more about
free-form, handwriting-like, fonts as opposed to a canonical definition of
connects / doesn't connect.


>> 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.  

Right.  The following sentence in the spec:

  "The sole criterion of a monospace font is that all glyphs have the same
fixed width."

contradicts the fact that 'monospace' CJK fonts do exist.  Hence my suggestion.


>> 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.

It's not about whether user agents should or should not.  It's about what's
permissible by CSS.  When CSS does explicitly allow synthesized font-weight
and font-style, I don't think CSS must disallow synthesized font-stretch.
That would be a double-standard.


>> 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.

Right.  I though about that first.  I think font-scale as you propose is
useful.  However, we also need to have a solution for what I call the
'composite' font.  Something like:

@font-face {
  font-family: My Sans;
  src: url(...iranian-sans.ttf);
  src: url(...dejavu-sans.ttf);
}

The idea being: "use Iranian Sans if it covers the range, otherwise fall back
to DejaVu Sans."  Is something like this in the scope of @font-face?  Or the
scope of @font-face is really just one family?  If the latter, then I agree
that font-scale is preferred.

Humm. Thinking more about it, I see that this is the way one can implement a
composite font:

@font-face {
  font-family: My Sans;
  src: url(...iranian-sans.ttf);
}

@font-face {
  font-family: My Sans;
  src: url(...dejavu-sans.ttf);
}

In that case, font-scale is just fine.

[snip]

>> 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)).

I like both those suggested syntaxes.


> 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.

Not sure how OpenType solves the first case, but I want to focus on the
second.  To me, TTC is more about having one file per family.  Say, you have
your company's logo type.  Much easier to have one file for regular, bold,
italic, etc, than keeping multiple files.  Plus, clients can download
partially if they decide to.  Plus, if all faces are used, it's actually faster.

Again, I'm just suggesting that CSS should aim for supporting OpenType as is
instead of pick and choose which parts it supports.


>> Issue: should @font-face rules be able to reference other @font-face's?
> 
> Ok, I'm stumped.  Why?

Nevermind.


>> 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?

Sure, why not?  The spec builds such a family for demonstration even!  Example
XIV unifies DroidSansFallback, DroidSansJapanese, and DroidSans into a single
unified DroidSans family.  We do exactly that in Linux using fontconfig.


>  Hmmm, sounds kind of sucky from a performance perspective

Why?


>> 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.

Donno.  I read that paragraph as a whitelist of what is allowed.  Maybe it's
just me not used to interpreting CSS specs correctly.


>> 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.


Let me use an example:

  <div style="font-feature-settings: scap=1;">
    Some text here.
    <span style="font-family: MyLogo; font-feature-settings: aalt=2;">LOGO</span>
  </div>

Now, intuitively one would expect that the scap feature is applied to the
entire div.  But setting aalt unsets the scap.  That's why IIUC the earlier
proposals added one attribute per OpenType feature.  I understand why that
earlier proposal is not feasible, but I think this is a serious issue that the
spec needs to address.


>> 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?

Sorry, my bad.  I mean, I suggest the spec leaves it undefined to use values
other than 0 or 1 for boolean features.  I don't have any specific reason for
this except that, for example, in hb-ng, it will be limiting to use large
integers there.  Since I don't see any compelling reason for allowing
arbitrary integers for boolean features, I'd rather err on the side of caution.


>> 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.

The same way that font families with space in the name can be escaped by using
double-quotes, freely-defined features can be escaped if necessary.
Personally, I like something along these lines more:

  font-feature-settings: opentype(aalt=1, ...);

For the record, we've had very similar discussion around the feature API in
harfbuzz-ng.  I'm interested to see how CSS decides to do it.


>> 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?


The BCP 47 has an extension mechanism.  If we request and get, for example, an
OpenType extension with the letter 'o', one can then use something like
'tr-o-srb' to request the 'SRB ' OpenType language system even though the text
is marked Turkish.

Thinking about it again, I agree that it doesn't help the case of wanting to
override that per font via CSS.

Not a huge fan of font-language-override, but I think I can live with it.


Cheers,
behdad


> Again, thanks for taking the time to review the draft!
> 
> Regards,
> 
> John Daggett
> 
>

Received on Wednesday, 25 August 2010 22:47:26 UTC