| | <<<Back 1 day (to 2011/07/08) | 2011/07/09 |
| Robin_Watts | tor8: Dunno if you saw my new version last night. | 11:19.00 |
| tor8 | Robin_Watts: yes, I saw but was too tired to review it and commit | 11:19.37 |
| Robin_Watts | np. | 11:19.42 |
| | I suspect we can do better for tiles than I'm currently doing. | 11:20.08 |
| | When I hit a tile, I just say that it has an infinite bbox. | 11:20.25 |
| tor8 | I punt on a lot of stuff for tiles anyway, I wouldn't worry about it :) | 11:20.29 |
| | they're rendered in an isolated context, and then the pixmap is copied to the destination area repeated NxM times to fill | 11:21.37 |
| | looks good so far, let me just run the bigger test set first | 11:29.15 |
| | Robin_Watts: no diffs on the fts :) | 11:52.37 |
| Robin_Watts | excellent. | 11:52.46 |
| tor8 | pushed | 11:55.14 |
| pdewacht_ | What's the recommended way to write Linux printer drivers? | 16:00.06 |
| | Some drivers are ghostscript devices, some use the cups raster api, some implement the IJS spec, and others do other things | 16:00.52 |
| kens | I'm not sure there is a recommended way. | 16:01.08 |
| | It probably depends what you want to do. | 16:01.16 |
| | Writing GS devices is hard though, using CUPS is probably better | 16:01.35 |
| | There is a generic CUPS device for GS | 16:01.44 |
| pdewacht_ | I want to get my parent's printer working with free software :) | 16:02.20 |
| kens | Writing a device sounds heroic ! | 16:02.40 |
| pdewacht_ | they have a cheap Brother multi-function printer | 16:03.00 |
| | but it's PCL implementation is too buggy to use | 16:03.15 |
| kens | Linux isn't my field of expertise. | 16:03.44 |
| | And msot of the other developers are out right now, it being a weekend | 16:04.02 |
| | You might get better help on a weekday. THough we are mmore able to help with GS than generic Linux | 16:04.22 |
| pdewacht_ | I have to do paying work on weekdays :) | 16:04.59 |
| kens | Us too :-) | 16:05.07 |
| pdewacht_ | but I'll look into the cups api | 16:05.09 |
| kens | A CUPS driver is probably better. | 16:05.23 |
| pdewacht_ | do you know of any more general linux printing channel? | 16:05.58 |
| kens | I'm sorry I don't. | 16:06.09 |
| pdewacht_ | apparently there used to be #openprinting but it's dead now | 16:06.15 |
| | ok, thanks | 16:06.28 |
| kens | Yes, I think the open printing intiative died. | 16:06.30 |
| Robin_Watts | pdewacht_: Probably you want to check back here in the week and speak to tkampeter. | 17:52.36 |
| | He's one of the lead developers for cups. | 17:52.50 |
| | Morning mvrhel2 | 18:29.48 |
| | I missed your comments on that bug until after I'd dug some more. | 18:30.02 |
| mvrhel2 | no problem. I should have a fix here shortly | 18:30.30 |
| Robin_Watts | It looks vaguely like a caching cockup to me ? | 18:30.37 |
| mvrhel2 | yes | 18:32.10 |
| | the issue is that the compare next.all[0] == run.all[0] only looks at the CMYK parts | 18:36.04 |
| Robin_Watts | ah, cool. that's kinda what I'd imagined it might be from observation. | 18:39.27 |
| ray_laptop | mvrhel2: I just committed the fix for the 12-07D.PS (nulldevice profile). Unless my cluster push didn't do what I thought, it should be OK. | 19:09.35 |
| | once I see the results from the git regression, I'll close the bug | 19:10.24 |
| mvrhel2 | ray_laptop: great | 19:16.29 |
| | ray_laptop: the object dep. color stuff seems to be working on the output end. | 19:16.58 |
| | I need to do some testing for the input side | 19:17.05 |
| | I may need to create some funny profiles to test this | 19:17.37 |
| | and create an document with rgb and cmyk images, graphic and text | 19:17.57 |
| | s/an/a/ | 19:18.14 |
| | Then I need to add in the profile override then I think I will have almost everything I need in place | 19:18.58 |
| | Robin_Watt: so the next thing to think about is how can we leverage the existing planar tile code (used for transparency) for use with the planar device | 19:32.39 |
| Robin_Watts | yeah. | 19:33.05 |
| | So, you want to change the pattern accumulator device to accumulate in planar form if we are going to a planar device? | 19:33.40 |
| mvrhel2 | that is my thought | 19:33.53 |
| Robin_Watts | It seems reasonable (and I think ray agrees from when I mentioned the problem on irc) | 19:34.10 |
| mvrhel2 | the trick is that this is currently tied to there being transparency | 19:34.12 |
| Robin_Watts | but I don't have a clear enough overview of the system to know whether that might still leave us open to having problems in specific cases. | 19:34.48 |
| mvrhel2 | yes. I need to review the way things work in the transparency case | 19:35.34 |
| Robin_Watts | At the moment patterns can be chunky and the output device can be planar. If we change the patterns to be planar too, do we ever swap devices to chunky? | 19:36.04 |
| | sorry, that was badly expressed. | 19:36.21 |
| | swapping to use a pattern accumulator device, we change from planar to chunky. | 19:36.43 |
| mvrhel2 | basically, the pattern accumulator is a hybrid device in that it can accumulate in a chunky structure or a planar structure | 19:36.59 |
| Robin_Watts | Are there any other devices that get swapped in that might cause a similar change ? | 19:37.01 |
| mvrhel2 | we could choose to use it based upon the target device. | 19:37.17 |
| | right now, if the target is pdf14 then we use the planar structure | 19:37.35 |
| Robin_Watts | for instance, the clist is one (but that knows about planar target devices) | 19:37.41 |
| mvrhel2 | we could basically do it if the target is planar | 19:37.42 |
| Robin_Watts | Right. | 19:37.47 |
| | That sounds neat enough. | 19:37.57 |
| | I was worried that the pdf14 device (being a device that can be 'swapped in') might cause us problems. | 19:38.19 |
| | but it sounds like it's half way towards being our solution. | 19:38.28 |
| mvrhel2 | yes. | 19:38.33 |
| Robin_Watts | Are there any other devices that can be 'swapped in' ? | 19:38.41 |
| mvrhel2 | nothing of the magnitude of the pdf14 and pattern accumulator | 19:39.02 |
| Robin_Watts | Any other device that can be swapped in could in theory get us back to this problem again. | 19:39.30 |
| mvrhel2 | right | 19:39.43 |
| Robin_Watts | I can't think of anything else offhand, but, as I say, my overview of the whole system still has large holes in it. | 19:40.02 |
| mvrhel2 | I dont think the overprint compositor could cause any issues. | 19:40.16 |
| | but I am not sure | 19:40.22 |
| Robin_Watts | must go pick up food. back in 15 mins or so. | 19:40.24 |
| mvrhel2 | ok. I need to run some errands too. | 19:40.31 |
| | be back in a couple hours... | 19:40.37 |
| | testing my fix now for the deviceN problem | 19:40.46 |
| Robin_Watts | cool. | 19:40.51 |
| mvrhel2 | ttyl | 19:41.10 |
| | hmm. my minor fix appears to have had some problems | 22:58.45 |
| Robin_Watts | howso? | 23:13.11 |
| | Forward 1 day (to 2011/07/10)>>> | |
IRC Logs