freenode/#clim - IRC Chatlog
Search
10:49:08
jackdaniel
cl-dejavu system is now available on Quicklisp, so we should be able to just put a dependency from McCLIM and get rid of hardcoded dejavu paths
11:52:13
jackdaniel
clipping with xrender: https://files.mastodon.social/media_attachments/files/105/621/874/626/961/414/original/13f6448e567b2124.png
15:03:51
ck_
I was sick but can now try to attempt working on those open compose-in implementations. Is there a test or demo for that already? Otherwise I think creating one is a good first step
15:05:21
jackdaniel
you may reduce things when due, but do not be tempted to i.e manually blend inks
15:06:36
jackdaniel
in principle we want to be able to take each ink in the "composition" and do the real composition i.e in a hardware-accelerated backend's method
15:16:53
jackdaniel
now, I have found an interesting bug: changing the medium transformation does not invalidate the clipping region (but it should!)
15:18:31
jackdaniel
why? because (setf medium-clipping-region) in fact stores a transformed region and the reader untransforms it
15:18:58
jackdaniel
as o fwhy we store in sheet coordinates is a mystery to me, but I'm not going to touch that for now
15:24:36
ck_
I'll be ok, thanks. By test or demo I meant a matrix with a set of ink/medium combinations, so we have something to look at. Is this a bad idea? Please take into account that I'm only just trying to get familiar with the terminology of the spec
18:20:39
scymtym
jackdaniel: the "patterns and designs" demo says if the y axis is flipped, DRAW-PATTERN* should draw the pattern within the flipped region (but without flipping the pattern itself, of course). do you know where the requirement to adjust the pattern position comes from?