Problems in Writer with rotated text in shapes

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 14.07.2022 um 16:38:
> Hi Regina,
> 
> On Thu, Jul 07, 2022 at 01:00:03AM +0200, Regina Henschel <rb.henschel at t-online.de> wrote:
>> (1)
>> I have turned off creating a textbox associated with the shape for some
>> cases, so I can see what happens on import. (Text rotations are still
>> missing here as a reason not to use a textbox).
>> -            else if (mbTextBox)
>> +            else if (mbTextBox && getRotation() == 0 && !mbFlipV)
>>               {
>>                   aShapeProps.setProperty(PROP_TextBox, true);
>>               }
>>
>> Apart from the fact that the shape-text cannot contain images, math objects
>> or bullets, does this cause any other problems?
> 
> This affects any kind of complex content: Writer fields, tables,
> comments, change tracking and so on. If you disable Writer TextBoxes for rotated text,
> it may happen that somebody will see it as a regression that their
> complex content is now gone. So this is somewhat controversial.
> 
> The ideal would be to have a way to rotate the Writer text, but we don't
> have that today.

I agree and have set it back. Nevertheless it makes sense to use it 
locally to see, whether my changes are correct in case there are no text 
boxes.

> 
>> (2)
>> The textbox created automatically on import of a shape causes significant
>> problems when the text in the shape needs to be rotated for some reason.
>> Could the creation of the textbox be limited to cases where the capabilities
>> of a frame are actually needed?
> 
> This is tricky to implement, you would need to "look ahead" when
> importing the content, I think.

Indeed, the needed information is not available at that point.

Independent from my current work, we could perhaps add an compatibility 
option to section Load/Save to let the user decide, whether he wants the 
text box in all cases.

> 
>> (3)
>> The XML_bodyPr element is handled directly in WpsContext.cxx. Why is
>> TextBodyPropertiesContext not used? Evaluating the attributes is quite
>> complex if done correctly, see e.g.:
>> TextBodyProperties::pushTextDistances(). It would be nice not to have to
>> repeat all this within WpsContext.
> 
> WpsContext is the glue layer between the DOCX import (writerfilter/) and
> the rest of the drawingML import (oox/source/drawingml/). We already try
> to import the shape using shared code and only read the actual complex
> content in writerfilter/. If you see an opportunity to share more code
> between oox/source/shape/ (glue layer) and the rest of the drawingML
> import, that's great.

I have replaced the directly evaluation with TextBodyPropertiesContext 
and found no problems so far. But perhaps you look into that area, when 
my work is no longer in WIP state.

  But importing the whole WPS shape in oox/ is not
> going to work once you start running into complex content, you really
> need the writerfilter/ code for that.
> 
> I hope that helps a bit. :-)

It is always helpful to talk about problems. I appreciate you taking the 
time to do this.

Kind regards,
Regina