-
Notifications
You must be signed in to change notification settings - Fork 16
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
Backend tree conversion #36
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…. A bit less wrong.
The idea is that the font face, weight, and slant must all be set *simultaneously* with a call to `selectFontFace`. When flattening with `prims`, we would get all the attributes collected in one place at a leaf; however, now that we are processing a tree, it won't do to call `selectFontFace` again every time we see a `Style`. Instead we must collect up font attributes as we traverse the tree and only call `selectFontFace` when actually rendering a text primitive. Note that something similar also showed up before with fill and line color: cairo only has a single "source color" so we can't simply set the fill or stroke color as soon as we encounter the corresponding attribute.
I have no idea why this is required.
The problem with storing individual attributes in CairoState is that it completely ignored the semigroup semantics for each attribute! Much more correct---and easier---is to simply accumulate a current Style value, which handles everything for us automatically. Then we can extract the right attributes when needed. Some attributes, of course, can be dispatched immediately instead of accumulating them; but we don't bother preventing them from accumulating anyway.
Previously, the Renderable instance for Path R2 did not do any filling or stroking; now it does. Clipping used to work by calling the Renderable Path instance and then doing a C.clip. But now this was causing the clipping paths to actually get stroked and filled. The solution is that there is now a separate function which draws a Path R2 without stroking or filling it, and both clipping and the Renderable instance call it; clipping then does a C.clip and the Renderable instance then does stroking and filling.
Oops, please don't merge just yet, this depends on diagrams/dual-tree#5 and diagrams/diagrams-core#46. |
jeffreyrosenbluth
added a commit
that referenced
this pull request
Nov 6, 2013
Backend tree conversion
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Port of
diagrams-cairo
to use the newRTree
interface. All tests now pass. I considered cleaning this up by squashing into just a few commits, but all the bugs I encountered are quite instructive (as, I hope, are the detailed commit messages).