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.hensc...@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
