Created attachment 180491 [details]
The docx example in Word 2016 and Writer

Created attachment 180493 [details]
Rotated Grouped Shape

Hello Gabor!

This one probably the grouped version of https://bugs.documentfoundation.org/show_bug.cgi?id=82627
So not understood what is to point of this one.. That commit only changed the target of the read in this case to a text-frame which is still not rotatable.
Rather feature request than regression see my attachment, which never was good, unfortunately :( What do you think what can be the solution for this problem without having the feature? Any idea?

Created attachment 180494 [details]
Sample file before and after that commit

Created attachment 180501 [details]
Shape with simple text

My take is, that the import filter needs to be so changed, that in case the text is so simple that it can be expressed as label text, then no attached text frame is used.

With "label text" I mean the handling of text in custom shapes as it is done in Draw, Impress and Calc.

The attached document shows such example.

In the long run the Draw text rendering engine should be able to handle tables and objects anchored as characters too. Then the scope of "simple" can be expanded.

Attila, Regina

Thanks for the insight, let's just add this to the "rotated text box from docx issues" pile.

Gabor, Regina,

I have tried to investigate how the rotation can be developed. I think two way can be mentioned, in the first case the rotation only will be applied when the frame is rendered, so it will be seen rotated. I think this one the easier way, but not the better, it is quite hackish... The other way to implement it in the layout in the level of the frames. But i am afraid, now the rotation only happens in the drawing level (svx) not in the writer. In this case all of the frame types have to be known and -- if i remember well -- from the swlayutframe it have to be implemented for frames, texts, tables, etc.
Other interesting thing, when in word the textbox is under editing, the rotation is disabled, after the editing finished it rotates the content. That looks like the first case.
So it have to be properly investigated, planned, designed and it will take many time to do it, not to mention how many mistake can be made. This is a so complex situation, i think, and it needs a far more experienced developer than me. Hopefully one day i can try it, but not now i afraid. :)

@Regina: Thank you for your idea. Unfortunately i do not know how to realize that, because the filter reads the xml sequentially, line by line. In the case, when the complex content is at the end of the textbox and we read it into the shape (as editeng text), it will be lost and there is no possibility to  turn back, because the read is done line by line. So the filter have to decide where the content have to be read, before the content is known. There might be a solution, but i have no idea about it for now.

Sorry for the novel, as always i have written a it a bit long... :)

(In reply to Attila Bakos (NISZ) from comment #6)
> @Regina: Thank you for your idea. Unfortunately i do not know how to realize
> that, because the filter reads the xml sequentially, line by line. In the
> case, when the complex content is at the end of the textbox and we read it
> into the shape (as editeng text), it will be lost and there is no
> possibility to  turn back, because the read is done line by line. So the
> filter have to decide where the content have to be read, before the content
> is known. There might be a solution, but i have no idea about it for now.

I think it can be done in WpsContext::onEndElement(). The challenge is, that the simple solution
OUString sFrameContent(xText->getString());
pCustomShape->NbcSetText(sFrameContent);
xShapePropertySet->setPropertyValue("TextBox", uno::Any(false));
as done for Fontwork will not work in this case, because it looses character formattings.