<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">Personally I do not think allowing fonts to influence itemization result is a good idea. </span><span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">Instead,
we could start leveraging "vrtr" feature by applying them to rotated ("non-sideways" in DWrite terms) runs, so no matter how the itemizer decide whether a character is rotated or upright, the font could always provide a rescue.</span><br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Yours,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Renzhi</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>发件人:</b> mpeg-otspec <mpeg-otspec-bounces@lists.aau.at> 代表 Ken Lunde <ken.lunde@gmail.com><br>
<b>发送时间:</b> 2020年8月11日 16:46<br>
<b>收件人:</b> Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com><br>
<b>抄送:</b> mpeg-otspec@lists.aau.at <mpeg-otspec@lists.aau.at><br>
<b>主题:</b> [EXTERNAL] Re: [MPEG-OTSPEC] Vertical Writing: Character Orientations are Sometimes Uncontrollable</font>
<div> </div>
</div>
<div dir="auto">
<div dir="ltr">Vladimir,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Registering and implementing a new vertical layout feature, which requires virtually all East Asian fonts to be updated, equates to a complete non-starter, in my professional opinion.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Regards...</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">-- Ken</div>
<div dir="ltr"><br>
<blockquote type="cite">On Aug 11, 2020, at 16:44, Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style>
<!--
@font-face
{font-family:"MS Gothic"}
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
@font-face
{}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif}
a:link, span.x_MsoHyperlink
{color:blue;
text-decoration:underline}
a:visited, span.x_MsoHyperlinkFollowed
{color:purple;
text-decoration:underline}
p.x_msonormal0, li.x_msonormal0, div.x_msonormal0
{margin-right:0in;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif}
span.x_gmail-il
{}
span.x_EmailStyle19
{font-family:"Calibri",sans-serif;
color:#1F497D}
.x_MsoChpDefault
{font-family:"Calibri",sans-serif}
@page WordSection1
{margin:1.0in 1.0in 1.0in 1.0in}
div.x_WordSection1
{}
-->
</style>
<div class="x_WordSection1">
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">Murata-san,</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">You wrote:</span></p>
<p class="x_MsoNormal">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 </p>
<p class="x_MsoNormal">is understandable, since users frown on </p>
<p class="x_MsoNormal">such changes.</p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">So, for the sake of an argument, let’s hypothesize that instead of updating some of the existing fonts to support new version of UAX#50-compliant ‘vert’ feature
implementation, we decided to switch to a new [yet to be standardized] feature “</span>that specifically imposes the rules (and may be fallback to 'vert')<span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">”.
</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">How do we expect this feature be implemented? Won’t we need ALL implementations and ALL fonts to be updated for the new feature to work? If users frown upon
any changes in existing Japanese fonts, why do you believe defining a new feature would make a difference?</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">Thank you,</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D">Vladimir</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:#1F497D"> </span></p>
<p class="x_MsoNormal"><b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif"> mpeg-otspec <mpeg-otspec-bounces@lists.aau.at>
<b>On Behalf Of </b>MURATA Makoto<br>
<b>Sent:</b> Tuesday, August 11, 2020 5:08 PM<br>
<b>To:</b> mpeg-otspec@lists.aau.at<br>
<b>Subject:</b> Re: [MPEG-OTSPEC] Vertical Writing: Character Orientations are Sometimes Uncontrollable</span></p>
<p class="x_MsoNormal"> </p>
<div>
<p class="x_MsoNormal">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 </p>
<div>
<p class="x_MsoNormal">that more and more problems will arise.</p>
<div>
<p class="x_MsoNormal"><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 </p>
</div>
<div>
<p class="x_MsoNormal">font developers to create their own glyph set, </p>
</div>
<div>
<p class="x_MsoNormal">specify a cmap,'vert' and other features. Thus,</p>
</div>
<div>
<p class="x_MsoNormal">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:</p>
</div>
<div>
<p class="x_MsoNormal">> I can only see two solutions, after having </p>
</div>
<div>
<p class="x_MsoNormal">> picked the rules: 1) we fix the fonts that</p>
</div>
<p class="x_MsoNormal">> do not follow the rules or 2) we switch to a </p>
</div>
<div>
<p class="x_MsoNormal">> new feature that specifically imposes the</p>
</div>
<div>
<p class="x_MsoNormal">> rules (and may be fallback to 'vert'). I </p>
</div>
<div>
<p class="x_MsoNormal">> suspect that 1) is not an option.</p>
<div>
<p class="x_MsoNormal">David wrote:</p>
</div>
<div>
<p class="x_MsoNormal">> Which leads me to suspect that (2) is better than (1). </p>
</div>
<div>
<p class="x_MsoNormal"> <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 </p>
</div>
<div>
<p class="x_MsoNormal">is understandable, since users frown on </p>
</div>
<div>
<p class="x_MsoNormal">such changes.</p>
</div>
<div>
<p class="x_MsoNormal"><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. </p>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal">For example, Firefox implements </p>
</div>
<div>
<p class="x_MsoNormal">such an ad-hoc behavior for wavy dash.</p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal">> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FOPiOCXD0wrhXQZzxi6gfj1&data=02%7C01%7Crenzhi.li%40microsoft.com%7C3f65ad17276840c066fa08d83e50c620%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637327863940921173&sdata=ltzdeDLc6kLIs9xqkbLh0QEnQ%2B%2FOYuqurk8qUEcgcXY%3D&reserved=0" originalsrc="https://protect-us.mimecast.com/s/OPiOCXD0wrhXQZzxi6gfj1" shash="iukwq7GuBALF4n8vdWTSDiZF8g+bLOO+kIiwXMnSUHKaaQCV6tjYU332XopuiuNS7M/9hTjY5Fvs4R/Ju5Uy1gIORgRn9FddopOFUhPWwG81sUlLXlQFnKFDPH5zDW8gbZCqysZaZ7RN1cjSaCufYRtlBS+Weo0zMs3C3RZ+OUc=">https://bugzilla.mozilla.org/show_bug.cgi?id=1431305</a></p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal">This behavior is allowed by CSS Writing Modes.</p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FwYQCCYEnxytL7X4zCG401e&data=02%7C01%7Crenzhi.li%40microsoft.com%7C3f65ad17276840c066fa08d83e50c620%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637327863940931167&sdata=F59T2PmMRIZa1uMGvFd82Bk3KN7j2IB3LzJlgtAU%2Fz4%3D&reserved=0" originalsrc="https://protect-us.mimecast.com/s/wYQCCYEnxytL7X4zCG401e" shash="JgE8sP98k4K7DFM1wNjgR2IOaXl5ErJwChb8rC7ewe7x87M8oyrxwpq+VVz2dueBwQap8UsJLrYG8jxOBBrO23o68HyAO35Oupod0B52BqBv5/5njFGXDJlz4Jvm6c7QqkX8zy0rI2LaPliJfBBRiqhByIw93KgxBK7vtshsTtY=" 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="x_gmail-il">wish</span> to [RFC6919] (but is not expected to) synthesize the missing glyphs<br>
> by typesetting them sideways etc. </p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal">Forefox wishes to synthesize the missing glyphs<br>
by typesetting them sideways etc but not for other </p>
</div>
<div>
<p class="x_MsoNormal">characters. The proliferation of such a workaround </p>
</div>
<div>
<p class="x_MsoNormal">might make things even worse eventually.</p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal">Forefox also implements an ad-hoc behavior for double vertical </p>
</div>
<div>
<p class="x_MsoNormal">line: it ignores the vert feature, although CSS Writing </p>
</div>
<div>
<p class="x_MsoNormal">Modes clearly specifies that " (E.g. the OpenType vert feature must </p>
</div>
<div>
<p class="x_MsoNormal">be enabled.) " <br>
<br>
Regards,<br>
Makoto</p>
</div>
</div>
</div>
</div>
<p class="x_MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<div>
<p class="x_MsoNormal">2020<span style="font-family:"MS Gothic"">年</span>8<span style="font-family:"MS Gothic"">月</span>8<span style="font-family:"MS Gothic"">日</span>(<span style="font-family:"MS Gothic"">土</span>) 11:41 Eric Muller <<a href="mailto:eric.muller@efele.net">eric.muller@efele.net</a>>:</p>
</div>
<blockquote style="border:none; border-left:solid #CCCCCC 1.0pt; padding:0in 0in 0in 6.0pt; margin-left:4.8pt; margin-right:0in">
<p class="x_MsoNormal">On 8/6/2020 3:11 AM, <span style="font-family:"MS Gothic"">
梁海</span> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FQnOnCZ6oyzh56Yp3iKk3-0&data=02%7C01%7Crenzhi.li%40microsoft.com%7C3f65ad17276840c066fa08d83e50c620%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637327863940931167&sdata=um4sC8tFW2DvGwB9SNI6W45P%2FDDw7tKD1q2pd%2Bc6B1A%3D&reserved=0" originalsrc="https://protect-us.mimecast.com/s/QnOnCZ6oyzh56Yp3iKk3-0" shash="fFyht+2vEraJA5bLUp4EVmL5Cj1jSIc/9UcltKq8MAW+YjBxB1iCRbZtMtAQqcV/ZhV6S0KRrSBys25AePCjHGMnZOq7M+tpIjKrL3L5OQFVyPz9eB8kNhExQFfX9E1KZ0hIYWmrhGsEb64RjHN4jJHNmEwFKYNOWe8iFF3R8og=" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a></p>
</blockquote>
</div>
<p class="x_MsoNormal"><br clear="all">
</p>
<div>
<p class="x_MsoNormal"> </p>
</div>
<p class="x_MsoNormal">-- </p>
<div>
<div>
<div>
<p class="x_MsoNormal">Regards,</p>
</div>
<div>
<p class="x_MsoNormal">Makoto</p>
</div>
</div>
</div>
</div>
<span>_______________________________________________</span><br>
<span>mpeg-otspec mailing list</span><br>
<span>mpeg-otspec@lists.aau.at</span><br>
<span>https://lists.aau.at/mailman/listinfo/mpeg-otspec</span><br>
</div>
</blockquote>
</div>
</body>
</html>