Skip to content
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 15 commits into from
Nov 6, 2013
Merged

Backend tree conversion #36

merged 15 commits into from
Nov 6, 2013

Conversation

byorgey
Copy link
Member

@byorgey byorgey commented Nov 5, 2013

Port of diagrams-cairo to use the new RTree 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).

Brent Yorgey added 14 commits November 3, 2013 20:38
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.
@byorgey
Copy link
Member Author

byorgey commented Nov 5, 2013

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
@jeffreyrosenbluth jeffreyrosenbluth merged commit 397dd79 into master Nov 6, 2013
@jeffreyrosenbluth jeffreyrosenbluth deleted the backend-tree branch November 6, 2013 03:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants