-
Michael Stahl yazdı
The problem is that we don't render ShapesWithWrapping.odt the same as Word does: https://beta.opendocumentformat.org/rendercompare/upload/223/86/191/1 The first shape in the file is anchored "as-char" and has no style:vertical-rel or style:vertical-pos attribute affecting it. If Word would write either style:vertical-rel="baseline" or style:vertical-pos="top" explicitly, the rendering in LO would be the same. So the problem is that, for drawing shapes (note, text frames are images, embedded objects handled differently), LO's default vertical alignment is different, it is hard-coded in SwShapeDescriptor_Impl::GetVOrient() as SwFormatVertOrient(0, text::VertOrientation::NONE, text::RelOrientation::FRAME) This effectively positions as-char shapes *below* the baseline, which, while technically allowed, isn't really a good default. So fix this by making the default alignment dependent on the anchor type, so that as-char shapes sit on top of the baseline. The ODF filter sets the anchor type before inserting the shape in XMLTextShapeImportHelper::addShape(), however as it turns out the various MSO filters insert the shape before setting the anchor, which means the new default in SwXShape has an unwanted effect on them, as inserting the shape causes the default to be created. This requires changes to VML import to always set the VertOrient property, and to RTF import to set the anchor type before inserting. The DrawingML import is unaffected as it already sets VertOrient for every non-as-char shape. The testDmlTextshape "dml-textshape.docx" test still fails, but it turns out that the change in alignment for this test document is a bugfix, as it now has the same vertical alignment as in Word, so adapt the test. Change-Id: Ifcabd96a037515f7803f5474ec995f968b3b4de1
c79467ba