OASIS JIRA report | Proposal: hint for complex content
rb.henschel at t-online.de
Mon Oct 6 07:11:12 PDT 2014
Miklos Vajna schrieb:
> Hi Regina,
> On Fri, Oct 03, 2014 at 12:08:06PM +0200, Regina Henschel <rb.henschel at t-online.de> wrote:
>> No, I do not know any. But I don't know, what MS does, when it
>> converts the own complex shapes to ODF.
> Try it yourself: if you have e.g. a triangle containing a table, then
> they simply write the content of the table (but not the table itself) to
> ODF, to produce valid ODF. That's a discussion for an other proposal,
>> 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.
> So you propose to add a fake paragraph and a fake frame to hack in a
> table into a shape content when you describe that in ODF, instead of
> simply allowing table:table inside e.g. draw:custom-shape? That sounds
> suboptimal to me. :-) But again, this is not proposed yet, so outside of
> the scope of the current discussion.
Yes. I have put my suggestion in
>> It depends on the children of <text:p> what renderer is needed. That
>> should be detected on parsing.
>> I disagree here. An implementation should be able to analyze the XML
>> tree and react according to existing or not existing child elements.
> Please be aware of that LO's xmloff uses a SAX parser, so this is not
> easily possible. This list is to discuss patches to the LO codebase, not
> to discuss theoretical problems. ;-) (Or instructing developers what
> their implementation should do.)
You are right in regard to implementation, but I will have to support
your solutions in OASIS TC as far as file format is affected. Therefore
I want to know why things are done and why it is necessary to do it that
Please apologize if I sounded presumptuous. You have implemented a great
feature. Especially getting Math-OLE inside a shape is a large
improvement and I hope you continue and implement it for Draw and
> However, now that you mentioned that an alternative way to describe a
> shape with a TextBox is to (mis-)use some existing ODF markup, instead
> of using an explicit new optional attribute, I reimplemented sw
> textboxes in xmloff in commit 9835a5823e0f559aabbc0e15ea126c82229c4bc7.
> It uses the same (somewhat ugly) trick how we detect draw vs sw shapes,
> just in this case for the content of customshapes.
I have tested the new daily build containing that changes. Testing
results in issues 84697, 84695, 84691; but I don't know, whether these
More information about the LibreOffice