<div dir="ltr"><div>Ken,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2020年8月6日(木) 22:11 Ken Lunde <<a href="mailto:ken.lunde@gmail.com">ken.lunde@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Murata-san,<br>
<br>
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>
<br>
> UAX #50 Compliance<br>
> 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>
<br></blockquote><div><br></div><div>Thanks for your clarification. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Ten Mincho (貂明朝) is another contemporary typeface whose fonts are UAX #50 compliant in the same sense:<br>
<br>
<a href="https://blogs.adobe.com/CCJKType/2018/11/ten-mincho-redux.html" rel="noreferrer" target="_blank">https://blogs.adobe.com/CCJKType/2018/11/ten-mincho-redux.html</a><br>
<br>
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>
<br></blockquote><div><br></div><div style="background-color:transparent">I remember that the original intent of the CSS WG was to </div><div>ensure conformant CSS user agents to provide the same </div><div>text orientation.  This is exactly what Japanese publishers </div><div>hope to have.  Fidelity is more important for users.  But </div><div>it is not there.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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></blockquote><div><br></div><div>It appears that every Japanese vendor faithfully follows the AJ1 font template.  </div><div>I do not think that changing them in an incompatible way is possible.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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>
<br>
<a href="https://corp.unicode.org/reporting.html" rel="noreferrer" target="_blank">https://corp.unicode.org/reporting.html</a><br>
<br>
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></blockquote><div><br></div><div style="background-color:transparent">Sure.  Let me try. </div><div><br></div><div>Regards,</div><div>Makoto</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards...<br>
<br>
-- Ken<br>
<br>
> On Aug 6, 2020, at 05:10, MURATA Makoto <<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</a>> wrote:<br>
> <br>
> Liang,<br>
> <br>
> 2020年8月6日(木) 19:12 梁海 Liang Hai <<a href="mailto:lianghai@gmail.com" target="_blank">lianghai@gmail.com</a>>:<br>
> The “compliance” talked about in the slides sounds a bit misguided.<br>
> <br>
> It may well be.  But this term was introduced by Source Han Sans.<br>
> <br>
> <a href="https://github.com/adobe-fonts/source-han-sans/raw/release/SourceHanSansReadMe.pdf" rel="noreferrer" target="_blank">https://github.com/adobe-fonts/source-han-sans/raw/release/SourceHanSansReadMe.pdf</a><br>
> <br>
> This document suggests that all other fonts are NOT <br>
> UAX#50 compliant.<br>
> <br>
> <br>
> 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>
> <br>
> 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>
> <br>
> Certainly, nothing is reliable.  This is unfortunately the case right now. <br>
> <br>
> 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>
> <br>
> I am very interested in your suggestion and hope to hear more.<br>
> <br>
> I heard that CSS border does not work for characters containing accents <br>
> when they appear in vertically written text.  This is not surprising.<br>
> <br>
> Regards,<br>
> Makoto<br>
> <br>
> <br>
> Best,<br>
> 梁海 Liang Hai<br>
> <a href="https://lianghai.github.io" rel="noreferrer" target="_blank">https://lianghai.github.io</a><br>
> <br>
>> On Aug 6, 2020, at 07:37, MURATA Makoto <<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</a>> wrote:<br>
>> <br>
>> Folks,<br>
>> <br>
>> This presentation explains typical problems around interactions <br>
>> of fonts and vertical writing.<br>
>> <br>
>> <a href="https://1drv.ms/p/s!An5Z79wj5AZBgsdN2pd2XmS08WslZA?e=UM5O6K" rel="noreferrer" target="_blank">https://1drv.ms/p/s!An5Z79wj5AZBgsdN2pd2XmS08WslZA?e=UM5O6K</a><br>
>> <br>
>> Japanese publishers are forced to use rasterized text, which hampers <br>
>> accessibility.  I hope that the activities planned here help to make <br>
>> things better.<br>
>> <br>
>> -- <br>
>> Regards,<br>
>> Makoto<br>
>> _______________________________________________<br>
>> mpeg-otspec mailing list<br>
>> <a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
>> <a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
> <br>
> _______________________________________________<br>
> mpeg-otspec mailing list<br>
> <a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
> <a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
> <br>
> <br>
> -- <br>
> Regards,<br>
> Makoto<br>
> _______________________________________________<br>
> mpeg-otspec mailing list<br>
> <a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
> <a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
<br>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,</div><div>Makoto</div></div></div></div>