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
the
    > following way: [...]
    >
    > Is this understanding correct?

    Yes! This is a correct understanding of 'mixed' orientation according
to
    CSSWM/UAX50.

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

    > > I think that every dash in Pd class (except PRESENTATION FORM FOR
VERTICAL)
    > > should be R or Tr, and that even 'R' dashes should have a 'vert'
alternate
    > > 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
existing
    > InDesign’s incompatibility with UAX50 about the above-mentioned R
characters
    > treated as ‘Tr’ glyphs by InDesign, included in the ‘vert’ feature,
because
    > the intended purpose was to prevent the glyphs from being
automatically
    > rotated by the application, but to provide the application with the
    > ‘pseudo-rotated’ glyph shapes, so that high precision in the
‘pseudo-rotated’
    > 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,
categorize
            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
UAX50/CSSWM
            applications to access an upright glyph when 'upright' mode is
            requested

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.

Regards,

--Taro




-- 
Regards,
Makoto
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