- From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
- Date: Thu, 12 Dec 2019 13:48:26 +0900
- To: www-archive@w3.org
- Message-ID: <CALvn5EBdHd4HZ4BTQdGDcuMx6pJuMzejU2SwDCo4Asuuspfeqw@mail.gmail.com>
---------- Forwarded message --------- From: Taro Yamamoto <tyamamot@adobe.com> Date: 2019年12月9日(月) 17:14 Subject: Re: UAX#50 conformance: Is it possible to update existing fonts without causing damage to existing non-CSS applications? To: fantasai <fantasai@inkedblade.net>, MURATA Makoto < eb2m-mrt@asahi-net.or.jp>, Nat McCully <nmccully@adobe.com> Cc: Florian Rivoal <florian@rivoal.net> 2019/12/09 15:36 に、"fantasai" <fantasai@inkedblade.net> を書き込みました: The 'vert' feature should not, in general, be controlling the rotation of glyphs other than Tr glyphs. It should provide alternates for upright typesetting, for when the application indicates to the font that this run of text will be upright. If a font is compatible with application software that can take any glyph and override its orientation to be upright or sideways, then it is definitely compatible with CSS Writing Modes and UAX50. Yes, I agree. So, if the 'vert' features in fonts were changed or unchanged, if it did not meet the expectation by applications, it would produce problems, and if the applications' handling of vertical postures were changed or unchanged, if it contradicted the behavior assumed by the fonts, it would produce problems. So, it is not sufficient to have each font or application pretend to conform to UAX50, self-righteously without coordination. This is an example of UAX50 having a different default orientation than such a page layout application software. This is why such software, as Nat explains, cannot "upgrade" itself to match UAX50, but has to offer it as an opt-in option. It is not an example of an incompatibility of the font with UAX50. UAX50 is only a table of defaults, similar to the one in InDesign that decides whether the default orientation of a glyph should be upright or sideways, but with potentially some different values. Yes, I agree also with this. One example that was discussed at the last meeting with Murata--san: U+2192 RIGHTWARDS ARROW, whose vertical posture is defined to be 'R' by UAX50, but has been traditionally been included in the 'vert' table of fonts based on the Adobe-Japan1-x Character Collection (glyph set) since the late 1980s. According to Nat, InDesign assumes its vertical posture to be 'Tr', so InDesign lets the 'vert' do the "pseudo-rotation" for the corresponding glyph without any scruple. There are very many similar cases, where glyphs corresponding to the characters whose vertical postures are defined to be 'R' by UAX50 are assumed to have the 'Tr' vertical posture, and as a result, our fonts have them in the 'vert' features to do the "pseudo-rotation". At this point, my guess may be wrong, but I have the idea that without the assumption, if these characters had not been assumed to have the 'R' vertical posture, as expected by UAX50 today, it would have not been possible for anyone to guarantee that the glyphs corresponding to these characters could have been rotated correctly at the very center of the Japanese EM square type body. There is the distinction here between Japanese glyphs and Western glyphs to be detected beforehand. However, as far as the 'vert' features are concerned, which are in font, for any font developers, it is self-explanatory whether a font is for Japanese or Western languages/scripts. So, by having the 'vert' features do the "pseudo-rotation", applications seem to have been free from the responsibility of rotating Japanese glyphs at the center of their EM square type bodies. Whatever type of glyphs, Japanese full-width characters or Western proportional glyphs, as far as applications position them correctly by rotating and shifting them, understanding how they should be positioned in Japanese vertical lines, it is not necessary to have those 'R' glyphs in the 'vert' features, but it is possible to have applications really rotate and shift them. But I guess it was impossible to assume all applications really could do it in those days. But is it possible to guarantee that they do it rightly at the end of 2019? Regards, --Taro -- Regards, Makoto
Received on Thursday, 12 December 2019 04:49:08 UTC