OASIS JIRA report | Proposal: hint for complex content

[Miklos Vajna]

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?

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20141003/19233a31/attachment.sig>