- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 22 May 2013 15:06:32 +0800
- 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