OASIS JIRA report | Proposal: hint for complex content

Regina Henschel rb.henschel at t-online.de
Thu Oct 2 15:02:29 PDT 2014


Hi Andras,

Andras Timar schrieb:
> Hi Regina,
>
> On Thu, Oct 2, 2014 at 8:30 PM, Regina Henschel <rb.henschel at t-online.de> wrote:
>> Hi all,
>>
>> the list in
>> https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes
>>
>> has a row for the JIRA report
>> https://issues.oasis-open.org/browse/OFFICE-3864
>>
>> The text is (currently last line in section 4)
>> 9d310ecfce3c2fc481b125e1493a534e2107a68e
>> Extend style:graphic-properties with attribute loext:text-box
>> Complex content (redlines, fields, tables, etc.) in Writer shapes.
>> OASIS JIRA report Proposal: hint for complex content
>>
>> I could not find information about loext:text-box and I do not understand
>> "Writer shapes".
>>
>> I thought shapes of MS documents will go into a custom-shape on import. And
>> these have already an attribute "draw:engine" and "draw:data", which is
>> intended to support using of different rendering engines. Why do you think,
>> a new attribute is needed?
>
> Have you read http://vmiklos.hu/blog/textbox.html ?

No, I didn't know it. It will help me to understand the problem, but I 
will need some time to reed.

  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.

  It is true,
> that it helps in MS Office interop, because Word already had this
> feature.

  The suggested boolean attribute helps Writer to decide,
> whether the shape text should be rendered with editengine,  or with
> Writer. We could use a namespace string instead of this boolean, e.g.
> LO/editeng and LO/sw, it would be the same.
  AFAIK draw:engine is not
> related to this problem.

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?

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.

  Do you have, by chance, an ODF document where
> draw:engine is used?

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

And are you really going to implement the new engine for arbitrary shapes?

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

Kind regards
Regina







More information about the LibreOffice mailing list