W3C home > Mailing lists > Public > www-archive@w3.org > December 2019

Fwd: UAX#50 conformance: Is it possible to update existing fonts without causing damage to existing non-CSS applications?

From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Date: Thu, 12 Dec 2019 13:51:53 +0900
Message-ID: <CALvn5EDtNyFTOJMKii93LCH=Q3ycZuyqYrk8aH8x3EydVcsCcw@mail.gmail.com>
To: www-archive@w3.org
---------- Forwarded message ---------
From: Taro Yamamoto <tyamamot@adobe.com>
Date: 2019年12月12日(木) 10:20
Subject: Re: UAX#50 conformance: Is it possible to update existing fonts
without causing damage to existing non-CSS applications?
To: fantasai <fantasai@inkedblade.net>
Cc: Florian Rivoal <florian@rivoal.net>, MURATA Makoto <
eb2m-mrt@asahi-net.or.jp>, Nat McCully <nmccully@adobe.com>

    > My current understanding of your explanation seems to be expressed in
    > following way: [...]
    > Is this understanding correct?

    Yes! This is a correct understanding of 'mixed' orientation according

I'm glad to know that my understanding of this issue has been improved to a

    > > I think that every dash in Pd class (except PRESENTATION FORM FOR
    > > should be R or Tr, and that even 'R' dashes should have a 'vert'
    > > with a rotated glyph, because even in upright styles of
typesetting, it would
    > > be desired to have them rotated.
    > If ‘vrtr’ characters are assumed to be rotated by the application
always, even
    > with some modified glyph shape, it doesn’t seem to avoid the current
    > InDesign’s incompatibility with UAX50 about the above-mentioned R
    > treated as ‘Tr’ glyphs by InDesign, included in the ‘vert’ feature,
    > the intended purpose was to prevent the glyphs from being
    > rotated by the application, but to provide the application with the
    > ‘pseudo-rotated’ glyph shapes, so that high precision in the
    > output results should be guaranteed.
    -> For other characters--specifically, those which should be rotated in
        'mixed' mode, but need to be upright in 'upright' mode:

         C. If there is no significant content compatibility problem,
            as R and ensure that fonts are generated with appropriate 'vert'
            and 'vrtr' glyphs to work with both 'upright' and 'mixed' modes.

         D. If there is a significant content compatibility problem, then
            we need to create some alternate system which allows existing
            applications to use 'vert' as they expect, but provides
            applications to access an upright glyph when 'upright' mode is

As I've been thinking UAX50 is for the 'mixed' mode, I haven't ever
considered the issue of supporting the 'upright' mode.
Nat might have some ideas about how applications to support it.



Received on Thursday, 12 December 2019 04:52:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:17 UTC