Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of dennis.hamilton@acm.org
 designates 216.119.133.2 as permitted sender)
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: <ooo-dev@incubator.apache.org>,
	"'LO-dev'" <libreoffice@lists.freedesktop.org>
References: <5023BE00.1070708@t-online.de>
 <CAFYHVnV9+7qv1E8GMaV_K19Rd+Tsm7RZkPpkuBF2x8YSpyQrUg@mail.gmail.com>
 <002b01cd77de$4818ead0$d84ac070$@acm.org> <50269758.3090901@t-online.de>
In-Reply-To: <50269758.3090901@t-online.de>
Subject: RE: ODF angle in draw:transform are in degrees
Date: Sat, 11 Aug 2012 10:41:24 -0700
Organization: NuovoDoc
Message-ID: <003201cd77e8$87b70910$97251b30$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHdR+YpP/bqGBwqsX2gAyA4R9yzswIEG+s4AfC2RqQBdgzN0ZcJ6QlA
Content-Language: en-us

@Regina,

Thanks.  I agree that the transform case needs to be taken up also.  My =
sense is that there is agreement that there should be transposition to =
SVG with attention to migration and down-level compatibility issues.

I also agree that the situation with existing ODF 1.0/../1.2 documents =
and implementations must be clarified, where practical, with advisories =
and errata.

 - Dennis

-----Original Message-----
From: Regina Henschel [mailto:rb.henschel@t-online.de]=20
Sent: Saturday, August 11, 2012 10:33
To: ooo-dev@incubator.apache.org; LO-dev
Subject: Re: ODF angle in draw:transform are in degrees

Hi Dennis,

[ ... ]

That is the problem with the unit of angles for gradients. But this here =

is different. It is about transformations. The matrix has no problems,=20
because the relevant matrix elements are used as unitless factor. But=20
rotate, skewX and skewY have angles as parameter.

>
> The next step is to come up with a new attribute (or attributes) that
> correspond to SVG provisions and are rigorously defined.  The new
> attribute(s) would appear down-level (i.e., in ODF
> 1.0/1.1/IS26300/1.2) as extensions and be ignored but be official in
> ODF 1.3 (which would deprecate but not remove draw:angle).
>
> If the SVG-aligned attributes are present (and to be required in ODF
> 1.3 documents, let's say) and recognized, they would over-rule
> draw:angle.  ODF 1.3 Producers that wanted to ensure down-level
> interoperability would produce both attributes.
>
> How does that sound?

It would be great to have an attribute svg:transform. That would be the=20
best solution for me and will prevent further trouble.

Nevertheless the problem remains, that
   ODF1.1 has no unit at all and documents written by StarOffice use=20
unit rad,
   and ODF1.2 specifies degree, but at least Apache OpenOffice,=20
LibreOffice and Powerpoint 2013 use rad.

I don't know, whether Gnumeric uses <draw:transform>. I have seen in the =

meantime that Genumeric uses the attribute <draw:angle> in fillings in=20
charts and unfortunately (from Apache OpenOffice point of view) Gnumeric =

uses it in deg there and not 0.1deg.

So there are some rules or hints needed, how to tread documents which=20
are ODF1.1 or ODF1.2.

Kind regards
Regina


[ ... ]