When describing text on a page in LibreOffice, we use the categories "direction" and in some cases "writing mode", whose values may be (assuming RTL-CTL and Asian language support is enabled): "Right to Left (Horizontal)" "Left to Right (Horizontal)" "Right to Left (Vertical)" "Left to Right (Vertical)" The parenthesized word indicates whether lines are oriented so that they extend progress horizontally or vertically on the page, and whether subsequent lines are placed at a vertical offset (for "Horizontal") or horizontal offset (for "Vertical"). That part is ok. Now, what does the RTL or LTR part mean? Here is the problem: For "Vertical", it means the direction in which additional lines fill the page: RTL means the first line is on the right side of the page, the second light is to its left etc., filling the page towards its left. LTR means the first line is on the left side, and additional lines fill the page towards its right. What about "Horizontal"? Consistency, and symmetry, would suggest that we don't see "Right to Left" and "Left to Right" here, but rather "Bottom to Top" "Top to Bottom": Whether the first line is placed at the top of the page and additional lines placed further down, or the first line is placed at the bottom and additional lines placed further up. Instead, RTL and LTR for the "Horizontal" case mean the default intra-line direction: Are subsequent same-direction stretches of text placed to the right of their predecessors, or to the left of their predecessors. That is inconsistent, and confusing, IMNSHO. Now, when Asian languages are disabled - everything is "fine": We only have the Horizontal case; we assume that lines start at the top of the page; and all we care about is the intra-line (or intra-paragraph) direction. I believe we need to change the dialog here: Option I ========= 1. When Asian languages are enabled, a different combo box will be presented, with label "Writing Mode:", and values: "Horizontal, Top to Bottom" "Vertical, Right to Left" "Vertical, Left to Right" with semantics as I have suggested one would expect (and _not_ as they are in CSS). A "Horizontal, Bottom to Top" option is missing, as we don't support it and it's not been requested (and CSS doesn't support it either). 2. The "Text Direction" box will _always_ have just two options, RTL or LTR (and inherit/use-superordinate), like CSS' direction attribute [1]. Option II ========== Same as option 1, but the "Text Direction" box will have RTL and LTR for a horizontal writing mode, but for Vertical writing modes, the box will have the options "Top to Bottom" and "Bottom to Top". This will correspond to how, in Vertical writing modes, the paragraph direction buttons' graphics is reoriented, so that the arrows point from top to bottom or from bottom to top. Note: It may also be useful to add a default text orientation setting for the page style, a-la CSS text-orientation [3]; or to support the "Sideways" writing modes. [1] : https://developer.mozilla.org/en-US/docs/Web/CSS/direction [2] : https://developer.mozilla.org/en-US/docs/Web/CSS/writing-mode [3] : https://developer.mozilla.org/en-US/docs/Web/CSS/text-orientation
(In reply to Eyal Rozenberg from comment #0) > "Right to Left (Horizontal)" > "Left to Right (Horizontal)" > "Right to Left (Vertical)" > "Left to Right (Vertical)" While I can easily read and understand the options, we can discuss possible improvements. (In reply to Eyal Rozenberg from comment #0) > "Horizontal, Top to Bottom" > "Vertical, Right to Left" > "Vertical, Left to Right" Not an improvement. (In reply to Eyal Rozenberg from comment #0) > Option II I understand it as Text Direction: ( ) Left-to-right (o) Right-to-left (o) Horizontal ( ) Vertical given Asian and CTL is enabled under tools > options > language (if Asian is off we can hide the direction), and your locale or preference is Arabic/Hebrew. I would not add labels, although this breaks accessibility. Sideways sounds wrong as label, "text flow" or "text orientation"... not ideal too.
It is indeed inconsistent. The term "Right to Left" is inline-progression-direction in "Right to Left (Horizontal)" but block-progression-direction in "Right to Left (Vertical)". It would become consistent, when the terms of XSL are used lr-tb rl-tb tb-rl tb-lr But that would not be understandable for users, so no option. So my take is to not change it, but be more verbose in the help. The help has currently: Text direction Select the text direction that you want to use in your document. The "right-to-left (vertical)" text flow direction rotates all layout settings to the right by 90 degrees, except for the header and footer. The help could mention inline vs block progression-direction, and could name scripts that use the direction. The label "text-direction" is wrong, should be "writing-mode". Look at the description of TextDirection and WritingMode and Writingmode2 in our API.
(In reply to Heiko Tietze from comment #1) > While I can easily read and understand the options, I believe you cannot - because, with respect - you misunderstand them: > I understand it as > Text Direction: ( ) Left-to-right (o) Right-to-left > (o) Horizontal ( ) Vertical It's actually not like that. With vertical layout, this box has no effect on the text direction, only on the direction in which consecutive lines are placed. Now, granted, the phrasing cannot be easy to understand for the novice user, who has not given methodical thought to text layout and the two kinds of directions it involves; but... > we can discuss possible improvements. before we consider what is easier or less easy to understand, we have to apply the criteria of: 1. Consistency. 2. Exposure of the necessary controls. 3. Minimization of clash / overlap of function other controls. We are currently not consistent (as Regina also verifies). But we are also missing a control: If you choose one of the Vertical options in the box, you have no way of setting the actual text direction property of the page (which, at the very least, applies to everything which uses "superordinate object direction". Like Columns, and the default paragraph style. And when we add that control - we would be clashing with its functionality for the Horizontal writing mode.
(In reply to Regina Henschel from comment #2) > It would become consistent, when the terms of XSL are used > lr-tb > rl-tb > tb-rl > tb-lr > > But that would not be understandable for users, so no option. Even regardless of ease of understanding - this would change the semantics, and drop our current support for bottom-to-top vertical. So you would need 6 options. But then it would be even more obvious that we need to split the direction property off from this list box. That's why I believe the CSS terms are the more appropriate ones: writing mode, direction (, and perhaps text-orientation although let's put that aside). Now, the steps for making this more understandable would be: 1. The splitting off of direction from writing mode - less to understand for each choice. 2. The use of longer labels rather than shorthands (which we already do, i.e. we don't say "lr" but "Left to Right"). 3. Consistency of semantics. 4. The preview graphic. It's already drawn incorrectly (bug 157554); we could do better than just correct it, but have it clearly indicate everything: * Whether lines are vertical or horizontal * In which direction of the page lines are added * Which direction along the line the text progresses * The glyph orientation > So my take is to not change it, but be more verbose in the help. Like I told Heiko, we have to be both consistent and cover the necessary settings, so I believe we can't leave things the way they are. But even if that wasn't a consideration - improving the help must never be an alternative to improving the UI, if a UI improvement is at all possible. The app must always stand on its own without relying on users consulting the help (with some rare exceptions). The help should always be extra, a fall back, in case we've not gotten through to some users despite our best efforts.
(In reply to Eyal Rozenberg from comment #4) > (In reply to Regina Henschel from comment #2) > > It would become consistent, when the terms of XSL are used > > lr-tb > > rl-tb > > tb-rl > > tb-lr > > > > But that would not be understandable for users, so no option. > > Even regardless of ease of understanding - this would change the semantics, > and drop our current support for bottom-to-top vertical. It would not change semantics. A "bottom-to-top vertical" mode is not implemented for page styles. The four terms I mentioned are exactly the terms used in the file markup. Look in styles.xml in office:automatic-styles > style:page-layout > style:page-layout-properties > style:writing-mode The writing-mode tb-lr is used in traditional Mongolian. More about the writing-modes is in the upcoming ODF 1.4 standard [1], section 20.404 in part 3. There the "bottom-to-top vertical" mode is called 'sideways-lr' with reference to CSS Writing Modes Level 4. [1] https://github.com/oasis-tcs/odf-tc/tree/master/docs/odf1.4/csd01
(In reply to Regina Henschel from comment #5) > It would not change semantics. A "bottom-to-top vertical" mode is not > implemented for page styles. Yes, you're right, I got myself mixed up. Sorry. But my "four point suggestion" stands... -------------------------------- (slightly-off-topic) > More about the writing-modes is in the upcoming ODF 1.4 standard [1], > section 20.404 in part 3. There the "bottom-to-top vertical" mode is called > 'sideways-lr' with reference to CSS Writing Modes Level 4. Wait, that can't be right... none of our writing modes has CJK glyphs set sideways (without otherwise rotating them). So we should not be corresponding to one of the 'sideways-lr' and 'sideways-rl' modes, but rather 'vertical-lr' and 'vertical-rl' modes [1]. Or am I missing something? [1] : https://developer.mozilla.org/en-US/docs/Web/CSS/writing-mode
> > More about the writing-modes is in the upcoming ODF 1.4 standard [1], > > section 20.404 in part 3. There the "bottom-to-top vertical" mode is called > > 'sideways-lr' with reference to CSS Writing Modes Level 4. > > Wait, that can't be right... none of our writing modes has CJK glyphs set > sideways (without otherwise rotating them). The attachment in bug 162201 has an example of 'sideways-lr' as table-cell style. It has CJK glyphs sideways. In contrast 'tb-lr' has CJK glyphs upright. Not only table-cells but a Frame in Writer has 'sideways-lr' too. If you find a 'sideways-lr' with upright CJK glyphs, it is a bug. When you examine the file source please remember that 'sideways-lr' is currently written as loext:writing-mode="bt-lr".
IF you're going to fix issues with writing system directionality, consider all of the directions that writing systems move in: • The Writing starts at the Bottom of the page moving up To the Top of the page, Vertically, with lines running from the Left hand side To Right hand side of the page. IOW, successive lines are to the right of each other; • The Writing starts at the Bottom of the page moving up to the Top of the page, Vertically, with lines running from the Right hand side To the Left hand side of the page. IOW, successive lines are to the left of each other; • The writing starts at the Top of the page, moving down To the Bottom of the page, Vertically, with lines running from the Left hand side of the page To the Right hand side of the page. IOW, successive lines are to the right of each other; • The writing starts at the Top of the page, moving down To the Bottom of the page, Vertically, with lines running from the Right hand side of the page To the Left hand side of the page. IOW, successive lines are to the left of each other; • The writing starts on the Left hand side of the page, moving To the Right hand side of the page, Horizontally, from the Bottom of the page To the Top of page. IOW, successive lines are above each other; • The writing starts on the Left hand side of the page, moving To the Right hand side of the page, Horizontally, from the Top of the page To the Bottom of the page. IOW, successive lines are below each other; • The writing starts on the Left hand side of the page, moving To the Right hand side of the page, Vertically, from the Bottom of the page To the Top of the page; • The writing starts on the Left hand side of the page, moving To the Right hand side of the page,Vertically, from the Top of the page To the Bottom of the page; • The writing starts on the Right hand side of the page, moving To the Left hand side of the page, Horizontally, from the Bottom of the page To the Top of the page. IOW, successive lines are above each other; • The writing starts on the Right hand side of the page, moving To the Left hand side of the page, Horizontally, from the Top of the page To the Bottom of the page; • The writing starts on the Right hand side of the page, moving To the Left hand side of the page, Horizontally, from the Top of the page To the Bottom of the page. IOW, successive lines are below each other; • The writing starts on the Right hand side of the page, moving To the Left hand side of the page, Vertically, from the Bottom of the page To the Top of the page; • The writing starts on the Right hand side of the page, moving To the Left hand side of the page, Vertically, from the Top of the page To the Bottom of the page; • The writing starts on the Right hand side of the page, moving To the Left hand side of the page,Horizontally, from the Bottom of the page To the Top of the page; • Boustropedon: The writing direction alternates on each line; • Boustropedon Clockwise: The writing direction is circular, moving in a clockwise direction; • Boustropedon Counter Clockwise: The writing direction is circular, moving in a counter-clockwise direction; • Reverse Boustropedon: The writing direction alternates on each line, with glyphs on alternate lines being upside down, in relation to the preceeding and successive line; • Reverse Boustropedon Clockwise: The writing direction is circular, moving in a clockwise direction, with glyphs on opposite side being upside down, in relation to each other; • Reverse Boustropedon Counter Clockwise: The writing direction is circular, moving in a counter clockwise direction, with glyphs on opposite side being upside down, in relation to each other; Writing systems with the following writing directions require additional hardware, and the appropriate drivers for that hardware, if they are to be correctly supported by LibreOffice. (FWIW, LibreOffice no longer supports the most commonly used writing system within this category). • 3-Dimensional; • 4-Dimensional; • Non-Linear; Writing systems with the following writing direction, can only be used by using _Draw_; As far as I know, the only writing systems that utilize these writing directions are conlang writing systems; • Left To Right 5 Degrees Downslant; • Left To Right 5 Degrees Upslant; • Left To Right 10 Degrees Downslant; • Left To Right 10 Degrees Upslant; • Left To Right 15 Degrees Downslant; • Left To Right 15 Degrees Upslant; • Left To Right 20 Degrees Downslant; • Left To Right 20 Degrees Upslant; • Left To Right 25 Degrees Downslant; • Left To Right 25 Degrees Upslant; • Left To Right 30 Degrees Downslant; • Left To Right 30 Degrees Upslant; • Left To Right 35 Degrees Downslant; • Left To Right 35 Degrees Upslant; • Left To Right 40 Degrees Downslant; • Left To Right 40 Degrees Upslant; • Left To Right 45 Degrees Downslant; • Left To Right 45 Degrees Upslant; • Left To Right 50 Degrees Downslant; • Left To Right 50 Degrees Upslant; • Left To Right 55 Degrees Downslant; • Left To Right 55 Degrees Upslant; • Left To Right 60 Degrees Downslant; • Left To Right 60 Degrees Upslant; • Left To Right 75 Degrees Downslant; • Left To Right 75 Degrees Upslant; • Left To Right 80 Degrees Downslant; • Left To Right 80 Degrees Upslant; • Left To Right 85 Degrees Downslant; • Left To Right 85 Degrees Upslant; • Right To Left 5 Degrees Downslant; • Right To Left 5 Degrees Upslant; • Right To Left 10 Degrees Downslant; • Right To Left 10 Degrees Upslant; • Right To Left 15 Degrees Downslant; • Right To Left 15 Degrees Upslant; • Right To Left 20 Degrees Downslant; • Right To Left 20 Degrees Upslant; • Right To Left 25 Degrees Downslant; • Right To Left 25 Degrees Upslant; • Right To Left 30 Degrees Downslant; • Right To Left 30 Degrees Upslant; • Right To Left 35 Degrees Downslant; • Right To Left 35 Degrees Upslant; • Right To Left 40 Degrees Downslant; • Right To Left 40 Degrees Upslant; • Right To Left 45 Degrees Downslant; • Right To Left 45 Degrees Upslant; • Right To Left 50 Degrees Downslant; • Right To Left 50 Degrees Upslant; • Right To Left 55 Degrees Downslant; • Right To Left 55 Degrees Upslant; • Right To Left 60 Degrees Downslant; • Right To Left 60 Degrees Upslant; • Right To Left 75 Degrees Downslant; • Right To Left 75 Degrees Upslant; • Right To Left 80 Degrees Downslant; • Right To Left 80 Degrees Upslant; • Right To Left 85 Degrees Downslant; • Right To Left 85 Degrees Upslant;
(In reply to Eyal Rozenberg from comment #6) > > More about the writing-modes is in the upcoming ODF 1.4 standard [1], > > section 20.404 in part 3. There the "bottom-to-top vertical" mode is called > > 'sideways-lr' with reference to CSS Writing Modes Level 4. > > Wait, that can't be right... none of our writing modes has CJK glyphs set > sideways (without otherwise rotating them). So we should not be > corresponding to one of the 'sideways-lr' and 'sideways-rl' modes, but > rather 'vertical-lr' and 'vertical-rl' modes [1]. Or am I missing something? > > [1] : https://developer.mozilla.org/en-US/docs/Web/CSS/writing-mode That might be a description of the Mongolian writing system, rather than CJKV. However, you can find examples of Traditional Chinese, with the columns moving from right to left, and the glyphs are rotated 90 degrees, so that they are read from bottom to top. and to further confuse one, there are examples of Simplified Chinese, with the columns moving from left to right, and the glyphs are rotated 90 degrees, so that they are read from top to bottom.
We discussed the topic in the design meeting. Following Regina's comments it might be reasonable to explain the relation between CSS or XSL terminology and our labels in the help. But I doubt this report has a real world background. Nevertheless, neither the people in the design call nor me have the expertise to give acceptable recommendations for an improvement. So up the RTL group. Happy to come up with a proposal if the full freedom of comment 8 will be implemented ;-)
Section 20.404.1, part 3, ODF 1.4 [1] allows the writing modes lr-tb, lr, rl-tb, rl, tb-rl, tb, tb-lr, sideways-rl, sideways-lr and page. Thereby "page" means an inheritance and lr=lr-tb, rl=rl-tb and tb=tb-rl. Our API has com::sun::star::text::WritingMode2 with values LR_TB, RL_TB, TB_RL, TB_LR, PAGE, CONTEXT, BT_LR, TB_RL90, STACKED. Thereby PAGE=CONTEXT. STACKED is similar to OOXML vert="wordArtVert" for shapes and not included in ODF 1.4. The task for UX is to find for each of them a wording for UI and use that wording consequently as far as possible. Currently the wordings are very different, depending on the object. The task for documentation would be to describe these writing modes in a way understandable for ordinary users. The state of implementation of a wording mode depends on the object which has the text. I don't think it's useful to refer to all the other possibilities in terms of writing direction, block and column arrangement and glyph orientation that are being developed for CSS4, for example. [1] https://github.com/oasis-tcs/odf-tc/tree/master/docs/odf1.4/csd01