In vertical text direction, glyphs are oriented the same way as they are in horizontal text direction, but for placing the next glyph, we move up or down on the page rather than left or right. If, instead, we reorient the glyphs by 90 (or 270) degrees, and then progress right or left according to the glyphs' rotated coordinate system - those are rotated paragraphs, _not_ vertical text direction. In vertical text direction, we should see something like H E L L O instead of HELLO in horizontal. Again, the glyphs are _not_ themselves rotated/reoriented. An attachment will further exemplify this. Interestingly, the Page Style dialog, when presenting a mini-preview of the page, does indeed show A B C ↓ as expected, with no reorientation - but it's not what gets laid out.
Created attachment 186578 [details] Page style dialog - note the mini-preview
Created attachment 186580 [details] Horizontal and vertical alignment - illustrations with English and Japanese This file has 4 layout examples for English text ("HELLO WORLD"): * How vertical (LTR) text should be rendered, if glyph centers are aligned * How vertical (LTR) text should be rendered, if glph centers are not aligned (and left-edges are aligned) * How vertical (LTR) text is actually rendered (it's rotated) * How horizontal (LTR) text is actually rendered and 2 layout examples for Japanese text ("こんにちは 世界"): * How vertical (LTR) text is actually rendered (it's not rotated) * How horizontal (LTR) text is actually rendered
The character orientations for style:writing-mode="tb-rl" are correct in LibreOffice. The "tb-rl" is the writing-mode that is dedicated for vertical writing of east asian scripts like Chinese, Japanese or Korean. In this writing-mode east-asian characters are upright and characters from western languages are turned 90deg clockwise. You can find a good overview about text directions in https://www.w3.org/TR/?title=requirements&tag=i18n But the preview icon in the page properties dialog is indeed wrong. The direction arrow is correct, but it needs to show upright characters of Chinese or Japanese, perhaps combined with rotated ABC. Showing only ABC in 90deg rotated is not suitable, because in addition to "tb-rl" there will be a writing-direction "sideways-rl" in (hopefully) ODF 1.4, which will specify a 90deg rotation for _all_ characters. A text direction mode with characters ABC upright from top to bottom is called "stacked". Such is currently not a possible value of the style:writing-mode attribute and is not implemented in LibreOffice. PowerPoint has such "stacked" text direction for text in shapes. So the bug here is, that the preview icon needs to be improved.
(In reply to Regina Henschel from comment #3) > The character orientations for style:writing-mode="tb-rl" are correct in > LibreOffice. Correct according to what? > In this > writing-mode east-asian characters are upright and characters from western > languages are turned 90deg clockwise. Aren't you're making an argument in the wrong direction? "If Western languages are rotated in tb-rl (or tb-lr) writing mode, then it is correct for them to be thus rotated." ... that doesn't sound right. Anyway, as I understand the definition of a "writing mode" - that is incorrect. Writing text on paper does not involve rotation, ever. Rotation is something you might do with a paragraph (or other object) _after_ having written it. Glyphs have a natural orientation, and you write/draw them in that orientation; the writing mode controls how you place consecutive glyphs. Again, nobody writes rotated glyphs. > A text direction mode with characters ABC upright from top to bottom is > called "stacked". Such is currently not a possible value of the > style:writing-mode attribute and is not implemented in LibreOffice. It is possible: It is the tb-lr writing mode for English: https://l450v.alamy.com/450v/bw999j/odeon-cinema-sign-bw999j.jpg https://st.focusedcollection.com/13735766/i/1800/focused_167580596-stock-photo-hotel-sign-on-the-side.jpg https://c7.alamy.com/comp/S238P8/bar-sign-on-side-of-building-S238P8.jpg You used the word "stacked" - that's exactly like for Japanese. Japanese tb-rl is the glyphs "stacked" one over the other. > The "tb-rl" is the writing-mode that is dedicated for vertical > writing of east asian scripts like Chinese, Japanese or Korean. We've just agreed that Western script text can also be written in tb-rl or tb-lr modes... the question is how should it be written on those modes. > You can find a good overview about text directions in > https://www.w3.org/TR/?title=requirements&tag=i18n I'll have a look at that.
(In reply to Regina Henschel from comment #3) > You can find a good overview about text directions in > https://www.w3.org/TR/?title=requirements&tag=i18n So, please go there, click the requirements for Chinese, and have a look at Section 2.4.2: https://www.w3.org/TR/2023/DNOTE-clreq-20230401/#latin-one-by-one Clause 2.1. of that section says "In vertical writing mode, there are 3 methods for arranging Western text or European numerals" These methods are: * The mode I described, i.e. Western glyphs in regular orientation. * Rotation - what LO does now * Pure horizontal, i.e. you get a stretch of horizontal text cutting a vertically-progressing sequence Here are renderings of the first two methods: https://www.w3.org/TR/2023/DNOTE-clreq-20230401/images/en/latin-one-by-one.svg https://www.w3.org/TR/2023/DNOTE-clreq-20230401/images/en/latin-90-clockwise.svg so, it seems this document agrees partially with what I said, and partially with what you said.
(In reply to Eyal Rozenberg from comment #5) ... and about the same thing is said about Japanese: https://www.w3.org/TR/2020/NOTE-jlreq-20200811/#vertical_writing_mode_and_horizontal_writing_mode in both case it's said that rotation is common for words or sentences in Western languages, while proper vertical order with no rotation "is usually applied to one-letter alphanumerics or capitalized abbreviations". What this means is that when writing a predominantly CJK paragraph, we need to _sometimes_ rotate and _sometimes_ not rotate. So the rotation or lack thereof must be a property of _stretches of non-CJK text_, not of a paragraph or a page. We may also need to be smart about choosing what to do by default (e.g. avoid rotation until we see a lowercase letter in English). With all of that said - when writing purely in Western languages (or RTL languages with block shapes like Hebrew) - the logic of "rotation for stretches of text" does not apply (in my opinion), or only applies sometimes (if we want to use the same logic as with CJK).
LibreOffice renders it in one way, when you set the text direction. Thereby the text direction is often inherit from the layout environment of an object. If you need a different glyph orientation for a portion of text, you can use the settings in the 'Position' tab of the character properties. The preview icon can be improved. Implementation of a "stacked" writing-mode for paragraphs and for frames is missing. If you want such, please write an enhancement request. We should use this bug report to improve the misleading preview icon.
(In reply to Regina Henschel from comment #7) > LibreOffice renders it in one way, when you set the text direction. Thereby > the text direction is often inherit from the layout environment of an object. I'm not sure I understand this sentence. > If you need a different glyph orientation for a portion of text, you can use > the settings in the 'Position' tab of the character properties. I need LO to do what I told it to do, which is render my English text in vertical writing mode. Now, given the information at the links - if the larger-piece-of-text is in a CJK language/script but contains a smaller-piece-of-text in Western script, or even in a Western language - then it would be acceptable for LO to diverge from literal conformance to the settings made. But even then, the default should probably be some kind of reasonable heuristic. An override of the heuristic should not necessitate setting a value for each and every stretch of Western-script text in a CJK document - that is very cumbersome. > Implementation of a "stacked" writing-mode for paragraphs and for frames is > missing. If you want such, please write an enhancement request. LO claims to offer vertical writing mode, and instead rotates. Fixing this is fixing a bug, not making an enhancement. It is also may be considered kind of a bug to conflate rotation of stretches of text with the writing direction, but I don't have a strong opinion on that.
Like Regina said, this is not a bug. Rotated horizontal text in the middle of vertical text is by far the most common and what users of vertical text expect. What is requested here is an enhancement request and should be re-worded as such.
(In reply to خالد حسني from comment #9) > Like Regina said, this is not a bug. Rotated horizontal text in the middle > of vertical text is by far the most common and what users of vertical text > expect. I'll first note that the question of users' expectation is a bit tricky, because if we have chosen a certain default - existing users would expect that default, because they're used to it. We have had a somewhat similar discussion about the request to make "tabbed UI" the default: Many argue that it's what users expect - but they only expect it, if at all, if they're used to Microsoft Office. My point is, that if we don't allow separate control of text direction and glyph orientation, then it is a literal mistake to offer an orientation option which is nothing but rotation. If you offer rotation, you need to say that's what it is. And it is inconsistent when LTR text will just be rotated while CJK text will not. The conflation of text block rotation and text orientation is not limited to just in the dialog UI. Here: https://help.libreoffice.org/6.2/en-US/text/scalc/guide/text_rotate.html they are mixed up. To get another point of reference, I checked what happens in CSS. Well, it has two related properties: * writing mode: https://developer.mozilla.org/en-US/docs/Web/CSS/writing-mode * text orientation: https://developer.mozilla.org/en-US/docs/Web/CSS/text-orientation if we offered _both_ of these together, I wouldn't mind the choice of default as much, because the outcome would be clear. Otherwise, either the default should change, or the labels should explain things better.
Added the URL of a CSS playground where one could check out the combinations of text-direction and text-orientation.
Don't know how UX can contribute to this discussion (whether writing mode is correct or not vs. how to change the preview). Removing the keyword and adding some experts.
Btw, if there is such a serious issue I'd expect a duplicate ticket. For example bug 114002.
(In reply to Heiko Tietze from comment #13) > Don't know how UX can contribute to this discussion You can help decide what combination of widgets should control direction and orientation in the Page Style dialog. You could perhaps also help reviewing my claim that what we have right now is confusing for some users. > Btw, if there is such a serious issue I'd expect a duplicate ticket. The likely reason this is not a "serious" issue is that it only affects non-CJK glyphs, and few Westerners care about this direction to begin with. In fact, > For example bug 114002. ... that _is_ a way this issue is "serious". You see, because we treat this writing direction as a rotation - and probably some of the implementing code also does that - we assume glyphs are supposed to be rotated. Which they are not. Different languages have different conventions regarding the potential orientations of their glyphs (what's possible and what's common/default). If we had respected that, and not assumed we should "rotated everything sans certain exceptions", bug 114002 would not have occurred.
Presented the topic in the ESC. Current behavior is presumably correct, yet enhancing it with a 90° rotation state of the characters possible. Would be an enhancement in this case. I wonder if this should work out of the box when combining the page style with rotated characters (doesn't work correctly though). 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.
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. See: https://developer.mozilla.org/en-US/docs/Web/CSS/text-orientation https://www.gimp.org/news/2018/08/19/gimp-2-10-6-released/#vertical-text-layers
(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...
We use https://www.unicode.org/reports/tr50/tr50-28.html#vo to determine the default orientation of a given character.
Created attachment 188023 [details] Writing mode description in ODF 1.4 I think, we have (at least) two problems here. So the issue should be divided into two reports. (A) The example window in the dialog does not show the essential property of the text direction. The example shown there is not a fixed image but generated content depending on the settings of the page style. The text shown in the example is generated in https://opengrok.libreoffice.org/xref/core/svx/source/dialog/pagectrl.cxx?r=444bf871#222 It might already help to add an east Asian glyph to the "ABC" text, "ABC本" for example. It needs to be something, which allows to see the direction in small font size. (And of cause which has a neutral meaning.) BTW, the text direction setting in frame styles in Writer have no example at all but only the text description. (B) "Stacked" writing modes are missing. Vertical without character rotation is currently only available as character property or for table cell styles in ODF. Implementing a "stacked" writing mode requires an extension to the file format. A "stacked" writing mode would be of most interest for shapes and frames. I don't think that a "stacked" writing mode is useful for pages. The attached document contains the description of the writing modes in ODF 1.4.
(In reply to Eyal Rozenberg from comment #17) > 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. On Chrome, Firefox, GIMP, Inkscape I saw all of them have some abilities to handle glyph orientation for vertical layout. SO I believe there are some internal API could be make use of.
So, shall we split this bug in two? one for the preview and one of the ability to control glyph orientation in addition to the writing mode?
(In reply to Eyal Rozenberg from comment #21) > So, shall we split this bug in two? one for the preview and one of the > ability to control glyph orientation in addition to the writing mode? Yes. They are different problems. Changing the preview is a simple improvement to the UI. The glyph orientation problem needs a deeper analysis: Use cases, effected objects, relationship to writing-mode, relationship to existing glyph rotation, investigate whether a change/addition to file format is required or whether it can be solved by a wizard in the UI. A lot of work to do.