[css-fonts-4] I18n self-review checklist

[svgeesus]

Short i18n review checklist is here

1. If the spec (or its implementation) contains any natural language text that will be read by a human (this includes error messages or other UI text, JSON strings, etc, etc),

   This specification is not used to generate text.

2. If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics.

   Yes, this is the main focus of this specification. See following comments.

3. If the spec (or its implementation) allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc.

   No

4. If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers

   In general no. However, see Localized name matching for matching on localized font names. For example, an implementation must match on 굴림체 (Korean) as well as GulimChe (Latin)

5. If the spec (or its implementation) sorts text

   No

6. If the spec (or its implementation) captures user input

   No

7. If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries

   No

8. If the spec (or its implementation) allows any character encoding other than UTF-8.

   Characters are processed as Unicode codepoints. Character encoding is not dealt with in this specification. The unicode-range descriptor defines the set of Unicode codepoints that may be supported by the font face for which it is declared. This serves as a download hint (don't download fonts that won't cover the text you are trying to render) and also a way to disallow use of a font for codepoint ranges that you don't want to be used.

9. If the spec (or its implementation) defines markup.

   No

10. If the spec (or its implementation) deals with names, addresses, time & date formats, etc

    No

11. If the spec (or its implementation) describes a format or data that is likely to need localization.

    No

12. If the spec (or its implementation) makes any reference to or relies on any cultural norms

    Yes, some font choices are informed by cultural norms such as the association of particular typefaces with expected usage (formal, playful, archaic, governmental, religious)

[svgeesus]

Text decoration

1. Text decoration such as underline and overline should allow lines to skip ink.

Not handled here. Addressed in CSS Text 4 Line Decoration: Underline, Overline, and Strike-Through in particular the text-decoration-skip shorthand and its sub-properties

2. It should be possible to specify the distance of overlines and underlines from the text.

Not handled here. Addressed in CSS Text 4 Text Underline Position: the text-underline-position property

[svgeesus]

Vertical text

In general, the requirements below are handled in CSS Writing Modes 4, Vertical Writing Modes rather than this specification.

However, in this specification:

• the font-kerning property handles both horizontal and vertical kerning (OpenType features kern and vkrn respectively)

• Default features place additional requirements on vertical text:

For upright text within vertical text runs, vertical alternates (OpenType feature: vert) must be enabled.

1. It should be possible to render text vertically for languages such as Japanese, Chinese, Korean, Mongolian, etc.

2. Vertical text must support line progression from LTR (eg. Mongolian) and RTL (eg. Japanese)

3. By default, text decoration, ruby, and the like in vertical text where lines are stacked from left to right (eg. Mongolian) should appear on the same side as for CJK vertical text. Placement should not rely on the before and after line locations.

4. Vertical writing modes that are equivalent to the vertical- values in CSS (only) should use UTR50 to apply default text orientation of characters. (This does not apply to writing modes that are equivalent to sideways- in CSS.)

5. By default, glyphs of scripts that are normally horizontal should run along a line in vertical text such that the top of the character is toward the right side of the vertical line, but there should also be a mechanism to allow them to progress down the line in upright orientation. Such a mechanism should use grapheme clusters as a minimum text unit, but where necessary allow syllabic clusters to be treated as a unit when they involve more than one grapheme cluster.

6. Upright Arabic text in vertical lines should use isolated letter forms and the order of text should read top to bottom.

7. It should be possible for some sequences of characters (particularly digits) to run horizontally within vertical lines (tate chu yoko).

8. Writing modes should provide values like sideways-lr and sideways-rl in CSS to allow for vertical rotation of lines of horizontal script text. UTR50 is not applicable for these cases.

[svgeesus]

Setting box positioning coordinates when text direction varies

The requirement below is handled in CSS Writing Modes 4, Vertical Writing Modes rather than this specification.

1. Box positioning coordinates must take into account whether the text is horizontal or vertical.

[svgeesus]

Ruby text annotations

In general, the requirements below are handled in CSS Ruby Layout Module Level 1 rather than this specification.

However, in this specification,

• the section Multi-valued feature value definitions contains an example which uses ruby-style annotations for the reading of a Byzantine seal.

• The font-variant-east-asian property also included in the CSS Fonts 3 Recommendation includes a value ruby which:

Enables display of ruby variant glyphs (OpenType feature: ruby). Since ruby text is generally smaller than the associated body text, font designers can design special glyphs for use with ruby that are more readable than scaled down versions of the default glyphs. Only glyph selection is affected, there is no associated font scaling or other change that affects line layout.

In other words, this works in conjunction with CSS Ruby, not as an alternative to it.

1. Ruby style annotations alongside base text should be supported for Chinese, Japanese, Korean and Mongolian text, in both horizontal and vertical writing modes.

2. Ruby implementations should support zhuyin fuhao (bopomofo) ruby for Traditional Chinese.

3. Ruby implementations should support a tabular content model (such that ruby contents can be arranged in a sequence approximating to rb rb rt rt).

4. Ruby implementations should make it possible to use an explicit rb tag for ruby bases.

5. ​Ruby implementations should allow annotations to appear on either or both sides of the base text.

[svgeesus]

Miscellaneous

The following items do not seem to relate to the functionality of this specification; they are dealt with in, for example, CSS Text 3 line breaking

1. Line heights must allow for characters that are taller than English.

2. Box sizes must allow for text expansion in translation.

3. Line wrapping should take into account the special rules needed for non-Latin scripts

4. Avoid specifying presentational tags, such as b for bold, and i for italic.

[svgeesus]

Other notable items

• the font-language-override property (previously in Fonts 3, moved to Fonts 4 for lack of implementations):

authors may need to specify a language system that differs from the content language, for example due to the need to mimic another language’s typographic traditions

• The font-variant-emoji property

allows web authors to select whether emoji presentation or text presentation is used for certain emoji code points ... Only the code points listed by Unicode as contributing to a Unicode emoji presentation sequence are affected by this property.

• expanded set of Generic Font families including Fangsong. Current open issue on what generics are for.

[r12a]

Thanks for this @svgeesus. Nicely done. I'll ask the i18n WG (including myself) to look at the details in the spec for items that you've highlighted, and we'll raise separate issues for any comments that arise, if any.

[r12a]

There are one or two issues already open (eg. for generic font families). I added just one other small one at #5295

Otherwise this all looks good to me. Thanks.

[svgeesus]

Thanks for the report, @r12a.

• There is the privacy/fingerprinting local font issue, whose mitigation has a significant I18n component limit local fonts to those selected by users in browser settings

• And the whole slew of generic font issues, whose meta-issue is Criteria for generic font families with a list of related issues

• Handling of Standardized Variation Sequences

• The horizontal/vertical kerning one you just raised

• Lastly, the default caseless matching issue

[r12a]

Fwiw, here is a list of open issues for css-fonts-4 that the i18n WG is currently tracking:
https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+label%3Acss-fonts-4+label%3Ai18n-tracker

[svgeesus]

Otherwise this all looks good to me. Thanks.

Closing, as individual issues have been filed separately.