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


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







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.