Created attachment 154015 [details] VertByAreaRotation.docx demonstrates the error. Open attached document. It contains an arrow shape on the left side and screenshot of how it looks in Word365 on the right side. Save the document to odt-format and open that new document. Error: Not only the text is rotated, but the entire text area. ODF does not have an attribute similar to attribute "vert" of OOXML. So it is not wrong principally to rotate the text area as ersatz for it. But then the position and size of the text area has to be adapted, so it is the same relative to the arrow as before.
@Miklos, i thought you might be interested in this issue, since it's related to btlr writing
It has the same root cause as bug 127785. The import writes a 90° rotation to TextPreRotateAngle. This leads to matrix order scale-matrix after rotation-matrix in createViewIndependentPrimitive2DSequence(). The scale factors are calculated as length of column vector in decompose(). In case of 90° or -90° the wrong matrix order leads to an exchange of x-scaling factor and y-scaling factor in decompose(). So the wrong matrix order produces an implicit exchange of width and height of the text box in rendering the docx file. So this implicit exchange produces the same result as an explicit exchange, which I would expect. But when the file is then saved as odt, the TextPreRotateAngle is saved as draw:text-rotate-angle attribute, same as a TextRotateAngle would be. When the odt-file is opened, then the angle goes to TextRotateAngle. And for this, the matrix-order is rotation-matrix after scale-matrix. Thus decompose() produces correct width and height and so you see the rotated text box. *** This bug has been marked as a duplicate of bug 127785 ***
Ups, wrong bug number. Duplicate to 127437. That is the bug, that a rotation angle for the text box in pptx leads to shearing of the text box in LibreOffice. *** This bug has been marked as a duplicate of bug 127437 ***