Re: Problems in Writer with rotated text in shapes

[Miklos Vajna <vmiklos@xxxxxxxxxxxxx>]

Hi Regina,

On Thu, Jul 07, 2022 at 01:00:03AM +0200, Regina Henschel <rb.henschel@xxxxxxxxxxx> 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.

> (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.

> (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. 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. :-)

Regards,

Miklos