[MPEG-OTSPEC] Vertical Writing: Character Orientations are Sometimes Uncontrollable

Wed Aug 12 07:47:27 CEST 2020

We still have to define what the scope of a "text shaping WG" would be. I commented on this in a separate thread yesterday: I think a useful scope that pertains to "shaping" can be defined by display of single lines of text. Certain meta information about the context of a line would be relevant inputs, including whether the line is within a horizontally or vertically oriented context. And that's a scope that would fit well for OpenType. 

There's more that may be relevant for interoperable layout of blocks of text—vertical or horizontal. Interoperability at that level is certainly important, especially for applications like ePub. But I think that's a scope that extends beyond OpenType.

Peter

-----Original Message-----
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of MURATA Makoto
Sent: Tuesday, August 11, 2020 6:52 PM
To: mpeg-otspec at lists.aau.at
Subject: Re: [MPEG-OTSPEC] Vertical Writing: Character Orientations are Sometimes Uncontrollable

Folks,

We are discussing the scope of the text shaping WG.
I hope that the text orientation issue in vertical writing provide a good example: interoperability of advanced typography is possible only when the contract between fonts and application programs is clearly defined and font developers can easily fulfill the contract.  I can imagine that other languages have similar issues.
Will the WG do something here?  Who should be involved?  Surely, the opinions of authors and application programmers are important.

Although I do have an interest in some patches to OpenType for addressing the text orientation issue, a big picture for the future of font technology is more important.

Regards,
Makotop

