<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Makoto,<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class="">Therefore we need to define and implement a mechanism that allows layout engines to resolve a glyph’s rotation property based on both a predefined dataset *and* the current font’s overriding.<br class=""></blockquote><br class="">I am very interested in your suggestion and hope to hear more.<br class=""></blockquote><div class=""><br class=""></div><div class="">A common pattern we use in complex text shaping (most for Indic scripts’ glyph reordering) to enable font-dependent (thus allowing fonts to override some default behavior) shaping/layout is that, we specify the shaping/layout engine should extract glyph properties from the lookups registered to certain OTL features before starting doing the shaping/layout.</div><div class=""><br class=""></div><div class="">For example, we could specify that, no matter what default rotation property (upright or rotated) the layout engine thinks a glyph has, it must first examine the OTL vert and vrtr features, and all glyphs resulted in vert must be kept upright, while all glyphs resulted in vrtr must be rotated. In this way, fonts get an opportunity to resolve incompatibility by explicitly declaring which glyphs are expected to be upright or rotated.</div><br class=""><blockquote type="cite" class="">I heard that CSS border does not work for characters containing accents <br class="">when they appear in vertically written text. This is not surprising.<br class=""></blockquote><div class=""><br class=""></div>Um, not clear what this means…<br class=""><div class="">
<br class="">Best,<br class="">梁海 Liang Hai<br class=""><a href="https://lianghai.github.io" class="">https://lianghai.github.io</a>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On Aug 6, 2020, at 21:27, MURATA Makoto <<a href="mailto:eb2m-mrt@asahi-net.or.jp" class="">eb2m-mrt@asahi-net.or.jp</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="">Ken,</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2020年8月6日(木) 22:11 Ken Lunde <<a href="mailto:ken.lunde@gmail.com" class="">ken.lunde@gmail.com</a>>:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Murata-san,<br class=""><br class="">The use of "compliance" in the context of the Source Han Sans (and Source Han Serif and Source Han Mono) ReadMe PDF is in direct reference to explicitly *not* including pre-rotated forms of non–full-width glyphs and excluding substitutions for arrows and arrow-like characters, which is clearly stated:<br class=""><br class="">> UAX #50 Compliance<br class="">> Source Han Sans is one of the first font implementations that is compliant with UAX #50 (Unicode Vertical Text Layout). Only the substitutions in the 'vert' GSUB feature are expected to be used, and the 'vrt2' GSUB feature, which is a subset of the 'vert' GSUB feature, is included only because some environments, such as Windows and some Microsoft applications, require it to be present. In particular, pre-rotated non–full-width glyphs have been excluded from the 'vrt2' GSUB feature, and substitutions for arrows and arrow-like characters have also been excluded from both GSUB features.<br class=""><br class=""></blockquote><div class=""><br class=""></div><div class="">Thanks for your clarification. </div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Ten Mincho (貂明朝) is another contemporary typeface whose fonts are UAX #50 compliant in the same sense:<br class=""><br class=""><a href="https://blogs.adobe.com/CCJKType/2018/11/ten-mincho-redux.html" rel="noreferrer" target="_blank" class="">https://blogs.adobe.com/CCJKType/2018/11/ten-mincho-redux.html</a><br class=""><br class="">As Liang was suggesting, the UAX #50 property values are not absolutes -- and cannot be -- and implementations are free to tailor as necessary. A good example can again be found in the Source Han typefaces: all of the full-size kana include a vertical form whose shape is subtly different from the default (horizontal) form. The vo property value for these characters is "U," but the fonts are tailored in such a way that they are virtually "Tu" in that they are transforming. In other words, fonts are allowed to transform.<br class=""><br class=""></blockquote><div class=""><br class=""></div><div style="background-color: transparent;" class="">I remember that the original intent of the CSS WG was to<span class="Apple-converted-space"> </span></div><div class="">ensure conformant CSS user agents to provide the same </div><div class="">text orientation. This is exactly what Japanese publishers </div><div class="">hope to have. Fidelity is more important for users. But </div><div class="">it is not there.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; background-color: transparent;">And yes, I agree that the standard 'vert' GSUB feature definition of Adobe-Japan1, which is what you mean when you state "AJ1 font template" in your slide deck, would benefit from tweaking. The difficulty, of course, is propagating the change to the large number of installed fonts, which tend to be among the most enduring pieces of digital code.<br class=""></blockquote><div class=""><br class=""></div><div class="">It appears that every Japanese vendor faithfully follows the AJ1 font template. </div><div class="">I do not think that changing them in an incompatible way is possible.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">With regard to changing the vo property of U+FF1B ； FULLWIDTH SEMICOLON from "Tr" to "Tu" on page 14 of your slide deck, please, please, please submit the suggestion here:<br class=""><br class=""><a href="https://corp.unicode.org/reporting.html" rel="noreferrer" target="_blank" class="">https://corp.unicode.org/reporting.html</a><br class=""><br class="">I have been trying to convince the other co-editor of UAX #50 to make this change. Having another voice would be very helpful.<br class=""></blockquote><div class=""><br class=""></div><div style="background-color: transparent;" class="">Sure. Let me try. </div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Makoto</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class="">Regards...<br class=""><br class="">-- Ken<br class=""><br class="">> On Aug 6, 2020, at 05:10, MURATA Makoto <<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank" class="">eb2m-mrt@asahi-net.or.jp</a>> wrote:<br class="">><span class="Apple-converted-space"> </span><br class="">> Liang,<br class="">><span class="Apple-converted-space"> </span><br class="">> 2020年8月6日(木) 19:12 梁海 Liang Hai <<a href="mailto:lianghai@gmail.com" target="_blank" class="">lianghai@gmail.com</a>>:<br class="">> The “compliance” talked about in the slides sounds a bit misguided.<br class="">><span class="Apple-converted-space"> </span><br class="">> It may well be. But this term was introduced by Source Han Sans.<br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><a href="https://github.com/adobe-fonts/source-han-sans/raw/release/SourceHanSansReadMe.pdf" rel="noreferrer" target="_blank" class="">https://github.com/adobe-fonts/source-han-sans/raw/release/SourceHanSansReadMe.pdf</a><br class="">><span class="Apple-converted-space"> </span><br class="">> This document suggests that all other fonts are NOT<span class="Apple-converted-space"> </span><br class="">> UAX#50 compliant.<br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">> The behavior specified by UAX #50 is a decent low-level default at most, and can’t address all the use cases. Therefore fonts naturally need to be diverse and address the flexibility required by typography.<br class="">><span class="Apple-converted-space"> </span><br class="">> The architectural problem is that, layout engines assume a predefined rotation property (based on UAX #50 or not) for characters, and there’s no reliable way to override that. The boundaries between rotated and upright runs even makes OTL a non-starter.<br class="">><span class="Apple-converted-space"> </span><br class="">> Certainly, nothing is reliable. This is unfortunately the case right now.<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">> Therefore we need to define and implement a mechanism that allows layout engines to resolve a glyph’s rotation property based on both a predefined dataset *and* the current font’s overriding.<br class="">><span class="Apple-converted-space"> </span><br class="">> I am very interested in your suggestion and hope to hear more.<br class="">><span class="Apple-converted-space"> </span><br class="">> I heard that CSS border does not work for characters containing accents<span class="Apple-converted-space"> </span><br class="">> when they appear in vertically written text. This is not surprising.<br class="">><span class="Apple-converted-space"> </span><br class="">> Regards,<br class="">> Makoto<br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">> Best,<br class="">> 梁海 Liang Hai<br class="">><span class="Apple-converted-space"> </span><a href="https://lianghai.github.io/" rel="noreferrer" target="_blank" class="">https://lianghai.github.io</a><br class="">><span class="Apple-converted-space"> </span><br class="">>> On Aug 6, 2020, at 07:37, MURATA Makoto <<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank" class="">eb2m-mrt@asahi-net.or.jp</a>> wrote:<br class="">>><span class="Apple-converted-space"> </span><br class="">>> Folks,<br class="">>><span class="Apple-converted-space"> </span><br class="">>> This presentation explains typical problems around interactions<span class="Apple-converted-space"> </span><br class="">>> of fonts and vertical writing.<br class="">>><span class="Apple-converted-space"> </span><br class="">>><span class="Apple-converted-space"> </span><a href="https://1drv.ms/p/s!An5Z79wj5AZBgsdN2pd2XmS08WslZA?e=UM5O6K" rel="noreferrer" target="_blank" class="">https://1drv.ms/p/s!An5Z79wj5AZBgsdN2pd2XmS08WslZA?e=UM5O6K</a><br class="">>><span class="Apple-converted-space"> </span><br class="">>> Japanese publishers are forced to use rasterized text, which hampers<span class="Apple-converted-space"> </span><br class="">>> accessibility. I hope that the activities planned here help to make<span class="Apple-converted-space"> </span><br class="">>> things better.<br class="">>><span class="Apple-converted-space"> </span><br class="">>> --<span class="Apple-converted-space"> </span><br class="">>> Regards,<br class="">>> Makoto<br class="">>> _______________________________________________<br class="">>> mpeg-otspec mailing list<br class="">>><span class="Apple-converted-space"> </span><a href="mailto:mpeg-otspec@lists.aau.at" target="_blank" class="">mpeg-otspec@lists.aau.at</a><br class="">>><span class="Apple-converted-space"> </span><a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank" class="">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br class="">><span class="Apple-converted-space"> </span><br class="">> _______________________________________________<br class="">> mpeg-otspec mailing list<br class="">><span class="Apple-converted-space"> </span><a href="mailto:mpeg-otspec@lists.aau.at" target="_blank" class="">mpeg-otspec@lists.aau.at</a><br class="">><span class="Apple-converted-space"> </span><a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank" class="">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br class="">><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><br class="">> --<span class="Apple-converted-space"> </span><br class="">> Regards,<br class="">> Makoto<br class="">> _______________________________________________<br class="">> mpeg-otspec mailing list<br class="">><span class="Apple-converted-space"> </span><a href="mailto:mpeg-otspec@lists.aau.at" target="_blank" class="">mpeg-otspec@lists.aau.at</a><br class="">><span class="Apple-converted-space"> </span><a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank" class="">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br class=""><br class="">_______________________________________________<br class="">mpeg-otspec mailing list<br class=""><a href="mailto:mpeg-otspec@lists.aau.at" target="_blank" class="">mpeg-otspec@lists.aau.at</a><br class=""><a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank" class="">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br class=""></blockquote></div><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class="">Regards,</div><div class="">Makoto</div></div></div></div><span style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">mpeg-otspec mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="mailto:mpeg-otspec@lists.aau.at" style="font-family: SFProText-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">mpeg-otspec@lists.aau.at</a><br style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" style="font-family: SFProText-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a></div></blockquote></div><br class=""></div></body></html>