Re: OASIS JIRA report | Proposal: hint for complex content

Hi Miklos,

Miklos Vajna schrieb:
> Hi Regina,
>
> On Fri, Oct 03, 2014 at 12:08:06PM +0200, Regina Henschel <rb.henschel@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,
> though.
>
> > 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 
https://bugs.freedesktop.org/show_bug.cgi?id=84714

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

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

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

Kind regards
Regina