I interpret that the horizontalbar U+2015 is the dash that is to be used as an introduction to speech in those traditions that utilize this style: Īs such, I generally draw it as a nominal em dash - i.e., I make it a full em wide with zero sidebearings (which is not typically how I draw my emdash U+2014 these days). I wouldn’t even really bother with the codepoints in except that I suspect there are a number of validators that would flag a font as not supporting various legacy codepages that include these codepoints (especially U+00AD) if these codepoints are not in fact present. case versions of U+00AD, since the hyphen glyph will be utilized and still be a proper target for any existing relevant GSUBs. If you double-encode then you don’t need to be concerned with. And if the glyphs differ from the 002D/0020 glyphs, then unexpected behavior can happen. However, in some apps, the renderer uses the mapped glyph if the 00AD/00A0 codepoints are actually present. In some apps, the renderer does so regardless. If these codepoints are not present, then the renderer should use the U+002D hyphen and U+0020 space. In practical reality, I believe most most modern apps treat them this way. I would guess that the fact that they are encoded at all is a legacy residue. The glyphs themselves should be the exact same as the hyphen and space in every other way. These two are unique characters whose distinct properties I feel should be properly handled at a higher level than the font: the discretionary character of the softhyphen and the non-breaking character of the nbspace are characteristics that should be managed at the layout level. My preferred approach to U+00AD softhyphen is the same as U+00A0 nbspace - which is to say, I prefer to double-encode them with their default references hyphen and space.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |