[css3-writing-modes] auto scaling and 'text-combine-horizontal'

>From the telcon discussion of 'text-combine-horizontal' this week [1]:

http://dev.w3.org/csswg/css-writing-modes/#text-combine-horizontal

# fantasai: ML discussion with jdaggett
# fantasai: jdaggett's proposal for exact rules of resizing. Spec says UA-defined
# fantasai: Put his algo as an example, eg. examples of things that could go wrong
# fantasai: but leave normative text as UA-defined, leave leeway
# fantasai: UA could give better results than this exact algorithm
# fantasai: Koji and I want to allow better results
# fantasai: but want to make sure it's at least "good". Having an example algo is a good way to do that
# florian: how to add controls in future levels on UA-defined behavior?
# fantasai: Plan is to have text-compression-switch, where the default is auto

The current spec *requires* that a set of glyphs be squished to fit
within a 1em space but it leaves the details of how up in the air.
There aren't an infinite range of options that user agents have here,
there are two basic options:

  1) Apply an x-scale operation to scale the glyphs to fit within 1em
  2) Use width-specific glyph variants if the font has them, otherwise use (1)

Option (2) implies using glyphs specifically designed by a type
designer for use in situations like tatechuyoko.  This is clearly the
better of these two options and given the wide support for OpenType
font features across existing user agents it's completely mystifying
to me that option (2) shouldn't be the normative behavior.

I'm perfectly fine with allowing UA's wiggle room in edge cases (e.g.
#12) but I think it's completely reasonable to make the use of the
proper width-variant glyphs be the norm, rather than some sort of
optional best-practice recommendation.

# SteveZ: users complain without the magic
# SteveZ: people want to do what the users expect
# SteveZ: to way to have this is normative text and test cases
# SteveZ: examples are nice but we trip over automagic
# fantasai: don't expect lock-in in this case
# fantasai: if you do a good job, no need to match against anything else
# fantasai: if it looks bad, you're just gonna not use the feature
# fantasai: no option to tweak the layout
# fantasai: enable tatechyu?? or not
# fantasai: no effect on the rest of the layout

Steve brings up another good point, without normative behavior defined
the only thing that can be tested here is whether the glyphs get
squished to 1em or not, regardless of the quality.  If you require the
proper use of width variants, you can test for that and improve *all*
user agents, not just those that choose to use the variant glyphs.

As I pointed out on the mailing list, requiring a stretch operation
but leaving the details undefined does *not* foster better results, it
only allows poorer results.  There's no "lock-in" involved in
requiring the use of proper width variants, future specs and evolve as
the underlying technology does.  The current spec allows user agents
to ignore the proper use of these width-variant glyphs and instead
*always* use a scaling transform.  Having "least common denominator"
user agents like this will make the feature unusable for some authors,
as the quality will of simply scaling will be unacceptable.

# plinss: problem is defining "better"
# plinss: objections?
# fantasai: proposal is: normative prose says "UA-defined how the
#           compression happens, but must transform full-width
#           and ??? before you do any scaling"
# fantasai: then add an example algo
# fantasai: and suggestions to do better
# fantasai: require transforming at least full-width
# fantasai: example of what people expect. Can do simpler,
#           can do smarter, but don't do this that looks bad
# RESOLVED: accepted the above proposal

s/simpler/poorer quality/ !!!!!!!!

I'll wait to see the revisions made to the editor's draft but after
looking at the implementation details of this more closely [2] I
strongly object to leaving the squishing operation undefined at this
level. Specifying a decent minimum level that all implementations need
to follow is not hard. We should do the right thing, not leave the
door open to hacky implementations that want to ignore OpenType
features.

Regards,

John Daggett

[1] http://logs.csswg.org/irc.w3.org/css/?date=2013-07-03
[2] http://lists.w3.org/Archives/Public/www-archive/2013Jul/0000.html

Received on Thursday, 4 July 2013 01:31:30 UTC