OASIS JIRA report | Proposal: hint for complex content
rb.henschel at t-online.de
Fri Oct 3 03:08:06 PDT 2014
Miklos Vajna schrieb:
> Hi Regina,
> On Fri, Oct 03, 2014 at 12:02:29AM +0200, Regina Henschel <rb.henschel at t-online.de> wrote:
>> It is not about
>>> custom 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?
No, I do not know any. But I don't know, what MS does, when it converts
the own complex shapes to ODF.
The file format itself allows such complex shapes.
>> 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
When you parse the file and detect a child in <text:p> which is not one
of the simple ones, then it is "complex" and you can switch to the other
> 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.
Yes. But the element text:p is not simple. See the possible child
elements listed in 5.1.3<text:p>
For your purpose relevant is, that it can have a child <draw:frame>. And
this in turn can have all you want, see the list in 10.4.2<draw:frame>.
Especially the child <table:table> is possible.
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.
It depends on the children of <text:p> what renderer is needed. That
should be detected on parsing.
> 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.
I disagree here. An implementation should be able to analyze the XML
tree and react according to existing or not existing child elements.
> 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. :-)
ODF 1.2 already allow complex content, no need to extend it.
>> 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
> 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
As far as I know, LO only preserves the string, but does not evaluate
it. Only the draw:type attribute is evaluated to distinguish MS
custom-shapes from others and give the MS custom-shapes a special treatment.
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. :-)
See above. You need to use a <table:table> as child of a <draw:frame> as
child of the <text:p> element.
More information about the LibreOffice