OASIS JIRA report | Proposal: hint for complex content

[Regina Henschel]

Hi Miklos,

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
> populate.

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 
model.

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

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.

Kind regards
Regina