Comments (6)
(Imported. Original comment by [email protected] on March 31, 2011, 04:08:27 PM UTC)
Still not sure why setting the color causes this bug to show up, but after a bit more playing around I think the problem has to do with freeze.
from diagrams-cairo.
(Imported. Original comment by [email protected] on April 2, 2011, 05:51:35 PM UTC)
I still don't know how to fix this, but I've narrowed the problem down a bit more. The problem seems to be that when rendering a primitive with multiple transformed attributes, the attribute transformations are accumulated rather than being applied separately for each attribute. Concretely,
d # attr1 # ... # attrN # freeze # transform
will have 'transform' applied N times.
I guess we need to somehow group attributes with a common transformation applied to them and do them all at once. It would probably help to retain more structure within a diagram, i.e. have a monoidally-annotated tree rather than immediately flattening everything out into a list of primitives. For example, that way we know that a transformation node applies to everything beneath it; once we flatten the tree out and just have a list of attributes paired with transformations it's impossible to know which transformations "came from the same place" and should hence be grouped and applied only once.
...well, so maybe I do know how to fix it. =)
from diagrams-cairo.
(Imported. Original comment by [email protected] on April 8, 2011, 10:01:13 PM UTC)
I know issue 15 affects this but I'm attaching a patch for educational purposes that addresses this issue.
from diagrams-cairo.
(Imported. Original comment by [email protected] on April 9, 2011, 12:20:28 AM UTC)
Some relevant text from documentation on the cairo website:
"Be careful when trying to draw lines while under transform. Even if you set your line width while the scale factor was 1, the line width setting is always in user-coordinates and isn't modified by setting the scale. While you're operating under a scale, the width of your line is multiplied by that scale. To specify a width of a line in pixels, use cairo_device_to_user_distance() to turn a (1, 1) device-space distance into, for example, a (0.01, 0.01) user-space distance. Note that if your transform deforms the image there isn't necessarily a way to specify a line with a uniform width."
"When you're working under a deforming scale, you may wish to still have line widths that are uniform in device space. For this you should return to a uniform scale before you stroke the path. In the image, the arc on the left is stroked under a deformation, while the arc on the right is stroked under a uniform scale."
from diagrams-cairo.
(Imported. Original comment by [email protected] on April 9, 2011, 12:57:40 AM UTC)
OK, I think I now have a clear idea how to do this. Along each path from a diagram's root to a leaf, we collect up the applied transformations, being sure to keep separate those occurring before and after the innermost call to freeze (see SplitMonoid.hs in core). After drawing the primitive at the leaf (with all the transformations applied to it -- we can either transform the primitive natively and draw it, or apply the transformation in cairo and draw the untransformed primitive, it amounts to the same thing), we apply the portion of the transformation occuring outside the innermost freeze (this is the part that applies to attributes), set all the attributes, and then stroke. (Actually we could also set the attributes, then apply the transformation and stroke. It took me a while to understand that it doesn't matter what transformation is in effect when you set attributes, only what transformation is in effect when you stroke.)
In particular, a transformation should not be stored along with each attribute. This will not work for the reason noted above: the transformation in effect when setting an attribute makes no difference.
from diagrams-cairo.
(Imported. Original comment by [email protected] on April 11, 2011, 12:04:26 AM UTC)
This is now implemented and seems to work correctly in all the examples I've tried so far, and in particular the test cases I developed to figure out what was going wrong before. It turns out that remembering tree structure is actually not necessary to do this correctly -- it would be enough to remember a "split transformation" (i.e. a pair of transformations before/after the innermost freeze) along with each style/primitive pair and apply the frozen portion of the transformation when setting the style attributes and stroking. In fact the current implementation "flattens" the tree into a list of exactly such triples (primitive, split transformation, style) before rendering. But of course remembering the tree structure is nice for other reasons as well.
from diagrams-cairo.
Related Issues (20)
- Better error message for outputs with zero width or height, or better default
- Bug while drawing certain vertex HOT 10
- Dark line between diagrams at certain widths HOT 2
- Build failure for GHC 7.4 HOT 3
- Mac OS X/XQuartz: Can't render single letter HOT 5
- Color conversions have huge impact on performance HOT 3
- --loop disables generating multiple files HOT 6
- Problems with yellow color in gif animation HOT 1
- expose gifRender HOT 3
- loop when rendering text HOT 5
- Travis build broken HOT 4
- GHC 7.10 support on hackage HOT 10
- Bump vector upper bound to allow 0.12
- Text envelope generation is fontsize ignorant HOT 5
- Relax version boundry on base for version 1.4 HOT 4
- Release GHC 8.6 compatilbe version HOT 2
- Release version with GHC 8.8 support HOT 9
- Please accept ownership of diagrams-gi-cairo HOT 7
- Too strict version bounds on optparse-applicative and base HOT 2
- The base dependency version on the Hackage is inconsistent with the actual version in tar.gz HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from diagrams-cairo.