Re: [css-text] Issue 18: character-based alignment in table columns

> On Jan 27, 2016, at 04:55, Alan Stearns <stearns@adobe.com> wrote:
> 
> On 1/27/16, 6:36 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
> 
>> On Tue, Jan 26, 2016 at 7:44 AM, Dave Cramer <dauwhe@gmail.com> wrote:
>>> Issue 18 in CSS Text 4 asks:
>>> 
>>>> Is this intended to say that it’s the centers of the alignment characters
>>>> that should be aligned?
>>>> It’s not clear that’s what it says, but that (or a different behavior)
>>>> needs to be specified,
>>>> to describe what happens when different occurrences of the alignment
>>>> character
>>>> are in different fonts. (Further, is that the intended behavior?
>>>> Probably the most significant use case to consider is bold vs. non-bold
>>>> text,
>>>> which only varies slightly in width.)
>>> 
>>> I've been looking at what InDesign does. It appears to align the origins of
>>> the alignment character glyphs, which sometimes does not result in the
>>> centers of the alignment characters being centered. I'm seeing similar
>>> behavior from a TeX package I tried. This is consistent with the printed
>>> examples we've found so far.
>> 
>> This sounds like those tools just not considering the case of the
>> texts being in different fonts or faces.  I don't think there's a good
>> reason to copy that bug.  You clearly want the texts *aligned*, and
>> aligning centers seems most likely to get you that result.
> 
> I agree. It’s likely this is an edge case that just never got considered or was never considered worth the time to address. In InDesign or TeX, when the problem crops up you can tell the user “If you want those things aligned, use the same font and size.” On the web that’s often not an option, so we can handle this edge case better.

There are not a lot of situations where you want to align on a character two pieces of text that are in a different font. The use case for this feature is aligning numbers. Maybe on a period, a comma, a colon or a semicolon, but you're generally aligning numbers and expecting digits to line up. When you're doing that, you need to make sure that not only the periods, but also all the digits are the same size, otherwise nothing is going to line up.

As far as I can tell, the only situation where you'd want to use different fonts is when one of the rows is in bold (maybe it's a total), and you'll need two fonts where all the digits and relevant punctuation are the same size.

Now yes, this is the web, and we have to deal with unreliability, so one of the fonts may fail to load, and we'll need to make do. But no matter what we do, if the character sizes don't match, it'll be wrong anyway.

I've been looking into this with Tzviya, and she checked with typographers as Wiley. They care about this feature for its main use case, but didn't think it had other use cases, and agreed that for this use case, if you don't have an equally sized font, there's not correct answer so it doesn't matter.

So sure, we can define it, and defining it to the center is probably as good as anything else, but as this is not only an edge case but also an error case where there is no correct answer, so if some implementers feel it would be easier or faster to do with a different rule, I'd be open to that.

 - Florian

Received on Wednesday, 27 January 2016 17:00:38 UTC