New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradients don't work when user space has been transformed #891

Closed
mogest opened this Issue Jul 5, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@mogest
Contributor

mogest commented Jul 5, 2015

I'm the author of prawn-svg, an SVG to PDF renderer that uses prawn, and have had a few requests to implement SVG gradients. @mojavelinux is interested in this for his asciidoctor-pdf project.

Unfortunately, prawn doesn't implement gradients quite right. PDF gradients/patterns take coordinates in the coordinate space of the document, not the "user space", so if you perform a scale/rotate/translate and then paint a gradient inside, it doesn't render correctly.

I have a working solution to this, but it's not super elegant, so I thought I'd bring it up here for discussion before I tidy it enough to be presentable.

The idea is that all calls to transformation_matrix result in the matrix being pushed on to a document-scope stack, and save_graphics_state and restore_graphics_state do what you'd expect them to do with the stack before passing the call on to PDF::Core.

The gradient code has then been extended to matrix multiply the transformations on the stack together, and pass to the PDF Matrix attribute in the shading pattern, instead of using an identity matrix as it currently does.

It works, but is a substantial change. It also means we'd be able to implement a working version of skew, I believe.

Any objections to the approach before I submit a PR?

@packetmonkey

This comment has been minimized.

Contributor

packetmonkey commented Jul 16, 2015

Thanks for the info @mogest, to be honest I'm not 100% comfortable with that code or that part of the spec so I'll take your word at that it's wrong :)

My first question is would implementing your change break backwards compatibility? If so we would need to implement your fix in a way that we can enable the new correct behavior while preserving the old behavior until we release Prawn 3.0 and remove the deprecated wrong code.

I would say throw open a PR so we can look over what you have and see what can be done. I'll try to become more knowledgeable about the area as well so we can come up with the right solution.

@pointlessone

This comment has been minimized.

Member

pointlessone commented Jul 16, 2015

@mogest Is my understanding correct that the problem is here: https://github.com/prawnpdf/prawn/blob/master/lib/prawn/graphics/patterns.rb#L65-L66 (and the relevant calls in the other branch)?

@mogest

This comment has been minimized.

Contributor

mogest commented Jul 19, 2015

@cheba, it's actually the Matrix that's passed on https://github.com/prawnpdf/prawn/blob/master/lib/prawn/graphics/patterns.rb#L124 that's causing the problem. The matrix has to match the current transformations that have been effected in the document.

I've created a pull request @packetmonkey. I'd love to hear what everyone thinks, as I feel like it might be a bit of a contentious solution.

@packetmonkey

This comment has been minimized.

Contributor

packetmonkey commented Aug 13, 2015

This issue can now be closed after the merging of 894. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment