PDF::Writer Angle Issues

ruby-talk
1

Well, things have just gotten ... interesting. In response to a
user's request, I'm looking at possibly doing SVG-to-PDF vector
transformations with PDF::Writer. In looking over the existing code,
I realised that there's some bugs in the axis transformation code
related to how rotation and skewing is done. The skewing is
completely wrong. The rotation is also completely wrong, but it's a
much more subtle issue.

See, I have the transformation *backwards* in the text rotation.
Without going into much detail as to *why*, rotation code is
supposed to be on a vector of:

  [ cos(a) sin(a) -sin(a) cos(a) 0 0 ]

The *text* rotation code, on the other hand, is:

  [ cos(a) -sin(a) sin(a) cos(a) 0 0 ]

This inversion *reverses* the direction of the angle.

Consider an analog clock. In both systems, zero degrees is at the
three o'clock position. Under the current text rotation, 90 degrees
is at the six o'clock position (headed DOWN the page); under the
common transformation, it is at the 12 o'clock position (headed UP
the page).

PDF::Writer 1.0 has been released with this behaviour. Changing it
will be very simple ... but it will break anyone's code that uses
angles. At the same time, if I use the broken transformation, then I
have to work harder at things like SVG or RVG transformations. I'm
definitely between a rock and a hard place here. The longer I wait
to fix this, the more people that will be affected by it.

I want the text angle and the graphics axis angle to mean the same
thing (either clockwise or counter-clockwise).

I'm looking for advice, people. I'm tempted to release 1.1 with this
fix; it's incompatible behaviour but compatible API, and the only
change necessary to your code would be to *negate* the angle.

-austin

···

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

2

[snip]

I'm looking for advice, people. I'm tempted to release 1.1 with this
fix; it's incompatible behaviour but compatible API, and the only
change necessary to your code would be to *negate* the angle.

-austin

Hello Austin,

  For what it's worth, I prefer a point release with an incompatible
change (but compatible API) than a major release some time down the
road with an incompatible change (and enough people having complained
about it that the new API is incompatible).

  Just my CAD0,02 worth.

    Cheers,

      kjw

···

On 14/06/05, Austin Ziegler <halostatue@gmail.com> wrote:

--
http://www.kjwcode.com/

3

i've been releasing all my code like

   lib.rb -> is a link to lib-1.3.4.rb

   lib-1.3.4.rb -> requires a bunch stuff from the __directory__ lib-1.3.4/*

therefore a

   require 'lib'

always gets the most recent lib while a

   require 'lib-1.3.4'

will pin an application to a specific version

with this approach you can release a new version that supports multiple
installs and completely eliminate issues like this...

that's one answer.

the other is - make it right! PDF::Writer is some great stuff and the
better/more-correct it is the more widespread it will become.

2cts.

cheers.

-a

···

On Wed, 15 Jun 2005, Austin Ziegler wrote:

Well, things have just gotten ... interesting. In response to a user's
request, I'm looking at possibly doing SVG-to-PDF vector transformations
with PDF::Writer. In looking over the existing code, I realised that there's
some bugs in the axis transformation code related to how rotation and
skewing is done. The skewing is completely wrong. The rotation is also
completely wrong, but it's a much more subtle issue.

See, I have the transformation *backwards* in the text rotation. Without
going into much detail as to *why*, rotation code is supposed to be on a
vector of:

[ cos(a) sin(a) -sin(a) cos(a) 0 0 ]

The *text* rotation code, on the other hand, is:

[ cos(a) -sin(a) sin(a) cos(a) 0 0 ]

This inversion *reverses* the direction of the angle.

Consider an analog clock. In both systems, zero degrees is at the three
o'clock position. Under the current text rotation, 90 degrees is at the six
o'clock position (headed DOWN the page); under the common transformation, it
is at the 12 o'clock position (headed UP the page).

PDF::Writer 1.0 has been released with this behaviour. Changing it will be
very simple ... but it will break anyone's code that uses angles. At the
same time, if I use the broken transformation, then I have to work harder at
things like SVG or RVG transformations. I'm definitely between a rock and a
hard place here. The longer I wait to fix this, the more people that will be
affected by it.

I want the text angle and the graphics axis angle to mean the same thing
(either clockwise or counter-clockwise).

I'm looking for advice, people. I'm tempted to release 1.1 with this fix;
it's incompatible behaviour but compatible API, and the only change
necessary to your code would be to *negate* the angle.

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
My religion is very simple. My religion is kindness.
--Tenzin Gyatso

===============================================================================

4

Austin Ziegler wrote:

angles. At the same time, if I use the broken transformation, then I
have to work harder at things like SVG or RVG transformations. I'm

"RVG" transformations?

I'm looking for advice, people. I'm tempted to release 1.1 with this
fix; it's incompatible behaviour but compatible API, and the only
change necessary to your code would be to *negate* the angle.

Go with your temptation. Shipping the fix now will cause the least amount of trouble.

5

* Austin Ziegler <halostatue@gmail.com> [2005-06-15 10:41:33 +0900]:

I'm looking for advice, people. I'm tempted to release 1.1 with this
fix; it's incompatible behaviour but compatible API, and the only
change necessary to your code would be to *negate* the angle.

Make the change now Austin. No, better yet, make the change yesterday.

···

--
Jim Freeze

6

[snippage]

i've been releasing all my code like

lib.rb -> is a link to lib-1.3.4.rb

lib-1.3.4.rb -> requires a bunch stuff from the __directory__
  lib-1.3.4/*

therefore a

require 'lib'

always gets the most recent lib while a

require 'lib-1.3.4'

will pin an application to a specific version

That's an interesting solution to the same thing that RubyGems
solves. Unfortunately, it's not a great situation for non-Unix
platforms, and it's not an approach that appears to be supported by
the stock setup.rb, which I've recently converted my applications
and libraries to.

the other is - make it right! PDF::Writer is some great stuff and the
better/more-correct it is the more widespread it will become.

I have made the changes. It will be out by early next week whether
or not I have the SVG transformation code completed.

-austin

···

On 6/14/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

7

Austin Ziegler wrote:
> angles. At the same time, if I use the broken transformation, then I
> have to work harder at things like SVG or RVG transformations. I'm
"RVG" transformations?

Why not? RVG works against a canvas. If I provide people a way to
insert a PDF document into that canvas and it Does The Right Thing,
then RVG and PDF::Writer graphics could be done with the same code. I
suspect that it will be harder than I want, but that's something that
could be worked out. It's also not a high priority :wink:

> I'm looking for advice, people. I'm tempted to release 1.1 with this
> fix; it's incompatible behaviour but compatible API, and the only
> change necessary to your code would be to *negate* the angle.
Go with your temptation. Shipping the fix now will cause the least
amount of trouble.

Will be done.

-austin

···

On 6/15/05, Timothy Hunter <cyclists@nc.rr.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

8

That's an interesting solution to the same thing that RubyGems solves.

but without the 'require_gem' bit :wink:

Unfortunately, it's not a great situation for non-Unix platforms,

why not? my arrayfields module uses a similar approach and it install in
windows fine so far as i know. remember - the link would exit only in your
development director - once you tar it up and the user installs it the
mylib.rb and mylib-0.0.0.rb simply become a copy but each time the user
installs a new verion the mylib.rb gets clobbered leaving the versioned one
behind to be used.

make sense?

and it's not an approach that appears to be supported by the stock setup.rb,
which I've recently converted my applications and libraries to.

i've used it with setup.rb, basically you have

   lib/mylib.rb -> mylib-0.0.0.rb

   lib/mylib-0.0.0.rb

   lib/mylib-0.0.0/a.rb
   lib/mylib-0.0.0/b.rb

and

   mylib-0.0.0.rb

does a

   require 'mylib-0.0.0/a.rb'
   require 'mylib-0.0.0/b.rb'

   etc.

i have some boilerplate scripts/code generators that spew all this stuff out,
including all the relative path bits, if you are interested.

I have made the changes. It will be out by early next week whether
or not I have the SVG transformation code completed.

great!

-a

···

On Wed, 15 Jun 2005, Austin Ziegler wrote:
--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
My religion is very simple. My religion is kindness.
--Tenzin Gyatso

===============================================================================

9

> That's an interesting solution to the same thing that RubyGems solves.
but without the 'require_gem' bit :wink:

> Unfortunately, it's not a great situation for non-Unix platforms,
why not? my arrayfields module uses a similar approach and it install in
windows fine so far as i know. remember - the link would exit only in your
development director - once you tar it up and the user installs it the
mylib.rb and mylib-0.0.0.rb simply become a copy but each time the user
installs a new verion the mylib.rb gets clobbered leaving the versioned one
behind to be used.

make sense?

[...]

i have some boilerplate scripts/code generators that spew all this stuff out,
including all the relative path bits, if you are interested.

Some. I'll see if I can make it work for future versions; part of the
problem is that I'm actively developing on Windows, so I can't do a
symlink; I have to do a copy. So I'll definitely need scripts to wrap
that up. It certainly is an intriguing solution that might offer some
suggestions for the future of RubyGems. Can you send those scripts on?

-austin

···

On 6/15/05, Ara.T.Howard@noaa.gov <Ara.T.Howard@noaa.gov> wrote:

On Wed, 15 Jun 2005, Austin Ziegler wrote:

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca