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

Wed Aug 12 01:46:21 CEST 2020

Vladimir,

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.

Regards...

-- Ken

> On Aug 11, 2020, at 16:44, Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com> wrote:
> 
> 
> 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://bugzilla.mozilla.org/show_bug.cgi?id=1431305
>  
> This behavior is allowed by CSS Writing Modes.
>  
> https://www.w3.org/TR/css-writing-modes-3/#typeset-upright
> > 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://lists.aau.at/mailman/listinfo/mpeg-otspec
> 
>  
> --
> Regards,
> Makoto
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200811/925ee643/attachment.html>