<div dir="ltr">I agree with Eric.<br><br>In the Internet world, authors do not know which application<br>and which font is used for rendering their contents, but<br>they still would like to ensure the same character orientation<br>everywhere. I suppose that the same scenario probably<br>applies to other features for other languages, and <div>that more and more problems will arise.<br><div><br>David wrote:<br>> * behavior should only be embedded in fonts if it is expected to vary between fonts; constant properties of characters that are independent of fonts should be expressed once<br>> * it should be possible (e.g. by user-side style-sheet) to substitute a font (from the one the author expected or previewed with) and still get correct layout<br><br>This is thoughtful advice. But OpenType allows </div><div>font developers to create their own glyph set, </div><div>specify a cmap,'vert' and other features. Thus,</div><div>interoperability cannot be easily achieved. A<br>well-know glyph set (such as AJ1) is a big help,<br>but the standard 'vert' GSUB feature<br>definition of Adobe-Japan1 is not compliant<br>with UAX #50 (Unicode Vertical Text Layout).<br><br>Eric wrote:</div><div>> I can only see two solutions, after having </div><div>> picked the rules: 1) we fix the fonts that</div>> do not follow the rules or 2) we switch to a </div><div>> new feature that specifically imposes the</div><div>> rules (and may be fallback to 'vert'). I </div><div style="background-color:transparent">> suspect that 1) is not an option.<div>David wrote:</div><div>>
Which leads me to suspect that (2) is better than (1). </div><div> <br>As far as I know, nobody in the Japanese font<br>industry is interested in updating existing<br>fonts so that they comply with UAX#50. This </div><div style="background-color:transparent">is understandable, since users frown on </div><div style="background-color:transparent">such changes.</div><div><br>As I see it, font developers often say that<br>the rest is up to application programmers.<br>Poor application programmers are thus <br>forced to implement ad-hoc behaviors <br>depending on the character and <br>also depending on the font used. <div><br></div><div>For example, Firefox implements </div><div>such an ad-hoc behavior for wavy dash.</div><div><br></div><div></div><div>> Handle fallback (rotated) rendering of characters with Vertical_Orientation=Tr<br>> when the font does not support them via 'vert', nor is there a vertical presentation<br>> form encoded in Unicode. <br><br>This is copied from <br><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1431305">https://bugzilla.mozilla.org/show_bug.cgi?id=1431305</a></div><div><br></div><div>This behavior is allowed by CSS Writing Modes.</div><div><br></div><div style="background-color:transparent"><a href="https://www.w3.org/TR/css-writing-modes-3/#typeset-upright" rel="noreferrer" target="_blank">https://www.w3.org/TR/css-writing-modes-3/#typeset-upright</a><br>> Typographic character units which are classified as Tr or Tu in [UAX50] are expected<br>> to have alternate glyphs or positioning for typesetting upright in vertical text.<br>> In the case of Tr characters, if such vertical alternate glyphs are missing from the<br>> font, the UA may <span class="gmail-il">wish</span> to [RFC6919] (but is not expected to) synthesize the missing glyphs<br>> by typesetting them sideways etc. </div><div><br></div><div>Forefox wishes to
synthesize the missing glyphs<br>by typesetting them sideways etc but not for other </div><div>characters. <span style="background-color:transparent">The proliferation of such a workaround </span></div><div><span style="background-color:transparent">might make things even </span><span style="background-color:transparent">worse eventually.</span></div><div style="background-color:transparent"><br></div><div>Forefox also implements an ad-hoc behavior for double vertical </div><div>line: it ignores the vert feature, although CSS Writing </div><div style="background-color:transparent">Modes clearly specifies that " (E.g. the OpenType vert feature must </div><div style="background-color:transparent">be enabled.) " <br><br>Regards,<br>Makoto</div></div></div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2020年8月8日(土) 11:41 Eric Muller <<a href="mailto:eric.muller@efele.net">eric.muller@efele.net</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">On 8/6/2020 3:11 AM, 梁海 Liang Hai wrote:<br>
> The behavior specified by UAX #50 is a decent low-level default at <br>
> most, and can’t address all the use cases. Therefore fonts naturally <br>
> need to be diverse and address the flexibility required by typography.<br>
<br>
I disagree with the second sentence, when interpreted anywhere close to <br>
"fonts can do anything". We need fonts to do their part. If a U+0041 A <br>
LATIN CAPITAL LETTER A is displayed by a "B", we can clearly blame the <br>
font and declare it useless for rendering text. Similarly if "MANZANITA" <br>
is displayed at "MAZNAZITA" by the font deciding to rotate N and Z, we <br>
are in trouble.<br>
<br>
I also disagree with the second sentence as a consequence of the first. <br>
UAX50 is not in control of the orientation. The author, via markup, is <br>
in control (at least, wants to be; that's implicit in Murata-san's <br>
presentation). UAX50 is there only to make the life of the author <br>
simpler, by minimizing markup. You can think of running a transformation <br>
on documents that inject explicit markup, according to UAX50, wherever <br>
the author did not explicitly put it. That document would have a precise <br>
meaning regardless of UAX50.<br>
<br>
The way I see the current situation is that we have many fonts that <br>
predate the need for the author to control the orientation regardless of <br>
the font, rather than the author reacting to the font. The later is <br>
acceptable in the print world, where layout is done at "factory" time, <br>
the author (in a broad sense) can see exactly what the reader will see, <br>
and can adjust his document to the font. It is problematic in the <br>
ebook/web world where the layout is done at "reading" time, with pieces <br>
or behaviors that the author does not always control (in particular <br>
fonts). In that world, we need fonts (and layout engines) that respect <br>
precisely the orientation chosen by the author (and of course document <br>
formats that let him or her express the desired orientation)<br>
<br>
The link between layout engines and fonts is the 'vert' feature. So what <br>
Murata-san wants is for the 'vert' feature to behave according to some <br>
known fixed rules (of course, the UAX50 rules are an obvious choice, but <br>
by no means necessary), rather than the current situation where MS <br>
Mincho does it one way and Meiryo does it another way. I can only see <br>
two solutions, after having picked the rules: 1) we fix the fonts that <br>
do not follow the rules or 2) we switch to a new feature that <br>
specifically imposes the rules (and may be fallback to 'vert') . I <br>
suspect that 1) is not an option.<br>
<br>
Eric.<br>
<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>