> On June 10, 2013, 5:52 p.m., C. Boemann wrote:
> > I still don't see the relation to the bug nor do I understand why we need
> > to save 0,0
>
> Inge Wallin wrote:
> Ah, now I understand why everybody focusses on the bug. I was unclear in
> my description. "This bug" in the description is about the bug I described,
> not the bug in bugzilla. I was just mentioning the bug in bugzilla because
> it provided me with a file where I noticed the problem first time.
>
> Regarding why we need to save 0,0... Can you point me to the place in
> the spec where it says that 0,0 is the default value? If not, there's your
> answer.
>
> Elvis Stansvik wrote:
> In 19.573.5 the spec refers to 5.2.1 of the SVG spec which says 0,0 is
> the default [1]. Not 100% sure this is what we're talking about here, so
> someone please fill me in if I'm wrong :)
>
> [1] http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#SVGElement
>
> Inge Wallin wrote:
> No, this is the svg element. We are talking about svg:x and svg:y
> attributes. But there is probably a relation.
>
> Elvis Stansvik wrote:
> Right, but that's the section of the SVG spec the ODF spec references in
> 19.573.5 [1], and it includes the definition of the x and y attributes (see
> under "Attribute definitions"). So the way I read it is that x/y should be
> treated the same as for the svg element in the SVG spec. But I may be wrong.
>
> [1]
> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1418216_253892949
>
> Sebastian Sauer wrote:
> Yes, that's correct. Grep for "svg-compatible" in
> http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part1.html which
> gives a nice table explaining that ODF uses the svg prefix for "Elements and
> attributes that are compatible to elements or attributes defined in [SVG]."
> including link to the SVG specs.
>
> For a longer explanation of the background see
> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/SVG_in_ODF
>
> re optional see also
> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-schema.rng
>
> <define name="common-draw-position-attlist">
> <optional>
> <attribute name="svg:x">
> <ref name="coordinate"/>
> </attribute>
> </optional>
> <optional>
> <attribute name="svg:y">
> <ref name="coordinate"/>
> </attribute>
> </optional>
> </define>
>
>
> Inge Wallin wrote:
> Ok, that does it. I'm convinced. :)
> Still, I think that it would be nice to always save x and y so that also
> non-well behaved applications could read the files. Opinions? If there are
> only negative reactions to this I will retract the RR.
>
> C. Boemann wrote:
> I don't have negative reaction to your suggestion to always save. I mean
> normally we don't save that many shapes at 0,0 anyway so it's unlikely to be
> a big change in practice.
hmmm, hmmm... I see multiple problems with that.
1. I think there is a good reasons that we NOT save default values (not talking
here about scg:x/y only but in general default values). That is that we
*greatly* (and I mean by factors) reduce the ODF produced what makes it factors
faster to investigate, manipulate (hand-edit to check for behavior), save those
XML files.
2. Afaik neither Apache OpenOffice nor LibreOffice nor Microsoft Office do that
or?
3. This would then apply to all default values, right? If yes, 1) applies (lots
of noise) plus I fear about the consequences of 2).
4. This:
> that also non-well behaved applications could read the files
What "non-well behaved applications" we are talking about?
In an ideal world we would never work around broken apps. Unfortunately that's
unrealistic and so we do lots of workarounds during loading ODF. But we do so
by clearly documenting that (KoOdfWorkaround). Now if we try to do the same for
saving it becomes imho an even bigger problems cause:
a) We cannot really target the "consumer" since there is no "if consumer_is_aoo
{} else if consumer_is_mso {}" logic. We could probably use app=specific
namespaces for that. But that may break on newer versions of the specific app
and app-namespaces not contain version-informations.
b) What about conflicts? Like a workaround fixes broken app x but breaks broken
app y?
5. When we do this we need to cross-check at least AAO, LO and MSO that they
still proper load our ODF's.
6. And the most important question (for me) is: What is that what we try to fix
here?
- Sebastian
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110928/#review34071
-----------------------------------------------------------
On June 10, 2013, 7:18 p.m., Inge Wallin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110928/
> -----------------------------------------------------------
>
> (Updated June 10, 2013, 7:18 p.m.)
>
>
> Review request for Calligra.
>
>
> Description
> -------
>
> When a shape is in the position 0, 0 and there are no other transformations,
> the position will not be saved back. In other words, there will be an
> svg:height and svg:width but no svg:x or svg:y. I noticed this while trying
> to fix https://bugs.kde.org/show_bug.cgi?id=184727.
>
> This patch fixes that the code doesn't save the position. I suggest that we
> apply it to 2.7 as well and maybe also to 2.6.
>
>
> Diffs
> -----
>
> libs/flake/KoShape.cpp 6d14a8c
>
> Diff: http://git.reviewboard.kde.org/r/110928/diff/
>
>
> Testing
> -------
>
> Tested with the file mentioned above.
>
>
> Thanks,
>
> Inge Wallin
>
>
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
