Hi, On Wed, Dec 18, 2013 at 08:24:46AM +0000, Abdulaziz Ayed Khalid Alayed <aalayed@kacst.edu.sa> wrote:
thanks for responding its allready opend https://bugs.freedesktop.org/show_bug.cgi?id=70942 I was have a code pointer and i was trying to solve it now after my last [ git pull ] i try again with the same code pointer and it does not work . I use a debuger before last [ git pull ] in the same code pointer and the debuger catch the break point [textbox tag] , but now the debuger can't catch the same break point. so, I think some one make (small) mistake :) with the pushing of DOCX properties (I mean it doesn't push the text box tag within shape) .
This is a known issue, with no easy solution. The problem is that in Word, a shape can contain any text, while in Writer, there is a difference between a Writer textframe and a drawinglayer shape. Writer textframes can e.g. contain tables (drawinglayer shape text is editengine, that doesn't support this), OTOH drawinglayer rectangles can have rounded corners (Writer textframes don't support this) -- and there are other similar differences. The original VML import code simply imported every shape that has some text as a textframe, to make sure no data (like tables, OLE objects, etc) is lost during import; only formatting (like shape type). Up to 4.2, the Fallback branch of the mc:AlternateContent element is read. On master, the Choice branch is read if the required feature is wps, though the behavior is the same: if the shape has text, it's imported as a textframe (unless it's part of a groupshape). A long-term fix would be to implement missing features in editengine, so there won't be need to import any kind of shape as a Writer textframe, though that will take a huge amount of time to achieve. A shorter-term fix for this would be to "look ahead" in the importer, check if the shape text has any feature that requires a writer textframe (like a table), and if not, then go ahead with the requested shape instead. Unfortunately ATM we parse the DOCX XML with a SAX parser that doesn't allow such "look ahead". (A similar problem: if the shape is inside a group shape and the shape text contains tables, it's better to import it as a textframe and not to add it to the groupshape; but in general importing it as a drawinglayer rectangle and adding to the groupshape is preferred. The RTF import supports "look ahead" and decides what to do, based on if the shape text contains tables or not.) HTH, Miklos
Attachment:
signature.asc
Description: Digital signature