2020年8月12日(水) 7:44 Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>:
>
> Murata-san,
>
>
>
> You wrote:
>
> As far as I know, nobody in the Japanese font industry is interested 
> in updating existing fonts so that they comply with UAX#50.  This
>
> is understandable, since users frown on
>
> such changes.
>
>
>
> 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 “that specifically imposes the rules (and may be fallback to 'vert')”.
>
> 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?
>
>
>
> Thank you,
>
> Vladimir
>
>
>
>
>
> From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of 
> MURATA Makoto
> Sent: Tuesday, August 11, 2020 5:08 PM
> To: mpeg-otspec at lists.aau.at
> Subject: Re: [MPEG-OTSPEC] Vertical Writing: Character Orientations 
> are Sometimes Uncontrollable
>
>
>
> I agree with Eric.
>
> In the Internet world, authors do not know which application and which 
> font is used for rendering their contents, but they still would like 
> to ensure the same character orientation everywhere.  I suppose that 
> the same scenario probably applies to other features for other 
> languages, and
>
> that more and more problems will arise.
>
>
> David wrote:
> > * 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
> > * 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
>
> This is thoughtful advice.  But OpenType allows
>
> font developers to create their own glyph set,
>
> specify a cmap,'vert' and other features.  Thus,
>
> interoperability cannot be easily achieved.  A well-know glyph set 
> (such as AJ1) is a big help, but the standard 'vert' GSUB feature 
> definition of Adobe-Japan1 is not compliant with UAX #50 (Unicode 
> Vertical Text Layout).
>
> Eric wrote:
>
> >   I can only see two solutions, after having
>
> > picked the rules: 1) we fix the fonts that
>
> > do not follow the rules or 2) we switch to a
>
> > new feature that specifically imposes the
>
> > rules (and may be fallback to 'vert').  I
>
> > suspect that 1) is not an option.
>
> David wrote:
>
> > Which leads me to suspect that (2) is better than (1).
>
>
> As far as I know, nobody in the Japanese font industry is interested 
> in updating existing fonts so that they comply with UAX#50.  This
>
> is understandable, since users frown on
>
> such changes.
>
>
> As I see it, font developers often say that the rest is up to 
> application programmers.
> Poor application programmers are thus
> forced to implement ad-hoc behaviors
> depending on the character and
> also depending on the font used.
>
>
>
> For example, Firefox implements
>
> such an ad-hoc behavior for wavy dash.
>
>
>
> > Handle fallback (rotated) rendering of characters with 
> > Vertical_Orientation=Tr when the font does not support them via 
> > 'vert', nor is there a vertical presentation form encoded in Unicode.
>
> This is copied from
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> illa.mozilla.org%2Fshow_bug.cgi%3Fid%3D1431305&data=02%7C01%7C%7C7
> 952d32c10dd44f7ed9608d83e626a81%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1
> %7C0%7C637327939695594873&sdata=55XWFVa46fBdFHARP76EXEoLVGxqGZxXva
> M%2BSoY%2BRz0%3D&reserved=0
>
>
>
> This behavior is allowed by CSS Writing Modes.
>
>
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> w3.org%2FTR%2Fcss-writing-modes-3%2F%23typeset-upright&data=02%7C0
> 1%7C%7C7952d32c10dd44f7ed9608d83e626a81%7C84df9e7fe9f640afb435aaaaaaaa
> aaaa%7C1%7C0%7C637327939695594873&sdata=A3XqYCZb%2FGhgbfCzBZ5e%2Bf
> zPLKlTQmL%2FhpCL8byecWM%3D&reserved=0
> > Typographic character units which are classified as Tr or Tu in 
> > [UAX50] are expected to have alternate glyphs or positioning for typesetting upright in vertical text.
> > In the case of Tr characters, if such vertical alternate glyphs are 
> > missing from the font, the UA may wish to [RFC6919] (but is not 
> > expected to) synthesize the missing glyphs by typesetting them sideways etc.
>
>
>
> Forefox wishes to synthesize the missing glyphs by typesetting them 
> sideways etc but not for other
>
> characters.  The proliferation of such a workaround
>
> might make things even worse eventually.
>
>
>
> Forefox also implements an ad-hoc behavior for double vertical
>
> line: it ignores the vert feature, although CSS Writing
>
> Modes clearly specifies that " (E.g. the OpenType vert feature must
>
> be enabled.) "
>
> Regards,
> Makoto
>
>
>
> 2020年8月8日(土) 11:41 Eric Muller <eric.muller at efele.net>:
>
> On 8/6/2020 3:11 AM, 梁海 Liang Hai wrote:
> > 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.
>
> 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.
>
> I also disagree with the second sentence as a consequence of the first.
> UAX50 is not in control of the orientation. The author, via markup, is 
> in control (at least, wants to be; that's implicit in Murata-san's 
> presentation). UAX50 is there only to make the life of the author 
> simpler, by minimizing markup. You can think of running a 
> transformation on documents that inject explicit markup, according to 
> UAX50, wherever the author did not explicitly put it. That document 
> would have a precise meaning regardless of UAX50.
>
> The way I see the current situation is that we have many fonts that 
> predate the need for the author to control the orientation regardless 
> of the font, rather than the author reacting to the font. The later is 
> acceptable in the print world, where layout is done at "factory" time, 
> the author (in a broad sense) can see exactly what the reader will 
> see, and can adjust his document to the font. It is problematic in the 
> ebook/web world where the layout is done at "reading" time, with 
> pieces or behaviors that the author does not always control (in 
> particular fonts). In that world, we need fonts (and layout engines) 
> that respect precisely the orientation chosen by the author (and of 
> course document formats that let him or her express the desired 
> orientation)
>
> The link between layout engines and fonts is the 'vert' feature. So 
> what Murata-san wants is for the 'vert' feature to behave according to 
> some known fixed rules (of course, the UAX50 rules are an obvious 
> choice, but by no means necessary), rather than the current situation 
> where MS Mincho does it one way and Meiryo does it another way. I can 
> only see two solutions, after having picked the rules: 1) we fix the 
> fonts that do not follow the rules or 2) we switch to a new feature 
> that specifically imposes the rules (and may be fallback to 'vert') . 
> I suspect that 1) is not an option.
>
> Eric.
>
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7C%7C7952
> d32c10dd44f7ed9608d83e626a81%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C
> 0%7C637327939695594873&sdata=ziCP5GhIPVztCZQFnyBbu8Xql4yBqYIdNeMtk
> a8sSe4%3D&reserved=0
>
>
>
>
> --
>
> Regards,
>
> Makoto
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7C%7C7952
> d32c10dd44f7ed9608d83e626a81%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C
> 0%7C637327939695594873&sdata=ziCP5GhIPVztCZQFnyBbu8Xql4yBqYIdNeMtk
> a8sSe4%3D&reserved=0

--
Regards,
Makoto
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7C%7C7952d32c10dd44f7ed9608d83e626a81%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637327939695594873&sdata=ziCP5GhIPVztCZQFnyBbu8Xql4yBqYIdNeMtka8sSe4%3D&reserved=0