Created attachment 181628 [details] upper left corner of a document after following the repro instructions To reproduce: 1. Create a new Writer document. 2. Type in Enter, then "hello world". 3. Select all text. 4. On the menus, choose Format | Character... 5. Choose the Position tab 6. Set the rotation angle to 90 degrees 7. Close the dialog 8. Press the "Toggle Formatting Marks" dialog on the main toolbar Expected result: First paragraph's p-mark at left edge of writable area, second paragraph just below it, after the last upwards-facing "d" of "hello world". Actual result: First paragraph as expected, second paragraph - in vertical middle and on top of the text itself.
Created attachment 181652 [details] Screenshot Plus, the paragraph break is not working as expected putting "World" into a second vertical line when return is pressed after "Hello". The line break does the trick, however.
Thing is that you rotate a character not the paragraph, which makes the expectation incorrect. What do you think, Mike?
(In reply to Heiko Tietze from comment #2) > Thing is that you rotate a character not the paragraph, which makes the > expectation incorrect. Kind of. The two paragraphs are still positioned top-to-bottom, with horizontal (LTR) orientation. The first paragraph has a character property "oriented vertically (bottom-to-top)"; and that property makes it also show the *paragraph mark* that way. The paragraph mark *starts* vertically in the middle, and horizontally at the left, of the paragraph characters. But since the mark's image is also rotated, it partially overlaps the text. So I would consider drawing paragraph mark that way as misleading and wrong, even when the character rotation is the paragraph's property. The mark's orientation IMO should follow the orientation set in Paragraph->Alignment->Text direction.
(In reply to Mike Kaganski from comment #3) To see what is my idea of correct rendering in this case: create a normal paragraph; type "lorem " (with the trailing space); select "lorem" (without the space), and apply vertical character rotation. Indeed, the space between the rotated text and the paragraph mark should be mentally removed.
(In reply to Heiko Tietze from comment #1) > Plus, the paragraph break is not working as expected putting "World" into a > second vertical line when return is pressed after "Hello". Separate bug?
(In reply to Heiko Tietze from comment #2) > Thing is that you rotate a character not the paragraph, which makes the > expectation incorrect. I expect the paragraph-mark to appear at the place where the next character would appear, if I were to type one at the end of the paragraph's existing text. I also expect, and independently of the other point, the paragraph-mark not to overlap the paragraph's text (assuming further typing would not cause such overlap). Now, if typing at the end of the paragraph were to continue non-rotated for some reason - or if you insisted that the p-mark logic must ignore rotation - then at the very least it should be like Mike suggested.
(In reply to Eyal Rozenberg from comment #6) > if you insisted that the p-mark logic must ignore rotation Please note that you silently mix two things: paragraph direction, and character direction - into a single sentence, making the logic flaw not obvious. "the paragraph-mark to appear at the place where the next character would appear" expectation must only apply to the *caret* - paragraph mark has nothing to do with this expectation. Paragraph mark indicates *the direction at which the next paragraph would appear* if you decide to create one. And the horizontal position (and correct upright glyph orientation, which is absent now!) of the mark indicates that: your next paragraph will appear below this paragraph, as in other "normal" horizontal paragraphs, no matter what *character rotation* it uses. Now compare that to e.g. paragraphs in table cells, where you can set vertical orientation by modifying table cell's text orientation on Text Flow properties tab. That changes the position and the rotation of the paragraph mark, correctly. The real (and only) bug (as discussed in this report) is the glyph rotation.
(In reply to Mike Kaganski from comment #7) > (In reply to Eyal Rozenberg from comment #6) > Please note that you silently mix two things: paragraph direction, and > character direction - into a single sentence, making the logic flaw not > obvious. That's possible, but... I was silently assuming horizontal-LTR paragraph direction in this bug report. Which indeed I shouldn't :-) but my example is about paragraphs which are all horizontal-LTR. > "the paragraph-mark to appear at the place where the next character would > appear" expectation must only apply to the *caret* - paragraph mark has > nothing to do with this expectation. Is that an actual design decision, or are you explaining your intuition? If it's the former, can you post a relevant link? > Paragraph mark indicates *the direction > at which the next paragraph would appear* if you decide to create one. And > the horizontal position (and correct upright glyph orientation, which is > absent now!) of the mark indicates that: your next paragraph will appear > below this paragraph, as in other "normal" horizontal paragraphs, no matter > what *character rotation* it uses. Ah, you bring up an interesting point: The _position_ of the mark vs the orientation, or rotation, of the mark. I disagree. I see the paragraph mark as a "shadow" extra character in the paragraph. I do not expect it to indicate what you suggest. > Now compare that to e.g. paragraphs in table cells, where you can set > vertical orientation by modifying table cell's text orientation on Text Flow > properties tab. That changes the position and the rotation of the paragraph > mark, correctly. But that also agrees with my intuition regarding the p-mark.
(In reply to Eyal Rozenberg from comment #8) > > Now compare that to e.g. paragraphs in table cells, where you can set > > vertical orientation by modifying table cell's text orientation on Text Flow > > properties tab. That changes the position and the rotation of the paragraph > > mark, correctly. > > But that also agrees with my intuition regarding the p-mark. Sigh. It completely does not. It shows how it honors the *paragraph* direction, not character rotation. It suggests where the next paragraph will appear. If it followed character rotation, then it would be completely unclear how the paragraph is oriented, from the look of this *formatting mark*. But I digress - I forgot that I shouldn't engage in discussions where you participate, sorry.
(In reply to Mike Kaganski from comment #9) > But I digress - I forgot that I shouldn't engage in discussions where you > participate, sorry. Ok, then I'll ignore your personal attacks and the condescending gestures like your sigh. And the personal-attack aspect of this sentence itself. > > But that also agrees with my intuition regarding the p-mark. > > It completely does not. It literally does. When you change the orientation of a table cell, the p-mark appears at the place where an extra typed character at the end of the paragraph would appear. And this is true whether you've chosen top to bottom, bottom to top, or horizontal (= no orientation change). Try it.
Created attachment 181729 [details] Screenshot MSO MSO Word has no UI function to rotate text (unless by using text boxes). But I can load a document and that works. The pilcrow follows the rotated text, vertically centered. Sounds like a good solution.
(In reply to Heiko Tietze from comment #11) > MSO Word has no UI function to rotate text (unless by using text boxes). You need to install an east Asian language, e.g. Japanese. That is in Settings (in Windows) > Time & Language > Language > Add a language. After you have installed such language the UI of MS Word has got additional settings, the symbol "Text Direction" in tab "Layout" for example.
I expect this: If I move the cursor forward as much as possible using the arrow keys, then the pilcrow sign should be directly after the cursor in the same direction as the cursor. Showing the pilcrow sign inside existing text is a bug for me.
(In reply to Heiko Tietze from comment #11) > MSO Word has no UI function to rotate text For single words the rotation is in tab "Home". The icon "Asian Layout" is left from the "Sort" icon.
(In reply to Regina Henschel from comment #12) > (In reply to Heiko Tietze from comment #11) > > > MSO Word has no UI function to rotate text (unless by using text boxes). > > You need to install an east Asian language... That seems to have no effect on macOS. And the MSO help says "To rotate text in Word, you must first place the text in a text box, and then rotate the text box." https://support.microsoft.com/en-us/office/rotate-text-in-word-66d0ea6d-a26d-40bf-8b3c-3ff8a9f60dc9#ID0EBBD=Windows When it comes to CJK I wonder if the rotation is still happening on the character level or if it's some attribute of the paragraph.
(In reply to Regina Henschel from comment #13) > I expect this: If I move the cursor forward as much as possible using the > arrow keys, then the pilcrow sign should be directly after the cursor in the > same direction as the cursor. Yes, I would say that too. IIANM, this agrees with my phrasing in comment 6. (In reply to Heiko Tietze from comment #11) > Screenshot MSO > > MSO Word has no UI function to rotate text (unless by using text boxes). But > I can load a document and that works. The pilcrow follows the rotated text, > vertically centered. Sounds like a good solution. I prefer the approach I and Regima have put forward; but I can't really fault this one. It's not bad, but not the most intuitive to me. I mean, suppose I click that pilcrow. Where will the cursor be placed? Where will a character I then type be placed?
Created attachment 181784 [details] Hard and soft paragraph break above and next to the rotated word While showing the pilcrow next where the text continues has the advantage that it shows the actual position. However, it takes some space in case of a soft break. The same happens when the pilcrow is on top with the line above. Only solution I see is to show it next to the word (right in case of LTR, otherwise left) and do not show a soft break at all (or accept it being drawn over the previous line).
We discussed this topic in the design meeting with different opinions. First, we can follow the MSO approach and show the pilcrow/downward arrow for paragraph/line breaks next to the rotated word. MSO takes the word after a line break into the next line while we show it right (or left) of it. Aligning the behavior would solve the problems raised in comment 17. The alternative idea is to rotate the break symbol and show it at the end of the current line. It potentially overlaps previous characters (either on top or left/right of it), but unlike today the text should be drawn on top of the symbol (z-oder-wise). Last but not least, due to many pros and cons the request could be resolved as WF.
Created attachment 181845 [details] Difference between LibreOffice and MSO in handling line breaks Source "Lorem \x0A ipsum \x13 dolor" rotated by 90°. Document saved as odt and loaded into MSO.
I think it's far to expect that we lay this out in a Word-compatible way.
Created attachment 181849 [details] rotated parts including line break The situation in Word is different from LibreOffice: (1) Word treats the rotated part as one character. That is, after the part is rotated you cannot move the cursor into this part to edit it. In LibreOffice you can move the cursor into a rotated part to edit it. (2) If a rotated part is the last "character" in a line in Word, the cursor will be after the part when moving the cursor forward. In LibreOffice the cursor will jump to the next line after leaving the rotated part. (3) The UI of Word does not allow any kind of line break inside a rotated part. In LibreOffice it is possible to have a 'shift+enter' inside the rotated text. In that case the rotated part still belong to the same line. If such odt-file is opened in Word, Word divides the rotated parts and generates two lines from it. The problem is that a <text:line-break> element is indeed allowed inside a <text:span> element and therefore the current treatment in LibreOffice is OK in regard to ODF. The current rendering of the pilcrow sign overlapping the rotated part is wrong in any case. My take is, that a cursor movement should place the cursor after the rotated part after leaving the rotated part and only the next moving step forward should move the cursor to the next line. Such the pilcrow sign would be always in main orientation and after the rotated part.
(In reply to Regina Henschel from comment #21) > (3) The UI of Word does not allow any kind of line break inside a rotated > part. In LibreOffice it is possible to have a 'shift+enter' inside the > rotated text. In that case the rotated part still belong to the same line. > If such odt-file is opened in Word, Word divides the rotated parts and > generates two lines from it. The problem is that a <text:line-break> element > is indeed allowed inside a <text:span> element and therefore the current > treatment in LibreOffice is OK in regard to ODF. Not so clear to me what behavior is correct. Why shouldn't a line break continue on the next line? LibreOffice treats the "whole line" as rotated - and continues right of it (in case of LTR), which is at least questionable.
Created attachment 181853 [details] Rotation in table header (In reply to Heiko Tietze from comment #22) > Not so clear to me what behavior is correct. Why shouldn't a line break > continue on the next line? LibreOffice treats the "whole line" as rotated - > and continues right of it (in case of LTR), which is at least questionable. The ODF description [1] does not mention a <text:line-break>. It has the text, "If more than one character is selected, the entire selection is rotated as a block." In my understanding this "block" includes the 'shift+enter' line break. It is useful to render it as it currently is done. This character rotation is used in table cells to rotate row or column headers. And there it would be bad to have a stack of lines in the main top-down direction instead of a horizontal arrangement of the rotated parts. If a user really wants, that the part after the line break moves into a new line, he can use a simple 'enter' instead of the 'shift+enter'. [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#property-style_text-rotation-angle
(In reply to Heiko Tietze from comment #18) > Last but not least, due to many pros and cons the request could be resolved > as WF. While one participant in our discussion said this, I pointed out that it was a mis-interpretation of the situation. That is, everyone agrees the current state of affairs is unacceptable - and worse than any of the two options. The debate regards which of them we should choose. (In reply to Miklos Vajna from comment #20) > I think it's fa[i]r to expect that we lay this out in a Word-compatible way. Actually, that's not the case, for several reasons: 1. It's impossible: Word doesn't treat soft breaks like we do, so our rendering will look different however we choose to address this issue. 2. This is a corner-case situation, both in LO and in MS word. Very few people even know how Word handles it, and I doubt that those who do are particularly happy with it. Anyway, we need an image of the two suggested solutions side-by-side on several examples (attachment 181784 [details] only shows one of them, and a third solution with no supporters). Heiko, if you can put that up, please do, otherwise I'll try to find the time for it later this week.