https://bugs.documentfoundation.org/show_bug.cgi?id=154756

--- Comment #17 from Eyal Rozenberg <[email protected]> ---
(In reply to Heiko Tietze from comment #15)
> Presented the topic in the ESC. Current behavior is presumably correct

Correctness does not improve after presentation of behavior in the ESC... Did
someone in the ESC give a convincing argument why they believe vertical text
direction = rotation of text? :-(

>, yet
> enhancing it with a 90° rotation state of the characters possible.

Rotation of (Latin) characters is what we have now. The basic problem is an
incorrect semantics of setting text direction. It's as though RTL direction
were implemented via 180° rotation of the text, and then you'd tell me that it
can be enhanced by rotating the individual glyphs 180°.

(In reply to Volga from comment #16)
> To implement this, LibreOffice need to satisfy following conditions: 1) Call
> for API that forced character upright in vertical layout from our libraries.
> 2) Add options on the interface. 3) Implement additional attribute to save
> into documents.
> 
> This require all characters to be LTR direction.

Let me start with (3.) and (2.) then focus on (1.).

So, ODF needs needs three attributes:

* vertical-major vs horizontal-major text progression
* LTR vs RTL text progression
* glyph orientation

and (possibly contextual) defaults for these. IIANM, the first and second
attributes are rolled up into a single 4-valued attribute we already have.

The interface currently reflects the 4-valued text direction attribute. Another
widget right underneath could control glyph orientation. That's the easy part.

Now, about (1.) - I don't quite understand. Why do we need extra API for
"forcing glyphs upright"? If that were the case, CJK glyphs would be rotated as
well. But certainly some internal API changes would be necessary. What I'm
worried about is that the code currently makes the assumption that direction =
rotation, or conflates glyph orientation with text direction, and that's
something which needs addressing regardless of functionality.

> 
> Besides the enhancement it would be nice to change the preview but IMO low
> priority- affected users do understand the effect of changing the text
> direction.

I actually believe that UI "veracity" is very important. Better to just turn
the preview off (and perhaps say "no preview") than to present an invalid
preview...

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to