Re: [css-writing-modes] Should a combined white space at the end of a line be removed?

Thank you for answering.

I asked some people who know Japanese typography very well
including Toshi Kobayashi.

Our conclusion is that white spaces at the start/end of tate-chu-yoko
should always be trimmed. Therefore, your suggestion looks great.

I'd like to clarify:
1. The white-space property should prevent the trimming.
2. The Compression Rules should use the trimmed text.
3. The line breaking should use the actual contents of a text combine
instead of the trimmed text.

If we can change (3) to use the trimmed text, it becomes easier to
implement, but, I think it is needed to be compatible with the current spec
and current implementations.

I could implement the above except white-space support for WebKit. I think
it shouldn't be a problem from the perspective of implementation.

Best regards
Yuki Sekiguchi

On Wed, Aug 15, 2018 at 6:16 AM, fantasai <fantasai.lists@inkedblade.net>
wrote:

> On 08/13/2018 11:59 PM, Yuki Sekiguchi wrote:
>
>> Hi,
>>
>> I checked the following on Safari/Chrome/Firefox for macOS.
>> http://jsbin.com/nocidux/edit?html,output
>> <style>
>>    #tcy {
>>      border: solid 1px red;
>>      text-combine-upright: all;
>>      -webkit-text-combine: horizontal;
>>    }
>> </style>
>> <div style="writing-mode: vertical-rl">
>>    <span id="tcy"> </span>
>> </div>
>>
>> Safari shows the combined white space at the end of the line, but Chrome
>> and Firefox don't show it.
>>
>> Should the combined white space at the end of a line be removed?
>>
>> It looks like Chrome and Firefox remove the combined white space to
>> follow CSS 3 Text.
>> https://drafts.csswg.org/css-text-3/#white-space-phase-2
>>  > A sequence of collapsible spaces at the end of a line (ignoring any
>> intervening inline box boundaries) is removed.
>>
>> However, Safari doesn't remove the combined white space because it should
>> be considered as the Object Replacement Character
>> https://www.w3.org/TR/css-writing-modes-3/#text-combine-layout
>>  > For other text layout purposes, ... the resulting composition is
>> treated as a single glyph representing the Object Replacement Character
>> U+FFFC.
>>
>> I guess that Chrome and Firefox consider White Space Processing as line
>> breaking and follow:
>>  > For line breaking before and after the composition, it is treated as a
>> regular inline with its actual contents.
>>
>> I'm not sure if the removing is line breaking because the removing is
>> done after line breaking.
>>
>> Which is correct?
>>
>
> Wow, I don't know. From the specs you quote, it seems like Safari
> is correct, but I'm not sure it makes sense.
>
> It seems to me we did not consider what happens if there is white
> space at the start/end of tate-chu-yoko in general, e.g.
>   text <span id="tcy">tcy </span> text
> Maybe such white space should always be trimmed? Probably the best
> thing is to combine TCY before white space collapsing, and then
> additionally trim the white space at the start/end of the TCY.
>
> What do you think should happen?
>
> ~fantasai
>
>

-- 
.