Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


Hi Regina,

On Fri, Oct 03, 2014 at 12:02:29AM +0200, Regina Henschel <rb.henschel@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

Attachment: signature.asc
Description: Digital signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.