Re: [css-writing-modes-3] range limit for 'text-combine-upright: all' versus 'text-combine-upright: digits <integer>'

On 23/06/2015 19:16, Florian Rivoal wrote:
>
>> On 23 Jun 2015, at 18:45, Koji Ishii <kojiishi@gmail.com> wrote:
>>
>> On Jun 23, 2015, at 03:13, Gérard Talbot <www-style@gtalbot.org> wrote:
>>>
>>> Le 2015-06-22 14:03, Florian Rivoal a écrit :
>>>>> On 22 Jun 2015, at 11:35, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:
>>>>>> There seems to be no implicit (and no explicit) range limit to the number of consecutive characters when using 'text-combine-upright: all' but there is a range 2-4 limit with 'text-combine-upright: digits n':
>>>>>> Q1: is that assumption correct? (To me, this seems odd and incoherent.)
>>>>> Correct.
>>>>>> Q2: If there is no range limitation with 'text-combine-upright: all', then
>>>>>> why should there be one with 'text-combine-upright: digits n' where 'n'
>>>>>> would be a [2-9] digit?
>>>>> “all” is not likely to be affected much by the number of characters; it just measure the whole string, and shrink if needed.
>>>>> “digits” checks the number of characters, and thus could fail on specific number. A request was made to avoid implementations and testing that were never used in the real world.
>>>> I agree with Gérard.
>>>> I understand wanting to limit to 4 digits since there is no use case
>>>> for more if that makes implementations simpler.
>>>> I do not understand why the logic is not applied to the all value,
>>>> allowing it to only match up to 4 digits.
>>>
>>> Yes. Exactly what I thought. Thank you Florian.
>>
>> “all” is only about scaling. We don’t limit, for instance, transform: scale() even if scale factor such as 1,000,000 won’t be used at all, right?
>>
>> On the other hand, “digits" value has two effects; limits number of characters to apply, and when apply, it scales by 1em/width.
>
> I understand that that's what they do. But why?

i suspect that one fundamental difference is that you might apply the 
digit setting to a whole paragraph or section, in which case you expect 
runs of digits to be automatically identified and made horizontal, but 
you want to avoid trying that on numbers that won't fit.

with the all value, you have to have manually specified boundaries, 
based on inline markup. This means that the content author is making the 
choice about how many characters it makes sense to fit horizontally on a 
case by case basis.

another difference is that applying character-based width counting to 
letters is more complicated that applying to numbers. 'Character' is 
only defined as equivalent to 'extended grapheme cluster' for section 
5.1. So, for example, if you wanted to tate-chu-yoko a vietnamese word 
in NFD, you may apply the markup to, say, 12 characters, but only end up 
with 4 spacing character widths. Numbers don't include combining 
characters, so there's not the same question about whether the number of 
characters fits the width.

does that help?
ri

Received on Wednesday, 24 June 2015 09:05:05 UTC