Hi Regina, On Fri, Oct 03, 2014 at 12:02:29AM +0200, Regina Henschel <rb.henschel@t-online.de> wrote:
It is not aboutcustom shapes, with this we can attach a textframe to drawinglayer shapes, so we can have tables, redlining, etc. in shapes.That is the implementation side. In ODF1.2 file format, shapes have child <text:p> which has child <draw:frame>, which has child <draw:text-box> or <table:table> a.o. So "complex" text is possible without anything in addition.
You mean you're aware of any other ODF implementation that already supports shapes with complex content, like the "rectangle with rounded corners, containing a table" example?
Till now it is not obvious to me, why this information needs to be in the file format. Couldn't it be detected when parsing on opening?
Regarding the implementation: the proposed "complex" shapes use the SwNodes array to store the document model and the sw layout to render the content, while non-complex shapes are rendered by editeng. Both have features which are missing from the other engine. *Before* the text of the shape is read, we want to know which type of document model to populate. Regarding ODF: at the moment ODF requires that the shape text be simple -- the draw-text define in the .rng schema says that only text-p and text-list is allowed. This means that an ODF implementation can use a much simpler engine for shape text rendering, compared to what is required to render the normal text content of a .odt file. The text-content define describes all these additional features, table-table is one such example. If we would propose to allow table-table in shape text without an extra attribute, then implementers could be worried about adding too much features to the shape text engine, which would slow down the handling of simple content, which would be only draw-text. So the idea is to add a new boolean attribute, and only use complex content in that case -- so at import time implementations can decide what engine to use for handling the content.
And would LibreOffice not show the <text:p> element of the shape, when it is "complex" but not marked as such? You cannot expect that another producer will write such attribute, because "complex" shape text is already possible yet, without having such attribute.
The new boolean attribute is completely optional. If it's missing, then LO will use editeng to handle the shape text, just like before. If the new attribute is present and it's true, then LO Writer will use SwNodes to handle the content of the shape, which allows features like having a table in a shape text.
No, I do not know, whether any application writes the attribute draw:engine. I would expect it for MS Office 365 or MS Office 2013, but I haven't got one to test it.
I created a shape containing a table in Word 2013 and saved it as .odt.
The 2x2 table is written as:
<text:p text:style-name="P2">A1</text:p>
<text:p text:style-name="P3">B1</text:p>
<text:p text:style-name="P4">A2</text:p>
<text:p text:style-name="P5">B2</text:p>
I.e. the complex content (the table) is lost during export. I can
understand this, they didn't want to spend time on extending ODF to
their needs, and this is probably the best you can do with ODF 1.2.
Sounds like one more argument showing that we need to do some extending
to allow this. :-)
But from its description, "The draw:engine attribute specifies the name of a specific rendering engine that can be used to render a custom shape." it would do exactly what you want - only, that it is currently only usable for custom-shapes.
If you grep for ENGINE in xmloff, then you'll see that draw:engine is already used by LO, to persist the CustomShapeEngine UNO property of the shape. I did not check in detail, but I expect that this is more about how the attributes and child nodes of <draw:enhanced-geometry> get handled. I guess that's why Andras asked if you are aware of any existing document using this attribute, that would help.
And are you really going to implement the new engine for arbitrary shapes?
Not "going to", this is all already implemented in master, see the draft <https://wiki.documentfoundation.org/ReleaseNotes/4.4#Shapes_can_have_a_TextBox>. ;-)
BTW, the example http://cgit.freedesktop.org/libreoffice/core/tree/sw/qa/extras/odfexport/data/textbox-rounded-corners.odt from the blog post is not valid, because <table:table> is not allowed as child of <draw:custom-shape>.
Indeed. I guess I'll just make the sw ODF filter write <loext:table> inside shapes for now, then we'll need a next ODF proposal to allow <table:table> inside shape text (possibly saying "an ODF reader can expect that this child element only appears when style:complex-content is true"). In any case, any constructive input is welcome on how to better represent the "shape with a TextBox" feature in ODF. Till 4.4 is released, we can still modify that without worrying about backwards compatibility. :-) Thanks, Miklos
Attachment:
signature.asc
Description: Digital signature