RE: [css3-writing-modes] inconsistent handling of 'Tr' codepoints in 'text-orientation'

Thank you a lot, I think we're narrowing down the point.

> >The benefits are for implementers. "The one that is simplest to code
> >and test" is different. Neither side says "I like this so I want to
> >write more code." Both sides say "this is much cheaper and simpler for me."
> 
> I do not understand how an option that requires an explicit check and a possible fallback
> is cheaper or simpler than an alternative that doesn't mandate either. But let's put that
> aside. If these two implementation approaches do produce the same results in all cases
> then why do we no need to specify them? Why should we constrain those who prefer a 3rd
> or a 4th way to one of these two? As long as the *valid result* is clearly specified there
> should be no need to set requirements on how it ought to be implemented. We don't define
> *how* implementors should do things, we standardize *what* they should do.

The spec is not how to implement, what results it should produce. Although both John and I said it's almost the same results, as John said, there are a few code points that might be affected in some fonts. John and I agreed that that difference is subtle, and tailoring is fine for users and authors.

So there are two different but both valid results. My proposal is to accept both results.

But then it looks like your key discussion is what you put aside. You're right, I guess I didn't explain much details about that, so let me try.

> >So the payoff of having two options is writing less code for everyone
> >we know as of today, without adding any more codes to anyone. If we
> >pick one, the other side has to write more code.
> 
> One of these options clearly requires more code than the other, Koji; so it can't be about
> everyone writing less code. So I think what you really mean is that by having both options
> you're saving *someone* some work because they've already taken this approach in their
> code? That is not a valid concern for a draft specification. This is a private concern of this
> one implementor.
> 
> But even if someone's existing code were a factor, I believe that whoever already
> implemented the fallback approach would be *removing* code, not writing more of it. It's
> true that it's new extra work for them but I don't buy they'd be worse off when done.

The first portion is right, thank you for understanding. The problem here is that that someone is in different layer, because Unicode is underlying layer of CSS. Let's say, someone in Skia (or CoreText or DWrite) team considered UTR behavior is important for drawing label controls and implemented it in Skia. This portion you're right that it's an additional code, but it's out of control for UA implementers.

Now a developer came in to implement a UA upon the Skia. It exposes vertical text drawing API with a flag:

enum VerticalOrientation { mixed, upright, sideways_left, sideways_right };

If CSS allows UTR-compliant results, all s/he needs is to pass the computed value of text-orientation to this API. Done, as little code as possible, no splits, fast.

If he needs to produce exactly the same result as John's proposal, he needs:
1. Have a table of code points of Tr
2. Every text run must be split into text without Tr code points and text of Tr
3. When drawing Tr text, it must pass "upright" to the API

It's not a private concern; all developers using the API have to write this additional code, and all such UA must pay the performance cost to split text runs.

You may, instead, ask Skia developers to add a flag to produce the same result as CSS specifies. Then there's no additional code for UA developers. But Skia team is in trouble by getting two different requests; one wants UTR-compatible behavior because the group agrees with UTR, the other wants tailored results because the group does not agree with UTR.

Is this good enough to understand, a large amount of developers must write more code if CSS does not allow Unicode-compatible behavior?

/koji

Received on Thursday, 3 October 2013 03:06:19 UTC