W3C Summary: If a font family match occurs, the user agent assembles the set of font faces...

W3C Summary: If a font family match occurs, the user agent assembles the set of font faces...

1. If a font family match occurs, the user agent assembles the set of font faces in that family and then narrows the set to a single face using other font properties in the order given below. (213)

2. If there are no more font families to be evaluated and no matching face has been found, then the user agent performs a system font fallback procedure to find the best match for the character to be rendered. (208)
3. The first available font, used for example in the definition of font-relative lengths such as ‘ex’ and ‘ch’ or in the definition of the ‘line-height’ property, is defined to be the first available font that would match the U+0020 (space) character given font families in the ‘font-family’ list (or a user agent's default font if none are available). (200)
4. For sequences containing variation selectors, which indicate the precise glyph to be used for a given character, user agents always attempt system font fallback to find the appropriate glyph before using the default glyph of the base character. (197)
5. If none of the families named in the ‘font-family’ list contain a glyph for that codepoint, user agents must display some form of missing glyph symbol for that character rather than attempting system font fallback for that codepoint. (197)
6. If no font on the system supports the full sequence, match the single character b using the normal procedure for matching single characters and ignore the variation selector. (185)
7. When matching the replacement character U+FFFD, user agents may skip the font matching process and immediately display some form of missing glyph symbol, they are not required to display the glyph from the font that would be selected by the font matching process. (183)
8. If a given character is a Private-Use Area Unicode codepoint, user agents must only match font families named in the ‘font-family’ list that are not generic families. (182)
9. If no faces are present for a family defined via @font-face rules, the family should be treated as missing; matching a platform font with the same name must not occur in this case. (176)
10. On systems containing fonts with multiple localized font family names, user agents must match any of these names independent of the underlying system locale or platform API used. (172)
11. For fonts containing character maps for both legacy encodings and Unicode, the contents of the legacy encoding character map must have no effect on the results of the font matching process. (171)
12. However, within font families defined via @font-face rules, italic and oblique faces must be distinguished using the value of the ‘font-style’ descriptor. (170)
13. Using the computed font property values for a given element, the user agent starts with the first family name specified by the ‘font-family’ property. (169)
14. If a particular character cannot be displayed using any font, the user agent should indicate by some means that a character is not being displayed, displaying either a symbolic representation of the missing glyph (e.g. using a Last Resort Font) or using the missing character glyph from a default font. (161)

Best words:

1. font (56)
2. character (27)
3. faces (25)
4. matching (25)
5. user (22)
6. face (17)
7. family (17)
8. fonts (14)
9. agents (13)
10. value (13)
11. using (12)
12. must (12)
13. glyph (12)
14. values (11)
15. sequence (11)
16. other (10)
17. given (10)
18. families (10)
19. italic (10)
20. w3c (10)
21. set (9)
22. agent (9)
23. first (9)
24. document (9)
25. system (8)
26. process (8)
27. oblique (8)
28. match (8)
29. available (7)
30. defined (7)
31. containing (7)
32. characters (7)
33. single (7)
34. rules (6)
35. width (6)
36. name (6)
37. supports (6)
38. list (6)
39. been (6)
40. property (6)
41. patent (5)
42. fallback (5)
43. missing (5)
44. @font-face (5)
45. checked (5)
46. css (4)
47. procedure (4)
48. unicode (4)
49. definition (4)
50. ‘font-family’ (4)
51. section (4)
52. normal (4)
53. matched (4)
54. contains (4)
55. variation (4)
56. default (4)
57. names (4)
58. combining (4)
59. treated (4)
60. ‘font-stretch’ (4)
61. find (4)
62. weight (4)
63. contain (3)
64. platform (3)
65. 2018 (3)
66. module (3)
67. cluster (3)
68. selector (3)
69. occurs (3)
70. permitted (3)

Keyword highlighting:

• If a font family match occurs, the user agent assembles the set of font faces in that family and then narrows the set to a single face using other font properties in the order given below.
• If there are no more font families to be evaluated and no matching face has been found, then the user agent performs a system font fallback procedure to find the best match for the character to be rendered.
• The first available font, used for example in the definition of font-relative lengths such as ‘ex’ and ‘ch’ or in the definition of the ‘line-height’ property, is defined to be the first available font that would match the U+0020 (space) character given font families in the ‘font-family’ list (or a user agent's default font if none are available).
• For sequences containing variation selectors, which indicate the precise glyph to be used for a given character, user agents always attempt system font fallback to find the appropriate glyph before using the default glyph of the base character.
• If none of the families named in the ‘font-family’ list contain a glyph for that codepoint, user agents must display some form of missing glyph symbol for that character rather than attempting system font fallback for that codepoint.
• If no font on the system supports the full sequence, match the single character b using the normal procedure for matching single characters and ignore the variation selector.
• When matching the replacement character U+FFFD, user agents may skip the font matching process and immediately display some form of missing glyph symbol, they are not required to display the glyph from the font that would be selected by the font matching process.
• If a given character is a Private-Use Area Unicode codepoint, user agents must only match font families named in the ‘font-family’ list that are not generic families.
• If no faces are present for a family defined via @font-face rules, the family should be treated as missing; matching a platform font with the same name must not occur in this case.
• On systems containing fonts with multiple localized font family names, user agents must match any of these names independent of the underlying system locale or platform API used.
• For fonts containing character maps for both legacy encodings and Unicode, the contents of the legacy encoding character map must have no effect on the results of the font matching process.
• However, within font families defined via @font-face rules, italic and oblique faces must be distinguished using the value of the ‘font-style’ descriptor.
• Using the computed font property values for a given element, the user agent starts with the first family name specified by the ‘font-family’ property.
• If a particular character cannot be displayed using any font, the user agent should indicate by some means that a character is not being displayed, displaying either a symbolic representation of the missing glyph (e.g. using a Last Resort Font) or using the missing character glyph from a default font.

Sentences:

1. CSS Fonts Module Level 3 W3C Recommendation 20 September 2018 This version: Latest version: Latest editor's draft: Previous versions: Issues List: css-fonts-3 issues on GitHub Discussion: on GitHub (preferred), or www-style@w3.org with subject line “[css-fonts] … message topic …” (archives) Test Suite: Editors: John Daggett (Invited Expert) Myles C.
2. Please check the errata for any errors or issues reported since publication.
3. Copyright © 2018 W3C® (MIT, ERCIM, Keio, Beihang).
4. W3C liability, trademark and document use rules apply.
5. This CSS3 module describes how font properties are specified and how font resources are loaded dynamically.
6. The contents of this specification are a consolidation of content previously divided into CSS3 Fonts and CSS3 Web Fonts modules.
7. The description of font load events was moved into the CSS Font Loading module.
8. This section describes the status of this document at the time of its publication.
9. Other documents may supersede this document.
10. This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation.
11. It is a stable document and may be used as reference material or cited from another document.
12. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment.
13. This enhances the functionality and interoperability of the Web.
14. This document was produced by a group operating under the W3C Patent Policy.
15. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent.
16. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
17. This document is governed by the 1 February 2018 W3C Process Document.
18. A test suite and implementation report are available.
19. 4.
20. 5.
21. 6.
22. 7.
23. 8.
24. Using the computed font property values for a given element, the user agent starts with the first family name specified by the ‘font-family’ property.
25. If the family name is a generic family keyword, the user agent looks up the appropriate font family name to be used.
26. 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.
27. For other family names, the user agent attempts to find the family name among fonts defined via @font-face rules and then among available system fonts, matching names with a case-insensitive comparison as outlined in the section above.
28. On systems containing fonts with multiple localized font family names, user agents must match any of these names independent of the underlying system locale or platform API used.
29. If the font resources defined for a given face in an @font-face rule are either not available or contain invalid font data, then the face should be treated as not present in the family.
30. If no faces are present for a family defined via @font-face rules, the family should be treated as missing; matching a platform font with the same name must not occur in this case.
31. If a font family match occurs, the user agent assembles the set of font faces in that family and then narrows the set to a single face using other font properties in the order given below.
32. ‘font-stretch’ is tried first.
33. If the matching set contains faces with width values matching the ‘font-stretch’ value, faces with other width values are removed from the matching set.
34. If there is no face that exactly matches the width value the nearest width is used instead.
35. If the value of ‘font-stretch’ is ‘normal’ or one of the condensed values, narrower width values are checked first, then wider values.
36. If the value of ‘font-stretch’ is one of the expanded values, wider values are checked first, followed by narrower values.
37. Once the closest matching width has been determined by this process, faces with other widths are removed from the matching set.
38. ‘font-style’ is tried next.
39. If the value of ‘font-style’ is ‘italic’, italic faces are checked first, then oblique, then normal faces.
40. If the value is ‘oblique’, oblique faces are checked first, then italic faces and then normal faces.
41. If the value is ‘normal’, normal faces are checked first, then oblique faces, then italic faces.
42. Faces with other style values are excluded from the matching set.
43. User agents are permitted to distinguish between italic and oblique faces within platform font families but this is not required, so all italic or oblique faces may be treated as italic faces.
44. However, within font families defined via @font-face rules, italic and oblique faces must be distinguished using the value of the ‘font-style’ descriptor.
45. For families that lack any italic or oblique faces, user agents may create artificial oblique faces, if this is permitted by the value of the ‘font-synthesis’ property.
46. ‘font-weight’ is matched next, so it will always reduce the matching set to a single font face.
47. If bolder/lighter relative weights are used, the effective weight is calculated based on the inherited weight value, as described in the definition of the ‘font-weight’ property.
48. Given the desired weight and the weights of faces in the matching set after the steps above, if the desired weight is available that face matches.
49. ‘font-size’ must be matched within a UA-dependent margin of tolerance.
50. (Typically, sizes for scalable fonts are rounded to the nearest whole pixel, while the tolerance for bitmapped fonts could be as large as 20%.) Further computations, e.g., by ‘em’ values in other properties, are based on the ‘font-size’ value that is used, not the one that is specified.
51. If the font resource has not been loaded and the range of characters defined by the ‘unicode-range’ descriptor value includes the character in question, load the font.
52. After downloading, if the effective character map supports the character in question, select that font.
53. When the matched face is a composite face, user agents must use the procedure above on each of the faces in the composite face in reverse order of @font-face rule definition.
54. While the download occurs, user agents may either wait until the font is downloaded or render once with substituted font metrics and render again once the font is downloaded.
55. If no matching face exists or the matched face does not contain a glyph for the character to be rendered, the next family name is selected and the previous three steps repeated.
56. Glyphs from other faces in the family are not considered.
57. The only exception is that user agents may optionally substitute a synthetically obliqued version of the default face if that face supports a given glyph and synthesis of these faces is permitted by the value of the ‘font-synthesis’ property.
58. For example, a synthetic italic version of the regular face may be used if the italic face doesn't support glyphs for Arabic.
59. If there are no more font families to be evaluated and no matching face has been found, then the user agent performs a system font fallback procedure to find the best match for the character to be rendered.
60. The result of this procedure may vary across user agents.
61. If a particular character cannot be displayed using any font, the user agent should indicate by some means that a character is not being displayed, displaying either a symbolic representation of the missing glyph (e.g. using a Last Resort Font) or using the missing character glyph from a default font.
62. Optimizations of this process are allowed provided that an implementation behaves as if the algorithm had been followed exactly.
63. Matching occurs in a well-defined order to ensure that the results are as consistent as possible across user agents, given an identical set of available fonts and rendering technology.
64. The first available font, used for example in the definition of font-relative lengths such as ‘ex’ and ‘ch’ or in the definition of the ‘line-height’ property, is defined to be the first available font that would match the U+0020 (space) character given font families in the ‘font-family’ list (or a user agent's default font if none are available).
65. When text contains characters such as combining marks, ideally the base character should be rendered using the same font as the mark, this assures proper placement of the mark.
66. For this reason, the font matching algorithm for clusters is more specialized than the general case of matching a single character by itself.
67. For sequences containing variation selectors, which indicate the precise glyph to be used for a given character, user agents always attempt system font fallback to find the appropriate glyph before using the default glyph of the base character.
68. A sequence of codepoints containing combining mark or other modifiers is termed a grapheme cluster (see [CSS-TEXT-3] and [UAX29] for a more complete description).
69. For each family in the font list, a face is chosen using the style selection rules defined in the previous section.
70. If all characters in the sequence b + c1 + c2 … are completely supported by the font, select this font for the sequence.
71. If a sequence of multiple codepoints is canonically equivalent to a single character and the font supports that character, select this font for the sequence and use the glyph associated with the canonically equiavlent character for the entire cluster.
72. If c1 is a variation selector, system fallback must be used to find a font that supports the full sequence of b + c1.
73. If no font on the system supports the full sequence, match the single character b using the normal procedure for matching single characters and ignore the variation selector.
74. Note: a sequence with more than one variation selector must be treated as an encoding error and the trailing selectors must be ignored.
75. Otherwise, the user agent may optionally use system font fallback to match a font that supports the entire cluster.
76. If no font is found in step 2, use the matching sequence from step 1 to determine the longest sequence that is completely supported by a font in the font list and attempt to match the remaining combining characters separately using the rules for single characters.
77. CSS font matching is always performed on text runs containing Unicode characters [UNICODE], so documents using legacy encodings are assumed to have been transcoded before matching fonts.
78. For fonts containing character maps for both legacy encodings and Unicode, the contents of the legacy encoding character map must have no effect on the results of the font matching process.
79. The font matching process does not assume that text runs are in either normalized or denormalized form (see [CHARMOD-NORM] for more details).
80. Fonts may only support precomposed forms and not the decomposed sequence of base character plus combining marks.
81. Authors should always tailor their choice of fonts to their content, including whether that content contains normalized or denormalized character streams.
82. If a given character is a Private-Use Area Unicode codepoint, user agents must only match font families named in the ‘font-family’ list that are not generic families.
83. If none of the families named in the ‘font-family’ list contain a glyph for that codepoint, user agents must display some form of missing glyph symbol for that character rather than attempting system font fallback for that codepoint.
84. When matching the replacement character U+FFFD, user agents may skip the font matching process and immediately display some form of missing glyph symbol, they are not required to display the glyph from the font that would be selected by the font matching process.
85. In general, the fonts for a given family will all have the same or similar character maps.
86. The process outlined here is designed to handle even font families containing faces with widely variant character maps.
87. However, authors are cautioned that the use of such families can lead to unexpected results.
88. The algorithm above is different from CSS 2.1 in a number of key places.
89. These changes were made to better reflect actual font matching behavior across user agent implementations.