Source Han Sans Version 1.003 Update

Although it has been less than two months since the Source Han Sans Version 1.002 update was released, a Version 1.003 maintenance update was released on 2015-06-09 to address two particular issues. No glyphs nor Unicode mappings were added or modified.

Google’s corresponding Noto Sans CJK fonts, which continue to differ from Source Han Sans only by name, were also updated to Version 1.003 at the same time, and reflect the same changes.

The following are the changes that are reflected in the Version 1.003 update:

  • The vertical metrics were adjusted by harmonizing the OS/2.usWinAscent and OS/2.usWinDescent values by using the highest value across all weights, 1160, for the former value and the lowest value across all weights, 320, for the latter (the values in the Version 1.002 fonts were calculated by removing excessively tall and other vertical-only glyphs from the equation, specifically those for U+2E3A, U+2E3B, U+302A through U+302D, U+3031, and U+3032, but were not harmonized across all weights), and reflecting these same harmonized settings in the 'hhea' table by overriding the hhea.Ascender (1160) and hhea.Descender (−320) values (the Version 1.002 fonts reflected the OS/2.sTypoAscender and OS/2.sTypoDescender settings in the 'hhea' table).
  • The 'locl' (Localized Forms) GSUB feature was adjusted so that language tagging correctly functions in applications besides Adobe InDesign, such as modern browsers that support the 'locl' GSUB feature, which are currently Chrome and Firefox, though the former currently requires setting -webkit-font-feature-settings: "locl"; in the CSS.

These changes can also be found in the “Changes” section of the 26-page official ReadMe file (the PDF file will download if the link is clicked).

Both changes are reflected in the image at the top of this article, which was prepared using Firefox and four weights of Source Han Sans (with Japanese as the default language). Below is an image of what is displayed when the Version 1.002 fonts are used:

Some observations when comparing the two images:

First and foremost, the line spacing is no longer overly tight, because the vertical metrics that are reflected in the 'OS/2' and 'hhea' tables are now in line with what we do for the other Source families. Latin descenders will no longer collide with the line below.

Second, the forms of some ideographs (漢 and 曜 in Korean), along with those of particular punctuation (look very carefully at the Y-axis placement and width of U+201C (“) and U+201D (”) across all languages, and the Y-axis placement and relative weight of U+2014 (—) across all languages), are now correct in terms of what the 'locl' GSUB feature was intended to produce. Of course, the application must support language tagging and the 'locl' GSUB feature. The table below provides the actual language-tagged text, which should display correctly as long as the browser supports language tagging and the 'locl' GSUB feature:

Language Text String
Japanese あ—ん 漢—字“曜”
Korean 한—글 漢—字“曜”
Simplified Chinese 汉字“曜”
Traditional Chinese 漢—字“曜”
English a—g A—G

As a side note, this maintenance update represented a great learning experience for me, in terms of better understanding how language tagging and the 'locl' GSUB feature interact, to include language and script declarations in OpenType fonts. Regardless of age, one should never stop learning.

Enjoy! ☺

Comments are closed.