W3C home > Mailing lists > Public > www-style@w3.org > May 2013

[css3-fonts] Font Matching Algorithm: Comments II

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 22 May 2013 15:06:32 +0800
Message-ID: <519C6E78.2020400@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
http://dev.w3.org/csswg/css-fonts/#cluster-matching
   # When text contains characters such as combining
   # diacritics, ideally the base character should be
   # rendered using the same font as the diacritic,
   # this assures proper placement of the diacritic.

I think it would be nice to make this sentence a little
more generic, wrt combining marks in general not just
diacritics. Diacritics are relatively easy; there are
more amusing changes with other kinds of combining marks.

Here's my half-baked try at making it more generic...

   | When text contains characters such as combining
   | marks, ideally the combining mark should be
   | rendered using the same font as the base character,
   | as this assures proper placement of diacritics and
   | shaping of glyph combinations.


   # Codepoint sequences consisting of a base character followed
   # by a sequence of combining characters are treated slightly
   # differently, see the section on cluster matching below.

This is covered normatively in the algorithm. If you want to
draw attention to this fact, I suggest making this a
<p class="note"> at the end of the section. (I say at the end,
rather than up front, because it's not really introductory
material. The green will be eye-catching enough; it needn't
be up front, distracting people who don't care from understanding
fundamental concepts like "grapheme cluster" and "character map".)

   # A font is considered to support a given character if

<dfn> the word support. This is a *great* definition. Can we
use it in the previous section ("font matching"), instead of
the rather less precise prose that's already there?

I'd also pull out the definition of character map from there
and put it in the same paragraph as this, so that they're
together.

So, in my view of the spec, "Matching font styles" would start
with a paragraph containing

   1. The sentence summarizing the algorithm, as currently,
      with s/exists for/<i>supports</i>/ in
        "whether a glyph exists for a given character"
   2. The sentence defining "supports".
   3. A sentence defining "character map".
   4. The sentence about legacy fonts lacking shaping support
   5. The sentence about cluster matching being defined later.

(Alternately, pull out #4 into a note. It's more of an
informative aside, anyway.)

Example:

   5.2 Matching font styles

   In CSS, fonts are chosen per character by iterating over
   the families named by the 'font-family' property, selecting
   those faces that match the style specified by the other
   font-matching properties, and choosing the first face of the
   matching faces that supports the given character. A font is
   considered to <dfn>support</dfn> a given character if (1)
   the character is contained in the font's character map and
   (2) if required by the containing script, shaping information
   is available for that character. The <dfn>character map</dfn>
   of the font is data which maps each character supported by
   the font to the font's default glyph for that character.
   Some legacy fonts may include a given character in the
   character map but lack the shaping information (e.g. OpenType
   layout tables or Graphite tables) necessary for correctly
   rendering text runs containing that character. Codepoint
   sequences consisting of a base character followed by a
   sequence of combining characters are treated specially,
   see the section on cluster matching below.

With the edits above, we now have the definition of grapheme
cluster much closer to our introductory sentences for this
section, which is good for cohesion.

   # Note: a sequence with more than one variation selector
   # is treated as an encoding error and the trailing selectors
   # are ignored.

This seems like a normative statement, so shouldn't be preceded
with "Note:". Or is that the behavior defined by Unicode, hence
this is just an informative reminder? (In which case, drop a
reference to Unicode.)

   # longest sequence that is completely matched by a font ...

s/matched/supported/

~fantasai
Received on Wednesday, 22 May 2013 07:07:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 22 May 2013 07:07:03 UTC