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

[css3-fonts] Font Feature Properties: Copyedits

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 23 May 2013 12:40:53 +0800
Message-ID: <519D9DD5.4030809@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
(I kinda wonder if the Japanese have different punctuating
habits, because you have more run-on sentences than anyone
else I've copyedited...)

http://dev.w3.org/csswg/css-fonts/#font-rend-props

  # the font-variant property has been expanded for CSS3,
  # it now functions as a shorthand for a set of properties
  # that provide control over stylistic font features.

s/font-variant/'font-variant'/ so that it autolinks
s/,/:/ to fix run-on sentence; alternately, start a new sentence

  # Simple fonts used for displaying Latin text use a very
  # basic processing model, fonts contain a character map
  # which maps a given character to a glyph for that character.

s/,/:/
s/a given/each/

  # Glyphs for subsequent characters are simply placed next
  # in line along a run of text.

I think s/next in line/one after the other/ is clearer.

   # Font formats such as OpenType and AAT (Apple Advanced'
   # Typography) use a richer processing model, the glyph
   # for a given character can be chosen and positioned not
   # just based on a single character, but also based on
   # surrounding characters along with the language, script,
   # and features enabled for the text. Font features may be
   # required for specific scripts, or recommended as enabled
   # by default or they may be stylistic features meant to be
   # used under author control.

s/Font formats/Modern font formats/ to match wording you have
elsewhere

s/, the glyph/. The glyph/ to fix run-on

s/based on a single character/based on the character it represents/
s/but also based on/but also on/
s/along with/as well as/

Replace "may" with either "can" or "might", as this is not
correct RFC2119 usage.

   # Stylistic font features can be classified into two broad
   # categories, ones that affect the harmonization of glyph
   # shapes with the surrounding context, such as kerning and
   # ligature features, and those such as the small-caps,
   # subscript/superscript and alternate features that affect
   # shape selection.

s/categories, ones/categories: ones/ because the correct
punctuation for this grammatical relationship is in fact
a colon.

Either replace "ones" with "those" or "those" with "ones"
so that you're using the same structure in both branches.
(Fix parallelism.)

Merge this sentence with the next paragraph, since they're
all the same topic and fit together well. This sentence
then serves as the introductory sentence to the paragraph.

  # The subproperties of font-variant listed below

sub-properties (missing hyphen), 'font-variant' (autolink)

  # these stylistic font features; they do not

Start a new sentence here. The link is not strong enough
to warrant a semicolon, and shorter sentences are easier
for people to grok.

  # They affect glyph selection and positioning, they do
  # not affect font selection

Suggest

  | The properties in this section only affect [...]

Also s/,/;/ to fix run-on...

   # and must be considered normative.

Another incorrect use of RFC2119... you're trying to assert
a conformance clause on the spec reader. Just say

   | and are normative.

  # Languages often share a common script but the shape of
  # certain letters may vary across those languages, such
  # as the variations in certain Cyrillic letters used in
  # Russian and Bulgarian text.

Would suggest rewriting as

  | Many languages share a common script, but the shape of
  | certain letters can vary across those languages. For
  | example, certain Cyrillic letters have different shapes
  | in Russian text than in Bulgarian.

What I'm doing here:
   * de-emphasizing "languages"; your wording gives it more
     emphasis, subtly implying a switch of topic. But we don't
     want to switch topics. The important part of this sentence
     is the second half, the way letters vary, not the way
     languages share scripts.
   * Comma before "but" that joins two full clauses; this
     is required in English.
   * s/may/can/ to avoid using RFC2119 terms where inappropriate
   * Shorten the sentence by splitting it. Shorter sentences
     are generally better for understandability, since they
     have less complex structure and require less working memory.

   # If the content language of the element is known, according
   # to the rules of the document language, user agents are
   # required

Remove the comma between "known" and "according". Currently,
because the phrase "according ... language" is surrounded
by commas, it's unclear whether it belongs to "known" or it
belongs to "user agents are required". Removing the comma
before it, and leaving the one after, solves this ambiguity.

~fantasai

P.S.

   # Should user agents be allowed to infer the OpenType language
   # or simply use only the default language system?

Note, we discussed this at the Tucson F2F, see the minutes starting
>    jdaggett: Another issue is wrt default [?]
>    <jdaggett> http://dev.w3.org/csswg/css3-fonts/#language-specific-support
>    jdaggett: This deals with language-specific features
>    jdaggett: Question is, whether UAs should by default always
>              use the default system, or use heuristics to guess
>              language
http://lists.w3.org/Archives/Public/www-style/2013Feb/0391.html
Received on Thursday, 23 May 2013 04:41:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 23 May 2013 04:41:27 UTC