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:
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 18.104.22.168 ST_TextVerticalType (Vertical Text Types) in the standard ISO/IEC 29500-1:2016.
This bug report is not about the OOXML attribute 'textDirection' (in 22.214.171.124), which can be used in paragraph properties for example, and where the unicode algorithm has to be used.