<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Makoto,<div><br></div><div>It’s getting tiring for me to see every single sentence from me get misinterpreted.</div><div><br></div><div>For what it’s worth, I’m not an amateur in terms of text encoding and layout, and I’m not your stereotypical “font guy”.</div><div><br></div><div>I’ll let you guys continue the discussion until some actionable proposal comes out of it, before I step in again.</div><div><br><div dir="ltr"><div>Best,</div><div>梁海 Liang Hai</div><div>https://lianghai.github.io</div></div><div dir="ltr"><br><blockquote type="cite">On Aug 16, 2020, at 18:23, MURATA Makoto <eb2m-mrt@asahi-net.or.jp> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Liang,</div><div><br></div><div>You appear to think that fonts or UAX#50 cannot provide </div><div>fidelity of text orientations, <span style="background-color:transparent">but application programs </span></div><div><span style="background-color:transparent">should be able to do so anyway. This is a typical </span><span style="background-color:transparent">reaction </span></div><div><span style="background-color:transparent">from font guys. Unfortunately, application programmers </span></div><div style="background-color:transparent">have never succeeded in doing so. Expecting application </div><div style="background-color:transparent">programs to provide fidelity in site of font mess is just</div><div style="background-color:transparent">hopeful thinking, IMHO.</div><div style="background-color:transparent"><br></div><div style="background-color:transparent">CSS Writing Modes of W3C is based on lots of discussions </div><div style="background-color:transparent">in W3C. Even if you explicitly markup every character (by the </div><div style="background-color:transparent">span element) and try <span style="background-color:transparent">to control the text orientation, it is </span></div><div style="background-color:transparent"><span style="background-color:transparent">not always possible in CSS.</span></div><div style="background-color:transparent"><span style="background-color:transparent"><br></span></div><div style="background-color:transparent"><span style="background-color:transparent">For example, consider <span>&$x2016;</span> </span><span style="background-color:transparent">(double </span></div><div style="background-color:transparent"><span style="background-color:transparent">vertical line) in vertical writing. If you specify 'sideways', </span></div><div style="background-color:transparent"><span style="background-color:transparent">it will certainly be rotated by CSS user agents. If you </span></div><div style="background-color:transparent"><span style="background-color:transparent">specify 'upright', CSS user agents do not rotate glyphs </span></div><div style="background-color:transparent"><span style="background-color:transparent">but they must enable the vert feature, which returns a rotated </span></div><div style="background-color:transparent"><span style="background-color:transparent">glyph in the case of AJ1 fonts. Thus, it is simply </span></div><div style="background-color:transparent"><span style="background-color:transparent">impossible to obtain an upright glyph.</span></div><div style="background-color:transparent"><br></div><div style="background-color:transparent">Regards,</div><div style="background-color:transparent">Makoto</div><div style="background-color:transparent"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2020年8月16日(日) 18:51 梁海 Liang Hai <<a href="mailto:lianghai@gmail.com">lianghai@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"><div style="overflow-wrap: break-word;"><blockquote type="cite">So, are you saying fidelity of text orientations is impossible? <br></blockquote><div><br></div>I said what I said:<div><br></div><div>Initially I pointed out why UAX #50 can’t be expected to decide glyph orientation for all use cases, as well as the importance of fonts being able to override glyph orientation.</div><div><br></div><div>Then Eric misunderstood my intention, so I explained why, even if we just think about compatibility, fonts need to be granted the ability to override glyph orientation.<br><div><br></div><div><blockquote type="cite">Publishers of EPUB publications strongly require fidelity. <br>They request implementors to provide fidelity. Kadokawa <br>(a big publisher in Japan) created a list of behaviors of <br>several EPUB readers for code points used in Japan. <br>UAX#50 should be stable with the exception of newly <br>added characters. Non-conformant implemenations <br>are decreasing and will be avoided by the market.<br><br>If fidelity is nor provided, publishers use rasterized <br>text, which is not at all accessible. This is really <br>a shame.<br></blockquote><div><br></div>Talking about theoretical fidelity like this isn’t helpful. We also need to make sure a workaround solution is in place. One can’t assume “fidelity” simply because an architecture says “there shall be fidelity”. Incompatibility issues exist in the wild, forever, and must be addressed.</div><div><br></div><div>On the other hand, EPUB is based on markups therefore theoretically it doesn’t need to be restricted by plain text formatting, as it can utilize markups to override glyph orientation. The question is though, is it appropriate to ask EPUB producers to rely on markups to address widespread compatibility issues?</div><div><div>
<br>Best,<br>梁海 Liang Hai<br><a href="https://lianghai.github.io" target="_blank">https://lianghai.github.io</a>
</div>
<div><br><blockquote type="cite"><div>On Aug 16, 2020, at 10:01, MURATA Makoto <<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</a>> wrote:</div><br><div><div dir="ltr" style="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;text-decoration:none"><div dir="ltr">Liang,<div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2020年8月16日(日) 3:28 梁海 Liang Hai <<a href="mailto:lianghai@gmail.com" target="_blank">lianghai@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">Eric,<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>><span> </span><br>> I disagree with the second sentence, when interpreted anywhere close to "fonts can do anything". We need fonts to do their part. If a U+0041 A LATIN CAPITAL LETTER A is displayed by a "B", we can clearly blame the font and declare it useless for rendering text. Similarly if "MANZANITA" is displayed at "MAZNAZITA" by the font deciding to rotate N and Z, we are in trouble.<br><br>I’m not sure why you felt the need to interpret the sentence in this way. But it feels like you wasn’t aware of the complete context of the issue. I’m not gonna even talk about UAX #50’s inherent inability of addressing different locale’s different preferences about certain characters’ orientation—now let’s just talk about compatibility.<br><br>Implementations are naturally incompatible. Adoption of UAX #50 varies. UAX #50 itself isn’t stable either. New characters get encoded. Old and new products coexist. It’s pretty clear you can’t assume all target environments of a font to have consistency of glyph orientation.</blockquote><div><br></div><div>So, are you saying fidelity of text orientations is impossible? </div><div><br></div><div style="background-color:transparent">Publishers of EPUB publications strongly require fidelity. </div><div style="background-color:transparent">They request implementors to provide fidelity. Kadokawa </div><div>(a big publisher in Japan) created a list of behaviors of </div><div>several EPUB readers for code points used in Japan. </div><div>UAX#50 should be stable with the exception of newly </div><div>added characters. Non-conformant implemenations </div><div style="background-color:transparent">are decreasing and will be avoided <span style="background-color:transparent">by the market.</span></div><div style="background-color:transparent"><br></div><div style="background-color:transparent">If fidelity is nor provided, publishers use rasterized </div><div>text, which is not at all accessible. This is really </div><div>a shame.</div><div><br></div><div>Regards,</div><div>Makoto</div><div><br></div><div><br></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>Now, U+00A9 © COPYRIGHT SIGN is rotated in Word but upright in Chrome. This is just two products. How do I resolve this incompatibility issue? Is this markup’s responsibility?<br><br>Best,<br>梁海 Liang Hai<br><a href="https://lianghai.github.io/" rel="noreferrer" target="_blank">https://lianghai.github.io</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>--<span> </span><br><div dir="ltr"><div dir="ltr"><div>Regards,</div><div>Makoto</div></div></div></div></div></blockquote></div><br></div></div></div>_______________________________________________<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>
</div></blockquote></div></body></html>