Description: Attached document has a text box at the middle of the page with rotated text direction. Formerly the position of the box was correct compared to Word. Now that the writing direction is imported correctly the box jumps to the very top or the very bottom of the page depending on the contained text length. Steps to Reproduce: 1. Open attached files in Word and Writer 2. Compare the text box position. 3. With long single word text the box jumps from the middle of the page to the top; with short text it jumps to the bottom. Actual Results: The text box is positioned incorrectly at the top or bottom of the page. Expected Results: The text box should be positioned at the middle of the page. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 152285 [details] Example file from Word with long text
Created attachment 152286 [details] Example file from Writer with shorter text
Created attachment 152287 [details] Screenshot of the original document with long text side by side in Word and Writer
Created attachment 152288 [details] Screenshot of the original document with short text side by side in Word and Writer
URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=ff17478e069cc82681df62514876c06365dd5cd6 author Miklos Vajna <vmiklos@collabora.com> 2019-04-25 21:05:43 +0200 committer Miklos Vajna <vmiklos@collabora.com> 2019-04-26 09:05:04 +0200 Summary: sw btlr writing mode: implement DOCX shape import for tbrl
Bibisected using bibisect-win32-6.3 Adding CC: to: Miklos Vajna
I confirm it with Version: 6.4.0.0.alpha0+ (x64) Build ID: b170256fb6ebaf774b02b89835b19d9f3a1afb89 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-07_03:30:35 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded in comparison with MS Word 2016 Additional observation: If I save document with MS Word 2016 and reopen it in LO I recieve a different result, because document was created in MS Word 2010 or 2013.
Why is this marked as regression? In which version had it worked? If Word exports a rect with vert="vert" to odt, it doesn't use a custom shape and its rotation of the text-area, but uses a draw:frame and sets style:writing-mode="tb-rl" in the paragraph-properties of the assigned graphic style. I think, that is a good idea in principle. But it would not solve the import immediately, because writing-mode on draw:frame is faulty too. Setting writing-mode to "tb-rl" can be used on custom-shape text-area too. There is no need for rotating the area. "bt-lr" would currently need loext-namespace. One problem of the given examples is the combination of "Wrap text in shape" with "Resize shape to fit text". Because of "Wrap text", only resize in direction from first text line to last text line makes sense. So the resize direction depends on the writing mode. A layout, which looks similar to Word would be: Start with the size of the text-area as in original horizontal text direction. Write the text in "tb-rl" writing mode into this area. Adapt the _width_ of the shape, if this is needed. Currently the text-area goes out of the frame rectangle of the shape. This problem becomes visible, if you set a background color to the shape. In case import should be really done rotating the text-area, then width and height of the area needs to be switched. In case the writing direction tb-rl is used, no rotation would be necessary. Currently the horizontal and vertical padding of the border is exchanged. I consider this an error, because padding belongs to the border, not to the test area. The text-area has its own size setting via draw:text-areas attribute. The current solution is not stable. Moving the shape a little bit up/down, creates two totally different layouts; both are wrong. It switches between text-area in rotated size and shape frame rectangle normal size, and second, text-area size not rotated and frame rectangle much too high. An additional problem in the given documents is, that the shape height is given as "20% to Margin". "Margin" in MS Office means "page text area" in our terms. In horizontal text direction, the hight is reduced to the height of the current text content. In vertical text direction, the hight has to be fixed 20% of the page text area, because in vertical text direction the adaption to the current text content happens in horizontal direction.
Created attachment 152347 [details] Example with absolute height of the shape and shape background filled
(In reply to Regina Henschel from comment #8) > Why is this marked as regression? In which version had it worked? > In 6.2.x the position of the box was about the same as in Word. The rotation did not happen, but at least the box was placed approximately correctly. This was our reasoning to set this as regression. We know this is still a work in progress from Miklos, that's why we post broken files (we have a lot from our users to check for regressions), to point out what is still missing. At the same time: many thanks for your detailed analysis!
Created attachment 155090 [details] Screenshot of the document in current Writer master Looks pretty good in: Version: 6.4.0.0.alpha1+ (x86) Build ID: f0340d58cc0f2808ce8003099ff2a0495360f267 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: hu-HU (hu_HU); UI-Language: en-US Calc: CL Text box is still a bit too large, but position and rotation are now fixed.
Verified in Versión: 6.3.3.1 (x86) Id. de compilación: f41f4c7f9507aeca13cb9df51f34d80e8ba30a99 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded Closing as RESOLVED WORKSFORME
Just for the record, this issue might has been fixed by the combination of https://git.libreoffice.org/core/commit/9c81d0a268cca4ff36eff94c0842361b9c0287ef and https://git.libreoffice.org/core/commit/ff17478e069cc82681df62514876c06365dd5cd6