Re: [css3-writing-modes] Yet another approach to discuss Tr fallback issue for UTR#50 and text-orientation

Thank you for the feedback, Eric. This is really appreciated.

> 1. It is very likely that fallback is more costly  than no fallback, for
> all architectures.

I don't want to argue whether I agree with you or not on this point.

The point of my proposal is that, if this is all about implementation
cost, and if some people prefers another option, let's stop discussing
which is right and instead discuss what the motivation to reject one of
two options is.

Results differ only for a handful of minor code points and both sides
agree that it's a trivial difference. CSS needs to support non-OpenType
fonts too and we don't know much about them.

In this case, what is the motivation to mandate only one of two options
and reject the other? If someone believes whichever option is cheaper,
that's fine, I want him to allow such implementation, but why do we need
to reject other people saying the other option works better for them for
trivial differences?

In 5 years, maybe people figured out that you're right and all
implementations follow one of two options. CSS still lists two options, or
leave it undefined. What do we loose in this situation? Is this situation
worse than delaying CSS Writing Modes LC further?


/koji




On 11/1/13 7:36 AM, "Eric Muller" <emuller@adobe.com> wrote:

I believe option A (mandate a behavior) is overwhelmingly preferable,
for the reasons listed in Koji's message.

Some of the arguments for option B do not seem very convincing:

1. It is very likely that fallback is more costly  than no fallback, for
all architectures.
2. sounds like an argument that works both ways. In fact, in combination
with my observation on argument 1, it says that fallback is pretty much
undesirable (why would do something that is not useful and costs?), at
which point one has to conclude that "A without fallback" is the best
choice.

I believe that fallback cannot be implemented in the context of
OpenType. Fallback implies a way to discover that the fallback should be
triggered. The only conceivable way is to detect whether the application
of an OT feature (namely 'vert') did change the glyph. However, OpenType
features are not about doing things, they are about ensuring some
property after their application. What 'vert' guarantees is that after
it is applied, the glyph is appropriate for upright presentation. It
could very well be that the font is built to handle only vertical
writing and that the glyphs are already appropriate for upright
presentation, before 'vert' is applied, in which case 'vert' does
nothing. (If it helps, you can replace 'vert'/vertical presentation by
'lnum'/lining digits, 'tnum'/tabular digits, etc.) While it is true that
a foundry would rarely build a font such that it is usable only for
vertical writing, remember that rendering systems often have to deal
with fonts which have been generated by machine, e.g. fonts subsetted
for use in a particular document/style.

For me, the choice is rather straightforward: "mandate no fallback" is
by far the best resolution.

Eric.

Received on Friday, 1 November 2013 04:01:37 UTC