Created attachment 155098 [details] CJKcharacters_in_bt-lr.odt has a ordinary frame and one with bt-lr writing-mode Open attached file. It has two frames, one with default lr-tb writing-mode and a copy of it with bt-lr writing-mode. The CJK characters have wrong orientation in bt-lr writing mode. Because bt-lr is no writing-mode for an existing language but is used for 90° counter-clockwise rotation, the CJK characters should have the same orientation as the latin characters. This is needed too, if you want to use bt-lr writing-mode to emulate the vert="vert270" text rotation on import of docx documents. Such is currently needed, because the text area of a shape cannot rotate if it is in frame text mode (Text Box is attached), and that is currently always the case for shape import from docx.
Created attachment 155305 [details] btrl in Table.odt contains CJK characters in ordinary table The problem is not only in frames but in tables too. Open attached document and save it to docx. Open the saved document in Word. A screenshot will follow.
Created attachment 155306 [details] Screenshot with comparison of LibreOffice and Word of bt-lr in table cell Look at the CJK characters in the cells and compare them with the horizontal line. In LibreOffice CJK characters are rotated 180°, in Word they are rotated 270° clockwise, same as the latin characters. It should be the same as in Word, so that this writing mode can be uses for import/export with OOXML vertical direction property vert="vert270".
Thanks for the sample, I confirm this is a bug.
Wait, don't the CJK glyphs have 'vert' table assignments and bidi hinting as to orientation of the glyphs in the frame? We end up with a vertical run each glyph of which has been rotated--not a rotated horizontal run.
Was looking for better details, and not surprised if we don't handle vertical text runs correctly in Draw text boxes, but his gem from the Unicode folks was pretty informative as to how to think of this and what we may need to implement: https://unicode.org/notes/tn22/RobustVerticalLayout.pdf and, not clear that Microsoft actually defines this correctly (for Vertical or Horizontal text runs) in OOXML.
(In reply to V Stuart Foote from comment #5) > and, not clear that Microsoft actually defines this correctly (for Vertical > or Horizontal text runs) in OOXML. I think, they do it correctly. OOXML has the script depending vertical modes vert="eaVert" (e.g. Japanese) and vert="mongolianVert". Latin characters are 90° rotated, whereas CJK characters stay upright. The difference is, that next lines go from right to left in "eaVert" and from left to right in "mongolianVert". And OOXML has the script independent, pure geometrical vertical modes vert="vert" and vert="vert270". They rotate _all_ characters 90°, clockwise or counter clockwise respectively. The attribute 'vert' belongs to element 'bodyPr' which is a child element of shapes. The description is in 20.1.10.83 ST_TextVerticalType (Vertical Text Types) in the standard ISO/IEC 29500-1:2016. This bug report is not about the OOXML attribute 'textDirection' (in 17.3.1.41), which can be used in paragraph properties for example, and where the unicode algorithm has to be used.
Dear Regina Henschel, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
It is OK in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 542a38de1a071f54f61806683dafea84e43edce9 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL Likely fixed by the fix for bug 131490. https://cgit.freedesktop.org/libreoffice/core/commit/?id=a8d26a0bb40c101394ded8061d1b58048153631b