| | <<<Back 1 day (to 2011/11/20) | 2011/11/21 |
| sebras | Fandekasp: ah.. then I misunderstood you. I wonder if resizing of the document has ever been present in mupdf. | 00:30.51 |
| henrys | mvrhel:do we have a device that you know will work with 2 bits per component? I know the bit devices can be set to -dGrayValues=4, but I don't know if the halftoning works properly. | 03:33.22 |
| kens | tkamppeter the fix for bug #692687 has been committed | 08:58.17 |
| tkamppeter | kens, I saw, thank you very much. I will try it. | 09:10.33 |
| | kens, I will then do the next patch release of GS with this one and the fix of bug 692691. | 09:10.33 |
| kens | tkamppeter if you can wait a day or so I will try and resolve the Duplexing problem as well | 09:10.47 |
| | I'm looking at it now | 09:10.55 |
| tkamppeter | kens, great. | 09:15.12 |
| sebras | I have forgotten to ask tor8, when is your next meeting? | 14:27.44 |
| kens | December 3/4th | 14:27.56 |
| Robin_Watts | sebras: But we'll all be gone from the 29th or 30th Nov or so. | 14:28.23 |
| sebras | ah! thanks a lot! :) then I know I won't be able to do mupdf development (with tor8) until dec 5th or so. | 14:29.58 |
| | Robin_Watts: I'm paying .uk a visit nov 26th-28th. my first time in london, yey! | 14:30.36 |
| Robin_Watts | sebras: Ah, have fun. Coming for a particular reason? | 14:30.56 |
| sebras | Robin_Watts: a friend of mine invited me to go to a Thomas Dolby-concert with him on the 27th. | 14:33.03 |
| Robin_Watts | fair enough. | 14:33.33 |
| henrys | thankgiving this week in the us - we're off thurs and fri. | 16:50.00 |
| kens | Slackers :-) | 16:50.25 |
| henrys | ;-) | 16:50.43 |
| Robin_Watts | yeah. Amazon started their 'Black Friday' sale thing this morning. | 16:50.48 |
| | What's the option to show the pdf operators as the interpreter runs ? | 17:03.33 |
| chrisl | -dPDFDEBUG I think | 17:03.54 |
| Robin_Watts | yeah, thanks. | 17:03.58 |
| henrys | mvrhel I asked you a question last night then realized you weren't here. | 17:09.36 |
| | mvrhel:do we have a device that you know will work with 2 bits per | 17:10.01 |
| | component? I know the bit devices can be set to -dGrayValues=4, but | 17:10.02 |
| | I don't know if the halftoning works properly. | 17:10.02 |
| mvrhel | henrys: I dont think we are set up to do proper multilevel halftoning yet | 17:12.51 |
| | ray_laptop: had done some work with the one customer for their device | 17:13.10 |
| Robin_Watts | henrys, mvrhel: I started to look at 692666 today. As alexcher correctly points out on the bug, it's a series of 'Draw thin horizontal black rectangle. Plot imagemask over the top of that.' calls. | 17:15.39 |
| | The problem is that when gs plots each rectangle, it overwrites a 2 pixel wide slice - one pixel of which was where the previous imagemask was just put. | 17:16.43 |
| henrys | mvrhel:I do wonder if Peter had it working at one time though, I was looking at 692405 I don't think peter would have released these devices without support but it's possible. | 17:17.10 |
| mvrhel | henrys: I can take a look to see what type of quantization they are doing | 17:18.41 |
| | you can assign it to me if you would like | 17:18.52 |
| Robin_Watts | gs 'stretches' rectangles slightly due to the fill adjust rules. So I experimented with some code to 'stretch' images similarly. This is exactly equivalent to the 'gridfitting' we do in mupdf (ensure that every (orthogonal) image completely fills any pixels it touches). | 17:19.31 |
| | And that helps, but it's still not perfect. Looking to find out why now. | 17:19.42 |
| kens | Heading off now, ngiht everyone | 17:21.13 |
| Robin_Watts | night kens | 17:22.15 |
| henrys | mvrhel:will do | 17:24.10 |
| mvrhel | off to coffee shop bbiab | 17:40.54 |
| ray_laptop | henrys: I saw the comments on 2-bit (-dGrayValues=4). AFAIK, the multi-level halftoning works, but it wasn't what customer 532 wanted. I think it just fills up (using the 'spot function') all pixels with a halftone of level 0 and level 1, and doesn't turn on any level 2 bits until the entire cell is at level 1, | 17:44.21 |
| | henrys: I hacked together a 'bitgray2' device that uses multiple threshold arrays (the prototype for their 2-bit device) so they can have halftone patterns that are a combo of level 0, 1, 2 or 3 pixels | 17:45.46 |
| henrys | okay so the x11 stuff (the original bug I was looking at) should work better than it does. All dithered colors are incorrect with the device. | 17:46.42 |
| mvrhel_laptop | ray_laptop: going to grab my coffee | 17:57.52 |
| ray_laptop | mvrhel_laptop: I'll email the final (full page) raw dump of file_1 of bug 692618.pdf | 17:58.57 |
| mvrhel_laptop | ok | 18:00.58 |
| | I only got bits and pieces of your phone call | 18:01.10 |
| ray_laptop | mvrhel_laptop: email sent -- let me know when you have a chance to look at it | 18:04.31 |
| mvrhel_laptop | ok | 18:04.58 |
| ray_laptop | I'll finish what I was doing with my wife in the meantime | 18:05.21 |
| mvrhel_laptop | ray_laptop: I took a look. off hand I don't see anything particularly odd in the alpha channel you may need to walk me through this | 18:12.49 |
| | the image on the right has 100% of weiss and weiss2 | 18:14.27 |
| | and the alpha channel is white in the region | 18:14.36 |
| | which would mean it will be drawn | 18:14.51 |
| | oh I see | 18:15.51 |
| | a little rect fill to the right of the image on the right | 18:16.02 |
| | in the alpha channel | 18:16.05 |
| | that is clearly wrong | 18:16.47 |
| | what is odd, is there were never any fills in that area, unless there was one that was a fill of 0 | 18:17.29 |
| | in which case, the alpha channel would be set to 100% and we should still end up with no ink at that location | 18:18.07 |
| | other than that, I don't see anything particularly odd | 18:19.14 |
| | ray_laptop: when you return, I had a question for you about bug 692618 | 18:33.25 |
| | oh wrong number | 18:33.38 |
| | I mean 692674 | 18:33.53 |
| henrys | bbiab | 18:37.47 |
| mvrhel_laptop | henrys: so I am making some good progress on the shortcut CM stuff. This should be pretty easy to get in for the next release | 19:32.14 |
| henrys | mvrhel_laptop:that's good, we should discuss tomorrow how much we want to push the customer to run gs as a server - are they the only performance complaints? | 19:34.42 |
| mvrhel_laptop | I believe so and as ray pointed out, if they run as a server 9.04 is actually faster | 19:35.10 |
| henrys | hail marcos for catching that regression why didn't it come up when the clusterpush happened. maybe the test is disabled. | 19:36.15 |
| mvrhel_laptop | off to lunch | 20:04.24 |
| Robin_Watts | henrys: If we push them to run gs as a server they'll push back and tell us that pdfwrite doesn't work as a server. | 20:11.29 |
| | henrys: If we push them to run gs as a server they'll push back and tell us that pdfwrite doesn't work as a server. | 20:12.28 |
| henrys | Robin_Watts:I thought from the API it could have separate jobs? | 20:15.40 |
| Robin_Watts | My memory is that kens said that this was a problem, but my memory is notoriously poor. | 20:16.34 |
| | OK. Gridfitting looks to solve the problems with that file. | 20:18.17 |
| | Is anyone going to argue that we shouldn't be gridfitting images? | 20:18.29 |
| henrys | none other than performance. | 20:19.34 |
| Robin_Watts | why should performance matter? | 20:20.03 |
| | Sorry, I'll rephrase. | 20:20.10 |
| henrys | so the rectangle in the file was in the correct position and the image not? | 20:20.13 |
| Robin_Watts | Why should it hurt performance ? | 20:20.15 |
| | The rectangle was correctly being rendered according to the 'touches any part of a pixel' rule, and was ending up being 2 pixels high. | 20:20.49 |
| henrys | I meant I have no objection if there will not be a performance penalty for implementing it. | 20:20.57 |
| Robin_Watts | The image was not being rendered by that rule, and was hence only appearing 1 pixel high. | 20:21.17 |
| | OK. It's a few conversions (double) -> (fixed) -> (int) -> (fixed) -> (float) on every image. | 20:21.56 |
| | i.e. peanuts compared to everything else. | 20:22.06 |
| henrys | okay I'm good. | 20:23.54 |
| Robin_Watts | For the other customer bug I have... it's caused by xps having stroke_adjust being enabled, and a gradient being drawn by doing a series of coloured strokes that are supposed to abut. | 20:30.28 |
| | Disabling stroke_adjust for all of xps gives nasty results (lots of oddly thickened lines) | 20:30.52 |
| | so I'm going to just disable stroke_adjust whilst drawing patterns. | 20:31.10 |
| | If that turns out not to be enough, we can rethink it. | 20:31.26 |
| henrys | have you checked it isn't something that should be done for low resolution only? | 20:33.39 |
| Robin_Watts | The problem referenced in the bug is at 600dpi. | 20:34.12 |
| henrys | you said disabling stroke adjust created problems, but I was speculating those problems are only low resolution problems. | 20:35.10 |
| Robin_Watts | Right. It's certainly most noticable at low resolution. | 20:37.20 |
| | But even at 600dpi, the difference between a 1 pixel wide and 2 pixel wide line is noticable. | 20:37.37 |
| | I'd rather disable it in patterns only to start with, and if people complain then look at a global disabling. | 20:38.49 |
| henrys | okay | 20:39.18 |
| Robin_Watts | rather than dive into some horrible nasty heuristic for 'if the resolution is high enough'. There's enough of that with fill adjust :( | 20:39.23 |
| henrys | XL does it, see px_initgraphics() | 20:39.46 |
| | sigh | 20:40.20 |
| | I can't remember if I did that or Peter. | 20:40.40 |
| Robin_Watts | Well, there's precedent if we have to go down that route then... | 20:41.18 |
| | Well, cluster test running. Marcos is going to love me... | 20:42.19 |
| ray_laptop | robin_watts: you are correct that pdfwrite currently only writes the PDF when GS exits (and the device is finalized). Devices stay 'open' all the time and we don't have a way to force a gs_closedevice on the pdfwrite, so a server (currently) can only write one PDF. | 20:44.35 |
| henrys | cringes and puts that atop the meeting agenda. | 20:48.22 |
| | I assume there is negligible peformance advantage to using the API and creating a new instance each time. | 20:48.58 |
| ray_laptop | henrys: correct -- if you 'delete_instance' and 'new_instance' it still has the start-up shut-down hit | 20:50.39 |
| henrys | well it shouldn't have the process overhead but I imagine that's hardly anything at all. | 20:51.30 |
| ray_laptop | I thought we had an enhancement bug for that, but I can't find it in ken's list | 20:52.14 |
| | henrys: that aspect also prevents them from using the (smaller file size) ps2write as a server | 20:53.47 |
| henrys | we can also look at startup time - I created a bug a while back that the CIE stuff is being created even if it isn't used - that itself is quite a hit. But we should be able to do pdfwrite/ps2write as a server. | 20:54.47 |
| ray_laptop | henrys: mvrhel has identified that even though the pdfwrite device doesn't need the link profile, it _is_ being created, and that helps the pdfwrite case. | 20:56.06 |
| | but when we go to devices that need the color conversion, we do need some way to do it (hence mvrhel's "quick" CMM project). | 20:57.09 |
| henrys | I see the joint cache stuff being built with -ZCc on any ps or pdf job. | 20:57.28 |
| ray_laptop | henrys: joint_cache ??? I thought that went away with 9.00 ??? | 20:58.03 |
| | and with PS jobs, it used to only be invoked when '-dUseCIEColor' was set (but we set that for PDF jobs in the PDF interp) | 20:59.02 |
| henrys | 691998 is the bug. | 20:59.06 |
| | but we seem to be initializing it regardless of if it is actually used. | 20:59.51 |
| ray_laptop | henrys: maybe we should at a reference to that bug on the performance bug | 21:01.34 |
| henrys | yes I agree. | 21:02.27 |
| ray_laptop | henrys: are you going to, or should I ? | 21:03.34 |
| henrys | well maybe michael will just do it when he reads the logs. I've spoken to him about it. | 21:04.27 |
| ray_laptop | henrys: I'll go ahead and do it so mvrhel doesn't miss it. | 21:04.56 |
| | done | 21:06.15 |
| henrys | thanks | 21:07.58 |
| tharkun | Gentlemen i need to merge two ps "files" is it posible to do it using gs using only STDIN as input? | 23:54.52 |
| Robin_Watts | tharkun: In what way 'merge' ? | 23:57.43 |
| tharkun | Robin_Watts: make one file out of two | 23:59.01 |
| Robin_Watts | So... cat file1 file2 > file12 ? | 23:59.28 |
| | Forward 1 day (to 2011/11/22)>>> | |
IRC Logs