00:31:50 *** StormTide has quit (Quit: Leaving)
00:41:38 *** Springmeyer_ (~mobile@166.205.138.23) has joined #mapnik
00:42:33 *** Springmeyer_ has quit (Client Quit)
01:08:06 *** jctull has quit (Quit: jctull)
01:09:58 *** Ldp__ has quit (Ping timeout: 256 seconds)
01:24:41 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
01:27:59 <springmeyer> DarcyB: do your shapefiles have a .prj file?
02:17:04 *** tcarobruce has quit (Quit: tcarobruce)
02:30:40 *** aude has quit (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20100106054534])
03:48:47 *** jfxberns (~jfxberns@ppp-58-8-126-165.revip2.asianet.co.th) has joined #mapnik
03:53:13 *** cgs_bob_ (~bob@54.sub-75-210-67.myvzw.com) has joined #mapnik
04:21:27 *** cgs_bob_ has quit (Ping timeout: 276 seconds)
04:54:51 *** StormTide (~Kevin@2002:186c:64c0:0:21d:60ff:fe5e:cf66) has joined #mapnik
05:12:02 *** HounD (~HounD@unics1.grfc.ru) has joined #mapnik
05:14:46 *** HounD has parted #mapnik (None)
05:54:46 *** gavinf has quit (Ping timeout: 245 seconds)
06:11:02 *** tcarobruce (~tim@c-98-210-194-147.hsd1.ca.comcast.net) has joined #mapnik
06:12:50 *** Arc is now known as hacdc
06:12:55 *** hacdc is now known as Arc
06:20:30 *** gavinf (~gavinf@41.4.40.16) has joined #mapnik
06:29:16 *** jfxberns has quit (Quit: jfxberns)
06:30:19 *** jfxberns (~jfxberns@ppp-58-8-126-165.revip2.asianet.co.th) has joined #mapnik
06:30:27 *** tcarobruce has quit (Quit: tcarobruce)
06:32:11 *** tcarobruce (~tim@c-98-210-194-147.hsd1.ca.comcast.net) has joined #mapnik
06:56:07 *** jfxberns has quit (Quit: jfxberns)
07:05:08 <dodobas> yello
07:15:24 *** jfreeman has quit (Remote host closed the connection)
07:42:29 *** springmeyer has quit (Quit: springmeyer)
07:55:36 *** tcarobruce has quit (*.net *.split)
07:55:36 *** mapnikbuild has quit (*.net *.split)
08:02:45 *** tcarobruce (~tim@c-98-210-194-147.hsd1.ca.comcast.net) has joined #mapnik
08:02:53 *** tcarobruce has quit (Client Quit)
08:03:28 *** cgs_bob (~bob@122.135-78-65.ftth.swbr.surewest.net) has joined #mapnik
08:31:57 *** gavinf has quit (Remote host closed the connection)
09:18:59 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
09:18:59 *** mperry has quit (Read error: Connection reset by peer)
09:19:00 *** mperry_ is now known as mperry
09:52:58 *** mapnikbuild (~mapnikbui@miranda.nwcr.net) has joined #mapnik
10:32:00 *** gavinf (~gavinf@41.4.40.16) has joined #mapnik
11:10:59 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
11:10:59 *** mperry has quit (Read error: Connection reset by peer)
11:11:00 *** mperry_ is now known as mperry
11:28:27 *** gavinf has quit (Remote host closed the connection)
11:36:47 *** jburgess has quit (Ping timeout: 246 seconds)
11:38:40 *** jburgess (~jburgess@15.92.187.81.in-addr.arpa) has joined #mapnik
12:24:32 *** Ldp__ (~thid@osm.xs4all.nl) has joined #mapnik
12:25:44 *** jfxberns (~jfxberns@ppp-58-8-126-165.revip2.asianet.co.th) has joined #mapnik
12:25:46 *** jfxberns has quit (Excess Flood)
12:37:30 *** jfxberns (~jfxberns@ppp-58-8-126-165.revip2.asianet.co.th) has joined #mapnik
12:55:32 *** gavinf (~gavinf@41.4.40.16) has joined #mapnik
12:57:09 *** ajturner has quit (Quit: ajturner)
13:39:59 *** gavinf has quit (Ping timeout: 246 seconds)
13:40:01 *** ajturner (~ajturner@pool-72-66-109-70.washdc.fios.verizon.net) has joined #mapnik
13:42:12 *** hobu has quit (Excess Flood)
13:42:45 *** hobu (~hobu@epimetheus.hobu.net) has joined #mapnik
13:48:51 *** hobu has quit (Excess Flood)
13:53:44 *** StormTide has quit (Read error: Operation timed out)
13:54:39 *** StormTide (~Kevin@2002:186c:64c0:0:21d:60ff:fe5e:cf66) has joined #mapnik
13:55:13 *** mperry_ (~mperry@c-67-164-175-65.hsd1.co.comcast.net) has joined #mapnik
13:55:13 *** mperry has quit (Read error: Connection reset by peer)
13:55:14 *** mperry_ is now known as mperry
14:17:37 *** chad_burt has quit (Quit: Leaving...)
14:17:48 *** chad_burt (~chad_burt@mm-01.msi.ucsb.edu) has joined #mapnik
14:24:08 <DarcyB> springmeyer yes my files ahve the associated .prj file
14:37:44 *** hobu (~hobu@epimetheus.hobu.net) has joined #mapnik
14:51:04 *** ajashton (~aj@c-69-136-229-112.hsd1.dc.comcast.net) has joined #mapnik
15:36:17 *** gavinf (~gavinf@41.3.29.162) has joined #mapnik
15:42:28 *** D3f0 (~D3f0@www.transpa-sa.com.ar) has joined #mapnik
16:29:08 *** gavinf has quit (Remote host closed the connection)
16:39:29 *** springmeyer (~springmey@c-76-28-156-154.hsd1.wa.comcast.net) has joined #mapnik
16:41:49 *** jctull (~jctull@ppp-71-142-138-235.dsl.renocs.pacbell.net) has joined #mapnik
16:58:37 *** D3f0 has quit (Ping timeout: 264 seconds)
17:06:09 <springmeyer> DarcyB: if your shapefiles have a .prj, then you need to set the cooresponding 'srs' parameter in the XML
17:06:24 <springmeyer> it will be the proj4 string for a given projection
17:06:42 <springmeyer> http://spatialreference.org is a good place to help generate that
17:07:13 <DarcyB> springmeyer yes my files ahve the associated .prj file
17:07:35 <DarcyB> and I've done that to the best of my knowledge.   But I'll run through them another time when I return.
17:07:53 <springmeyer> okay
17:23:56 *** cgs_bob has quit (Ping timeout: 245 seconds)
17:31:26 <StormTide> springmeyer, did you see your marine mapping guy yet?
17:31:39 <StormTide> if not ive got a question that you might pass along fer me
17:32:09 <StormTide> im trying to get a copy of the s-52 presentation library digital format files.... they seem to be pretty rare.
17:32:46 <springmeyer> ya, turns out he's a programmer more than a marine guy
17:33:27 <StormTide> drats
17:33:41 <StormTide> these files are like, nonexistant on the web
17:34:02 <StormTide> apparently theres a standard set for svg's and such of buoys and navigational markers in something called iho s-52
17:34:14 <StormTide> but you cant download it
17:35:21 <StormTide> i did manage to find a partial set on wikimedia tho.... http://commons.wikimedia.org/wiki/Category:Nautical_Chart_Icons
17:35:35 <StormTide> which might be useful to someone ere
17:50:45 *** tcarobruce (~tcarobruc@adsl-75-10-247-30.dsl.pltn13.sbcglobal.net) has joined #mapnik
17:56:39 *** Phurl__ has quit (Remote host closed the connection)
18:00:27 *** Phurl (~mdupont@2001:0:53aa:64c:38de:21f2:ae2d:1b81) has joined #mapnik
18:01:06 *** Phurl is now known as Phurl__
18:14:35 *** ajturner has quit (Quit: ajturner)
18:29:32 *** gavinf (~gavinf@41.3.29.162) has joined #mapnik
18:35:13 *** ajturner (~ajturner@209.155.228.129) has joined #mapnik
19:09:42 <StormTide> springmeyer, is it possible to draw a patterned line in mapnik with the linesymbolizer
19:10:02 <springmeyer> `LinePatternSymbolizer
19:10:02 <nikq> http://trac.mapnik.org/wiki/LinePatternSymbolizer
19:13:26 <StormTide> nikq, thx, is the an example of the png format
19:13:49 *** HuskyRunner (~dkb@66-219-8-179.ip.gvtel.com) has joined #mapnik
19:15:44 <HuskyRunner> Hello.  Could someone enlighten me as to why osm2pgsql would only be creating/importing the "way" column in my postgresql tables?
19:16:25 <springmeyer> StormTide: nikq is a bot
19:16:36 <StormTide> lol
19:16:40 *** cgs_bob (~bob@146.sub-75-210-45.myvzw.com) has joined #mapnik
19:16:41 <StormTide> coulda fooled me
19:16:48 <StormTide> oh nm
19:16:50 <StormTide> i see
19:16:56 <StormTide> i didnt catch the nickname change
19:16:57 <springmeyer> nikq: wazzup?
19:17:10 <springmeyer> hmm
19:17:22 <StormTide> springmeyer, im trying to render .... http://195.217.61.120:8080/data/INT1%5CIL30.2.jpg
19:17:43 <StormTide> http://195.217.61.120:8080/data/INT1%5CIL31.2.jpg <--- too
19:17:50 <springmeyer> @seen artem
19:18:43 <springmeyer> StormTide: sure
19:19:05 <springmeyer> HuskyRunner: so really no other fields?
19:19:45 <HuskyRunner> I think I see why, I am using the default.style in osm2pgsql
19:19:50 <springmeyer> I've only seen that once when osm2pgsql did not build correctly against the geos library
19:20:00 <springmeyer> no, default.style is fine
19:21:08 <HuskyRunner> hmm.. yes, get error when ./generate_xml.py
19:21:18 <HuskyRunner> RuntimeError: PSQL error:
19:21:18 <HuskyRunner> ERROR:  column "aeroway" does not exist
19:21:18 <HuskyRunner> LINE 2:       (select way,aeroway,amenity,landuse,leisure,man_made,m...
19:21:18 <HuskyRunner>                           ^
19:21:39 <HuskyRunner> and look in db and find only "way" column in my gis db
19:21:51 <springmeyer> yep, that is a problem
19:22:16 <springmeyer> try importing again?
19:22:20 <HuskyRunner> tried that
19:22:24 <springmeyer> how did you build osm2pgsql?
19:22:39 <HuskyRunner> from scratch on OS X
19:23:28 <HuskyRunner> that could be it then, I am using the kyngchaos frameworks for the other libraries
19:24:56 <HuskyRunner> I take it I need to modify the makefile when building osm2pgsql and using the kyngchaos frameworks ?
19:25:07 <springmeyer> so.... the makefile will not find the..
19:25:09 <springmeyer> yep
19:25:13 <springmeyer> you need to modify it
19:25:22 <springmeyer> otherwise osm2pgsql won't compile
19:25:29 <HuskyRunner> it does compile though
19:25:57 <springmeyer> hmm
19:26:02 <StormTide> springmeyer, do you have /home/mapnik/mapnik/symbols/cliff.png ?
19:26:04 <springmeyer> what does this give?
19:26:13 <springmeyer> cd osm2pgsql_sources
19:26:13 <StormTide> trying to see what format this should be in to repeat right
19:26:14 <springmeyer> otool -L osm2pgsql
19:27:09 <HuskyRunner> 	/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)
19:27:09 <HuskyRunner> 	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
19:27:09 <HuskyRunner> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0)
19:27:10 <HuskyRunner> 	/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 40.0.0)
19:27:10 <HuskyRunner> 	/Library/Frameworks/GEOS.framework/Versions/3/GEOS (compatibility version 4.0.0, current version 4.2.0)
19:27:10 <HuskyRunner> 	/usr/local/pgsql/lib/libpq.5.dylib (compatibility version 5.0.0, current version 5.2.0)
19:27:10 <HuskyRunner> 	/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
19:27:11 <HuskyRunner> 	/Library/Frameworks/PROJ.framework/Versions/4/PROJ (compatibility version 7.0.0, current version 7.6.0)
19:27:11 <HuskyRunner> 	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
19:29:40 <springmeyer> that looks fine
19:29:47 <HuskyRunner> ah, I did a "make clean" and then tried rebuilding osm2pgsql
19:29:51 <springmeyer> odd it linked to icucore, but should not be a problem
19:29:54 <springmeyer> sure
19:30:00 <HuskyRunner> and get: make: geos-config: Command not found
19:31:10 <springmeyer> if you are using the Frameworks you need to put their bin directories on your path
19:31:22 <springmeyer> via ~/.bash_profile or /etc/profile...
19:31:23 <springmeyer> http://dpaste.com/157568/
19:31:45 <springmeyer> but proj4 does not have a config program so I've always needed to manually modify the makefile
19:34:18 <springmeyer> http://dpaste.com/157571/
19:34:37 <HuskyRunner> ok, that fixed the GEOS errors but the projection problem as you mentioned
19:35:03 <HuskyRunner> will add the proj changes now
19:37:14 <HuskyRunner> yay, that compiles
19:39:35 <HuskyRunner> trying reimporting
19:41:47 <HuskyRunner> definitely processing more now
19:42:26 <HuskyRunner> I'm wondering how it compiled the first time
19:43:00 <HuskyRunner> Processing: Node(7490k) Way(525k) Relation(0k)COPY_END for COPY planet_osm_ways FROM STDIN;
19:43:00 <HuskyRunner>  failed: ERROR:  duplicate key value violates unique constraint "planet_osm_ways_pkey"
19:43:01 <HuskyRunner> CONTEXT:  COPY planet_osm_ways, line 516642: "47845116	{608521516,608521519,608521520,608521523,608521524,608521526,608521528,608521530,608521532,..."
19:49:06 <HuskyRunner> I was using the "-s" slim option with osm2pgsql but don't have the intarray contrib module installed, after I removed the "-s" option it imported the data
19:49:12 *** gavinf has quit (Remote host closed the connection)
19:52:25 *** cgs_bob has quit (Ping timeout: 260 seconds)
19:53:15 <HuskyRunner> as an experiment I tried re-importing with -s again and got same error
20:00:48 <jburgess> that error means that your input data contains two ways with the same id value
20:01:12 <jburgess> that is not normally valid, but only the slim mode actually has a way to chek for this
20:01:42 <HuskyRunner> I'm using one of the downloads from cloadmade as the source
20:01:49 <jburgess> the problem has come up in the past when someone tries to import data from multiple extracts (e.g. a couple of neighbouring counties or countries)
20:01:50 <HuskyRunner> *cloudmade
20:02:24 <jburgess> and there was some ways which are near or cross the border and appear in both extracts
20:02:59 <jburgess> HuskyRunner: just a single extract or multiple ones?
20:03:10 <HuskyRunner> single: http://downloads.cloudmade.com/north_america/united_states/minnesota#downloads_breadcrumbs
20:03:31 <jburgess> ok, do you think you need the slim mode?
20:04:32 <HuskyRunner> I am just trying to get a sample mapnik rendered tile server going so it is not critical but it helpful to know why the data is wrong
20:05:04 <HuskyRunner> so the extract on cloudmade was created incorrectly for minnesota at least?
20:05:17 <jburgess> we saw something similar happen in another extract when it contained two versions of the same object
20:05:59 <jburgess> it is not normal but some tools will handle it gracefully, others do not
20:07:26 <HuskyRunner> so the problem is originating from however cloudmade created the extract for MN?
20:08:23 <jburgess> yes, but there is also an argument that osm2pgsql could cope with this situation better
20:08:27 *** jfxberns has quit (Quit: jfxberns)
20:08:57 <jburgess> I think there is a way to fix the data by running it through osmosis but I don't have the command to hand at the moment
20:09:41 <HuskyRunner> if you processed the entire planet this problem would not exist, correct?
20:10:00 <jburgess> correct, there are no duplicates in the full planet export
20:10:21 <jburgess> I'll take a quick look and let you know if I can tell you the right osmosis command
20:13:42 <Ldp__> jburgess: if you were thinking of --simc, that works on change streams only
20:15:09 <jburgess> Ldp__: I thought frederick showed a way to fix this on an existing osm file using osmosis. I thought this used --simc but perhaps not
20:16:30 <jburgess> HuskyRunner: did you download the mmesota file recently? I just downloaded the current file and it appears to only have a single reference to way 47845116
20:16:59 <HuskyRunner> I downloaded it maybe a week ago
20:17:27 <HuskyRunner> I will download current one and see what happens
20:17:42 <Ldp__> I think the CloudMade extracts have been broken ever since the regular diffs were disabled, or around that time anyway
20:18:10 <Ldp__> jburgess: you may have read this one: http://lists.openstreetmap.org/pipermail/osmosis-dev/2010-January/000446.html
20:18:47 <jburgess> no, I think there was a post about one of the early Haiti dumps
20:19:12 <HuskyRunner> the file size is about 8MB larger then the one I was processing
20:19:25 <Ldp__> jburgess: I think that was the same issue, ie. an extract kept up to date with the repl diffs, without --simc
20:19:43 <jburgess> right, the cause was the same
20:20:04 <Ldp__> but I know of no way to fix an extract like this with osmosis
20:20:04 <jburgess> and the long term fix was to use --smic but there was a quick workaround which fixed up the data using osmosis
20:20:12 <Ldp__> hmm
20:21:08 <HuskyRunner> will take 30 min or so before it finishes downloading :(
20:23:10 <Ldp__> jburgess: ah, think I remember that. He took an empty .osm file, did --dc then --ac --simc --wx
20:23:16 <jburgess> Ldp__: http://www.mail-archive.com/dev@openstreetmap.org/msg10343.html
20:23:34 <Ldp__> yup, just remembered that
20:24:17 <Ldp__> doesn't address the fact that the CM extracts seem broken in this regard
20:24:54 <jburgess> HuskyRunner: if you still run into problems you could try to fix the file using the osmosis commands referenced in the link above
20:25:07 <HuskyRunner> ok, thank you
20:42:47 *** cgs_bob (~bob@120.sub-75-210-62.myvzw.com) has joined #mapnik
20:50:45 *** cgs_bob has quit (Ping timeout: 260 seconds)
21:13:29 <HuskyRunner> the new Minnesota.osm file from CloudMade that was generated on Feb 4th does not give the error for me with the -s option.  I had the download from JAn 27th which does have an error in the extract.
21:16:05 *** jfreeman (~jfreeman@mail.agileware.net) has joined #mapnik
21:18:27 *** jfreeman has quit (Remote host closed the connection)
21:20:45 *** jfreeman (~jfreeman@mail.agileware.net) has joined #mapnik
22:00:49 *** gavinf (~gavinf@196.211.119.210) has joined #mapnik
22:59:09 *** cgs_bob (~bob@141.sub-75-210-114.myvzw.com) has joined #mapnik
23:21:10 <HuskyRunner> any further hints why osm2pgsql would only be adding the "way" column to the db tables?
23:22:36 *** cgs_bob_ (~bob@141.sub-75-210-114.myvzw.com) has joined #mapnik
23:22:45 *** cgs_bob has quit (*.net *.split)
23:22:45 *** ajashton has quit (*.net *.split)
23:22:45 *** chad_burt has quit (*.net *.split)
23:24:00 <jburgess> HuskyRunner: the "way" column contains the geometry information for each point/line/polygon
23:24:18 <jburgess> aka "the_geom" in many of the postgis docs
23:24:59 <jburgess> the other columns will be added as they are specified in the style file (normally default.style)
23:25:50 <jburgess> perhaps if your style file was empty then you would probably just get the way column... and probably little or no data imported either
23:25:57 *** ajashton (~aj@c-69-136-229-112.hsd1.dc.comcast.net) has joined #mapnik
23:26:03 *** chad_burt (~chad_burt@mm-01.msi.ucsb.edu) has joined #mapnik
23:26:20 <HuskyRunner> I ran osm2pgsql against my osm file and the tables only have the "way" column so when I try the generate_xml.py I get error about the next column it looks for missing
23:26:48 <springmeyer> HuskyRunner: what the the EXACT command you used to run osm2pgsql ?
23:27:19 *** ajturner has quit (Quit: ajturner)
23:27:25 <jburgess> can you pastebin "\d planet_osm_point" e.g. http://pastebin.ca/1794055
23:27:58 <HuskyRunner> ./osm2pgsql -v -U mapadmin -S /Users/db/Development/Weather/osm2pgsql -m -d gis /Users/dkb/Downloads/minnesota2.osm.bz2
23:28:22 <jburgess> osm2pgsql -p haiti --slim 2010-01-21-19-30.osm.bz2 -S ~/svn.openstreetmap.org/applications/utils/export/osm2pgsql/default.style
23:28:46 <jburgess> what does your "/Users/db/Development/Weather/osm2pgsql" file contain?
23:29:10 <HuskyRunner> isn't that where you specify the style directory?
23:29:19 <springmeyer> osm2pgsql must not be throwing an error when passed an invalid style...
23:29:31 <jburgess> it should look something like... http://pastebin.ca/1794058
23:29:34 <HuskyRunner> I get no errors
23:30:03 <jburgess> I can't say for certain since I didn't write that piece of code
23:30:19 <jburgess> but if it read nothing from that file then you would probably end up with what you describe
23:30:43 <jburgess> try using the original default.style and see if that makes a difference
23:31:09 <HuskyRunner> that would make sense and it is trying to use the default style located at /usr/share/osm2pgsql/default.style which doesn't exist on my system
23:31:16 <jburgess> HuskyRunner: not the directory, it is the filename
23:31:34 <HuskyRunner> that's terrible if it isn't giving me an error because of that! :p
23:31:41 <jburgess> it could be we're missing an error check on the file open
23:32:11 <HuskyRunner> running it again
23:32:13 <jburgess> or perhaps the open of the directory partially succeeds
23:32:50 <springmeyer> terrible is a bit harsh HuskyRunner
23:33:11 <HuskyRunner> hence my smiley
23:33:40 <springmeyer> ha ha
23:34:37 <HuskyRunner> I'll find the location in code and see if I can't make a correction if you wish for better error check
23:34:53 <HuskyRunner> if you wish
23:35:06 <jburgess> yep - the code is not properly checking the read() of the style file, see http://pastebin.ca/1794061
23:39:37 <HuskyRunner> that was it!
23:40:06 <HuskyRunner> For some reason I thought it wanted the directory location instead of full path of file
23:42:04 <HuskyRunner> thanks for pointing out the issue
23:44:53 <HuskyRunner> generate_xml.py is also happy now as well
23:46:04 <cmarqu> The first slippy map I see that was rendered with Kosmos: http://www.ts-eastrail.de/wandern/
23:50:45 <springmeyer> cool, painfully slow it seems, but looks nice
23:51:59 <springmeyer> cmarqu: you got ideas for GSOC/Mapnik ?
23:52:04 <jburgess> HuskyRunner: in response to your issue, I just added checks into the osm2pgsql code for: an error when reading the file or no valid columns
23:52:12 <springmeyer> e.g tickets that could be raised/formed into projects?
23:53:22 <HuskyRunner> jburgess, thank you
23:53:44 <Ldp__> jburgess, springmeyer: http://trac.openstreetmap.org/ticket/2571
23:54:27 <springmeyer> nice spot Ldp__
23:54:46 <Ldp__> I asked him to create the ticket, back then :)
23:55:00 <springmeyer> great
23:55:15 <jburgess> I have been a slack at checking the trac tickets for the past few months... we can mark this resolved now
23:55:24 <springmeyer> hey Ldp__ after #512, I think I'm convinced we need a Mapnik 0.7.1 release
23:55:25 <nikq> Ticket #512: Need to enforce AA/default gamma function post #428/r1557, http://trac.mapnik.org/ticket/512
23:56:04 <springmeyer> I'm just really tight on time right now so I don't know when I will be able to fit in the work, but wanted to let you know
23:56:16 <Ldp__> springmeyer: ok, thx for heads up
23:58:48 <Ldp__> does any of the gamma work for/influence cairo based renders?
23:59:44 *** HuskyRunner has quit (Quit: HuskyRunner)