| | <<<Back 1 day (to 2012/07/29) | 2012/07/30 |
| cryptopsy | pipitas: yes | 01:11.35 |
| | hi pipitas | 01:11.40 |
| sebras | morning tor8 | 07:25.27 |
| tor8 | morning sebras | 07:25.44 |
| sebras | tor8: too early! | 07:26.15 |
| tor8 | zzz | 07:26.22 |
| Robin_Watts | reboot | 09:09.01 |
| | What an awesome way to start the week - a clist patterns bug that only occurs on 64bit linux :( | 09:48.05 |
| | Welcome back paulgardiner! How was it? | 09:54.24 |
| paulgardiner | Great. Got some good walks in. Weather messed up one of them, but just one seems like a pretty good result for this country, especially the Lakes. Excellent Hotel within easy walking distance, with superb | 09:56.59 |
| | Pizza | 09:57.03 |
| | And your Breaking Bad DVDs of course. What's not to like?! | 09:57.35 |
| | Wasn't sure how Linda would get on with some of the steaper terrain, but turns out she's like a little mounting goat. Was me that had trouble keeping up. | 10:00.40 |
| pipitas | Hi cryptopsy | 10:16.08 |
| | From reading the backlog of this channel, I understand you want to add left+right margins to PDF pages so that you have wider page dimensions. Is that understanding correct? | 10:17.14 |
| cryptopsy | yes | 11:39.34 |
| | the goal is to specify a margin padding without assuming pagesize or trying to guess pagesize for resize width sum calculation | 11:41.02 |
| henrys | kens:does adobe always use the ctm when compressing or do they detect orthogonal segments and use it for just that? The customer is arguing with Miles so it has come back to me. | 14:18.28 |
| | that was a thought I had to do the change and only affect files that would really benefit but I doubt we should fool with this at all. | 14:22.26 |
| Robin_Watts | Has kens managed to shoehorn it into our code at all ? | 14:23.25 |
| chrisl | Hmm, customer in default is arguing with us, whilst asking us (effectively) for a favour - interesting "people skills"! | 14:25.42 |
| | Robin_Watts: kens did get something like the Adobe output - enough the prove the viability, anyway. I think he said the compression still wasn't quite as good. | 14:26.45 |
| kens | henrys sorry was getting coffee | 14:27.23 |
| henrys | this customer has a long history of having big problems and little money, otoh I think we can check the problem again, I'm concerned this may be a very common issue with cad files and the like. | 14:27.52 |
| kens | I don't believe that Distiller *always* uses this construction, but I admit I have not run many tests. THis is, after all, a zero attention custoemr, so I didn't want to waste lots of time on it | 14:28.04 |
| | Robin_Watts : I got a reduction from 350,000 to 240,000 without trying hard | 14:28.38 |
| | Distiller comes out at 64k | 14:28.46 |
| | So we are a long way from teh same point, but like I said, I didn't try very hard, I was just curious and wanted to investigaet further to satisfy myself | 14:29.25 |
| | THere are other areas in there which show differences. Distiller omits clips sometimes where we do not | 14:29.44 |
| | The emit more 're' constructions instead of laborious move/line rectangles | 14:30.07 |
| | And there may be other things too | 14:30.15 |
| | Given that (according to the customer) the Distiller output processes more slowly, and the difference is 190k vs 600k I haven't been worried by it. | 14:30.56 |
| | henrys i believe the 'problem' is almost certainly limited to a specific kind of output. | 14:31.39 |
| | In this drawing the area of the building is covered in a pseudo-random looking series of short strokes. | 14:32.04 |
| | Many thousands of them | 14:32.12 |
| | THis is what occupiesthe vast majority of the content, and by optimising that, we get the improved compression. | 14:32.40 |
| | I am unconvinced that this is particular to CAD files in general | 14:33.03 |
| | I am also unconvinced that architects truly care that much about what is, after all, not a very large file. | 14:33.35 |
| | The 600Kb is a 2 page architectural drawing, so it doesn't seem huge to me. | 14:34.05 |
| henrys | fair enough, I'll talk to them again and get them to go away. | 14:35.31 |
| | unless you want to have another look. | 14:35.45 |
| kens | OK if you do want me to look at it soe more, or implement the solution properly I can do so of course. I'm not really convinced we should be doing this myself, so I won't look again without someone saying so ;-) | 14:36.24 |
| | I think there are better things to look at | 14:36.32 |
| henrys | okay | 14:40.11 |
| | alexcher are you about? | 14:43.15 |
| | wow beach volleyball in London, bet that doesn't happen often. | 14:45.29 |
| kens | Never :) | 14:45.40 |
| Robin_Watts | On horseguards? No :) | 14:45.41 |
| henrys | the women in bikinis always make prime time in the U.S. | 14:46.18 |
| kens | THere have been a few comments in the press.... | 14:46.36 |
| | The male Sun corrspondent was enhtusiastic, teh female Independent correspondent not at all impressed | 14:47.03 |
| | Especially by the musinc in play breaks being the Benny Hill theme | 14:47.17 |
| henrys | well the ausies showed up in pants - that will not keep them in prime time. | 14:47.38 |
| kens | Apparently bikins are not mandatory this year | 14:47.43 |
| | Though I was under the mipression that was more for the benefit of Muslim and other religions | 14:48.25 |
| Robin_Watts | kens: Naked Beach Volleyball? | 14:48.27 |
| kens | Maybe the Aussies are just cold | 14:48.32 |
| | Robin_Watts : that was seriously proposed for swimming some years ago | 14:48.55 |
| henrys | the customer complain does remind of something we should check maybe marcosw - an output file comparison compressed against adobe - we should stay within a reach of Adbobe on that front. | 14:51.22 |
| | s/complain/complaint | 14:51.31 |
| | Robin_Watts:btw Sabrina and I have been watching American Horror Story thought you and Helen might like it too. | 14:54.23 |
| Robin_Watts | henrys: That's been shown over here, but I missed the start. | 14:54.55 |
| | I just rewatched the first 3 seasons of Sons of Anarchy. Helen was completely hooked. | 14:55.16 |
| henrys | yes that one is on my list. | 14:55.33 |
| Robin_Watts | And we recently watched Season 4 of Breaking Bad - really exceptional. | 14:55.42 |
| henrys | I think we should not hold up the release for blocker 693115 thoughts? | 15:00.01 |
| | can it block the next release? ;-) | 15:00.25 |
| chrisl | henrys: my feeling is that it would be a risky change to go in this late, even if it gets done in the next day or two | 15:02.04 |
| henrys | chrisl:good point | 15:04.39 |
| chrisl | henrys: also, kens made the point that it has been that way for a *long* time, it's not a regression, nor is it exposed by a new "class" of jobs we're seeing. | 15:05.58 |
| | henrys: in case it's not obvious from the above, I don't think we should block 9.06 on 693115....... | 15:08.09 |
| henrys | I changed the bug. | 15:09.16 |
| chrisl | henrys: good - we just have to remember to change it back again after the release :-) | 15:13.17 |
| henrys | or *each* release | 15:13.44 |
| ray_laptop | morning, alll | 15:15.10 |
| chrisl | Right off to play squash - will check the logs when I return...... | 15:15.11 |
| Robin_Watts | Morning ray_laptop | 15:15.19 |
| | I dropped a new bug on you this morning. | 15:15.26 |
| ray_laptop | Robin_Watts: I saw that the fix for the copy_planes didn't cure it ? | 15:15.29 |
| Robin_Watts | ray_laptop: There is still something wrong. | 15:15.48 |
| | This is a file showing up in the bmpcmp when I push the component_max up to 32. | 15:16.04 |
| pipitas | cryptopsy: Ah â you have a solution if you know the current pagesize, but you want one where you don't need that info? | 15:16.05 |
| Robin_Watts | The *new* one is fine, the *old* one is broken. | 15:16.18 |
| | I guess it's all just to do with where the clist buffer fills up. | 15:16.29 |
| | But honestly, I can't see where we're going wrong now :( | 15:16.47 |
| | I'm looking into a separate problem now, where bandheight changes make a significant difference to the output. | 15:18.15 |
| cryptopsy | pipitas: current page size isn't accurate | 15:18.32 |
| | pipitas: the only solution i know is to increase the size of the page, then use Translate | 15:19.07 |
| | wasn't able to implement it | 15:19.13 |
| ray_laptop | Robin_Watts: so does bug 692234 still fail as documented with HEAD (no patches ?) | 15:20.08 |
| | bug 693234 that is | 15:20.22 |
| Robin_Watts | Yes. That's the one I raised this morning. | 15:21.56 |
| ray_laptop | cryptopsy: how about you send a (small) sample input file, a clear description of what you want in the resulting PDF, and I'll have a quick look at it. | 15:22.05 |
| pipitas | cryptopsy: It's very easy if you know the current pagesize. F.e. let it be A4 portrait (595x842 pt) and add a 1 inch (72 pt) margin to the left and to the right, then just run: gs -o out.pdf -sDEVICE=pdfwrite -g6390x8420 -c "<</PageOffset [72 0]>> setpagedevice" -f input.pdf | 15:22.40 |
| ray_laptop | Robin_Watts: I thought I saw a coment in the logs that it only happens on 64-bit linux, but I don't see that in bug 693234 | 15:23.02 |
| pipitas | cryptopsy: it's a bit harder if you want the PostScript code to first examine the current pagesize... | 15:23.12 |
| ray_laptop | pipitas: the "BeginPage" proc is called after the PageSize is set, so it can adjust knowing the page size | 15:24.04 |
| cryptopsy | pipitas: ok write a command and try to add a 1" margin | 15:24.31 |
| | i wasn't able with HWMargin, PageSize and MarinLeft | 15:24.53 |
| | i don't remember the exact name of the last one | 15:25.01 |
| pipitas | cryptopsy: Did you try my command? | 15:25.12 |
| cryptopsy | i don't see it | 15:25.19 |
| ray_laptop | cryptopsy: I thought you also had a requirement to apply a different offset on left and right pages ? | 15:25.20 |
| cryptopsy | ray_laptop: i can run it one page at a time | 15:25.30 |
| ray_laptop | cryptopsy: that is a REALLY brute force way to do it, and also only works on input PDF files (gs doesn't support FirstPage LastPage on PS input) | 15:26.24 |
| Robin_Watts | ray_laptop: I can't reproduce it on windows. | 15:27.28 |
| ray_laptop | Robin_Watts: great :-( | 15:27.40 |
| Robin_Watts | I do say on the bug that it happens on peeves. | 15:27.42 |
| | The raster calculations are different on 64bit windows/linux. | 15:28.02 |
| ray_laptop | Robin_Watts: OK, I'll make sure I can reproduce it on peeves | 15:28.04 |
| Robin_Watts | hence the padding when writing bitmaps is different, and the clist fills up (probably) at a different point. | 15:28.30 |
| ray_laptop | kens: I have been struggling with a fairly simple patch to fix the fill_rectangle_hl_color usage and I am getting 1085 differences in pdfwrite | 15:29.04 |
| | kens: the thing is that I run the patched version on win 7 or on peeves and compare the PDF's (after pdfclean -d) and the only differences are in the metadata | 15:30.29 |
| | kens: and when I do the rendering that I _think_ the regression test does, they are identical | 15:30.55 |
| kens | ray_laptop : I'm not sure I can help you.... | 15:31.09 |
| pipitas | cryptopsy: I noted the command down roughly 9 minutes ago. Scroll up... | 15:31.12 |
| kens | As far as I know the cluster shoudl only show rendering dfiffs, the metadata isn't consulted | 15:31.34 |
| cryptopsy | oh i see it now | 15:31.35 |
| kens | ray_laptop : the cluster logs have the command line in there (I think) | 15:32.05 |
| cryptopsy | pipitas: how does -g get those values? | 15:32.08 |
| kens | ray_laptop : the command line is stored in the log files fro the cluster, so you should be able to replicate it | 15:33.26 |
| ray_laptop | kens: I'll try again being careful with the steps | 15:34.11 |
| kens | ray_laptop : I can look at it here if you send me the patch | 15:34.30 |
| ray_laptop | at least some of the PDF's are showing up on peeves, so it's not platform sensitive | 15:34.40 |
| pipitas | cryptopsy: Assumption was 595x842 pts. Add 72pts to each side and you get 739x842pts. That means -g7390x8420 (because the default resolution of pdfwrite is 720 dpi) | 15:34.49 |
| kens | ray_laptop : may not show up on a Windwos bos :) | 15:34.58 |
| cryptopsy | pipitas: it failed | 15:35.03 |
| | File:http://ompldr.org/vZXg4dw | 15:35.07 |
| pipitas | cryptopsy: I see I had a typo: it should be -g7390x8420 (for an originally A4 pagesize) | 15:35.31 |
| ray_laptop | kens: it's at the end of http://www.ghostscript.com/cgi-bin/clustermonitor.cgi?report=ray if you want to just look at it, but I can send you the patch | 15:35.43 |
| kens | ray_laptop : I'll take a peek | 15:36.09 |
| ray_laptop | kens: I can't get a difference on windoze (but then I'm not seeing a diff on linux, either) | 15:36.09 |
| kens | ray_laptop : did you do a bmpcmp ? | 15:36.37 |
| pipitas | cryptopsy: It works, I'm very sure. I use it quite frequently to crop pages or to add margins... | 15:37.01 |
| cryptopsy | pipitas: i just broke it for you | 15:37.15 |
| ray_laptop | kens: yes, but with an earlier version patch. I'll go ahead and update it now | 15:37.17 |
| cryptopsy | look at the screenshot | 15:37.19 |
| kens | ray_laptop : you'll have to wait until my run is done :) | 15:37.44 |
| ray_laptop | kens: they look like single pixel diffs (as if the rounding is different) | 15:37.50 |
| kens | ray_laptop : that may well be | 15:37.59 |
| | If we were previously emitting movee/line/line/line/line/closepath and are now emitting a 're' | 15:38.23 |
| | The path code does have optimisations for conerting to a rectangle, but its not 100% reliabel IMO | 15:39.01 |
| | In fact this seemed to be part of the isse for the customer henrys was referring to earlier | 15:39.24 |
| cryptopsy | pipitas: here's a broken with your updated -g | 15:39.25 |
| | File:http://ompldr.org/vZXg5Mw | 15:39.28 |
| pipitas | cryptopsy: No, you didn't break it. It did exactly what you told it to do. But you told it the wrong thing :-) I had a typo in the -g which should have been -g7390x8420 :) | 15:39.47 |
| ray_laptop | kens: I get calls from gs_rectfill into fill_rectangle_hl_color BOTH with the old and new code -- nothing I did affects when rectfill is called. | 15:40.14 |
| kens | Hmm, then I don't know ray_laptop | 15:40.27 |
| cryptopsy | i updated your fucking -g flag and it doens't produce the desired result | 15:40.28 |
| | you know, i didn't propose that solution, you did, i asked for a 1inch margin without cutting off my page, and you said 'ok i can do it' and here we are, my page is cut off | 15:40.52 |
| ray_laptop | kens: the main difference is that we were doing a 'fixed2float' from the fixed coordinates that came in -- now the coordinates come in as 'int' coordinates from gs_rectfill | 15:41.31 |
| kens | ray_laptop : that may mean that pdfwrite's rectangle heuristic works better on the path | 15:42.09 |
| | Perhaps | 15:42.15 |
| ray_laptop | kens: hmm... I just had a thought I wonder if pdfclean -d is truncating coordinates so the PDF's look the same | 15:42.16 |
| kens | Is that mupdfclean ? If so I don't think it does that | 15:42.41 |
| cryptopsy | pipitas: are you spanish? | 15:42.55 |
| ray_laptop | goes to use PDFDEBUG and try and compare the output | 15:42.57 |
| Robin_Watts | kens: pdfclean does do stuff like that. | 15:43.08 |
| kens | then I stand corrected, its always been OK for me | 15:43.24 |
| Robin_Watts | We parse the numbers in, then write them out again, in some cases. | 15:43.33 |
| pipitas | cryptopsy: first off â you should be a bit more polite, OK? I noticed already in the logs that you loose temper with people who are trying to help you solve YOUR problem. Second â you didn't tell me what was your original page size. Third â the links you posted don't show a PDF, but a JPEG. Fourth â provide a 3-page sample PDF and I'll add a 1inch margin left and right to each page for you. | 15:43.48 |
| Robin_Watts | and that can shift the representation slightly. or something. I remember this ,but I can't remember details. | 15:43.55 |
| ray_laptop | Robin_Watts: thanks -- that may show me what's up. | 15:44.15 |
| Robin_Watts | ray_laptop: It won't be stream contents; it'll be bounding boxes etc. | 15:44.40 |
| ray_laptop | Robin_Watts: what about clip paths ? | 15:45.38 |
| kens | clip paths are in stream contents | 15:45.48 |
| Robin_Watts | Xobject bounding boxes are dictionary entries though; they may be changed. | 15:46.19 |
| ray_laptop | Robin_Watts: rather than guess, I'm just going to look at the files | 15:46.20 |
| kens | The numbers I was thinking of were all stream contents, which is why (I guess) I never see thie pdfclean changes as a problem | 15:46.27 |
| | Hmm, my test code causes seg faults on *every* pdfwrite or ps2write test, not good. Its OK on WIndows, so I must have done something stupid | 15:47.46 |
| ray_laptop | kens: that's not related to my patch is it ? | 15:49.24 |
| kens | no, its mine | 15:49.35 |
| ray_laptop | kens: good (at least for me) | 15:49.54 |
| cryptopsy | pipitas: you get what you came for, in this case you decided to be talking out of your asshole, and then blame it on me - it is appropriate. Second -- i told you the original page size (in case you forgot, the page size is UNSPECIFIED). Third -- the links i posted show you the result of the scale operation. Fourth -- you're wasting your time, because any solution that is specific to the document is innappro | 15:50.04 |
| kens | ray_laptop : early steps in linearisation code, should have no effect on current code because its switched off, obviously something is wrong. | 15:50.41 |
| ray_laptop | cryptopsy: watch your tone and language ! | 15:50.42 |
| cryptopsy | pipitas: i didn't seek you out, so go figure | 15:50.55 |
| | ray_laptop: how many hours of abuse am i going to have to endure? | 15:51.10 |
| Robin_Watts | cryptopsy: None at all. Just leave, and your torment will be over. | 15:51.32 |
| cryptopsy | in most channels, misinformation carry a heavier penalty than few swear words | 15:51.36 |
| ray_laptop | cryptopsy: did you post links to your input file, and description of EXACTLY what all you want to achieve ? | 15:51.37 |
| cryptopsy | ray_laptop: yes, i described exactly what must be achieved | 15:51.56 |
| ray_laptop | cryptopsy: when ? today ? | 15:52.08 |
| cryptopsy | since this solution is independant of the input pdf, i'm not uploading 170pages | 15:52.13 |
| | ray_laptop: sooner than 30mins ago actually | 15:52.22 |
| ray_laptop | cryptopsy: no, earlier today I requested a small input file | 15:52.37 |
| | cryptopsy: I'll check the logs ... | 15:52.47 |
| cryptopsy | request all you want, the solution must be indepedant of pdf | 15:53.02 |
| | you might as well try it on any local pdf | 15:53.08 |
| pipitas | cryptopsy: Mind your words. I TOLD you 'let it be A4 page size' and gave you the command for THIS. I also TOLD you that "harder if you want the PostScript code to first examine the current pagesize" and I DIDN't give you a command for this. But the way you talk to other people who offer their help invites you to be put on the 'ignore' list, be aware of that... | 15:53.49 |
| ray_laptop | cryptopsy: just to confirm... your requirement is "the goal is to specify a margin padding without assuming pagesize or trying to guess pagesize for resize width sum calculation" | 15:53.59 |
| cryptopsy | pipitas: mind your solutions, i'm not gonna spend hours fighting you over incomplete/innapropriate solutions | 15:54.24 |
| | why are you even insisting | 15:54.33 |
| ray_laptop | cryptopsy: for help, send (or make avaialble) a small input file | 15:54.36 |
| cryptopsy | you don't have any local pdf's ? | 15:54.51 |
| | because if you don't, then i'll google the first pdf that comes up | 15:54.59 |
| pipitas | ray_laptop: your patience obviously is much bigger than mine... | 15:55.09 |
| ray_laptop | cryptopsy: If you want my help I REQUIRE one of your files !!!! | 15:55.10 |
| cryptopsy | catnet.stanford.edu/articles/Feralcats.pdf | 15:55.14 |
| | ray_laptop: use this one | 15:55.17 |
| henrys | cryptopsy:how are you using ghostscript? What is the application or service you are providing? | 15:55.47 |
| cryptopsy | henrys: i am using ghostscript and providing no service | 15:56.04 |
| ray_laptop | cryptopsy: and a COMPLETE description of your requirements... Please answer (1) Do you require different offset on even and odd pages ? (2) Do input pages need to be scaled to allow for the added margin ? | 15:56.36 |
| cryptopsy | ray_laptop: 1" margin (do you know what a margin is? it means adding material, not translating and leaving a 1" void -- that's NOT a margin) alternating pages in a universal solution that makes no assumptions | 15:57.39 |
| pipitas | and (3) do you have documents which contain mixed page sizes, mixed orientation (landscape/portrait) and mixed page rotations? | 15:57.50 |
| ray_laptop | cryptopsy: (3) IF the input page is to be scaled, should the input pagesize be scaled completely, or only the CropBox of the input (4) IF scaling, should it preserve aspect ratio OR scale only width ? | 15:57.52 |
| cryptopsy | pipitas: i am no longer reading what you write, just so you know | 15:58.09 |
| | ray_laptop: you can scale it if you want, if it can scale down it can be scaled up later, so it doesn't matter | 15:58.28 |
| | aspect ratio should be preserved, yes | 15:58.41 |
| pipitas | cryptopsy: I wasn't talking to you, wiseacre | 15:58.53 |
| cryptopsy | Please mind your words. | 15:59.14 |
| kens | Please do not feed the troll | 15:59.21 |
| henrys | I don't think cryptopsy should be helped at all. | 16:00.02 |
| kens | I stopped helping him on Friday | 16:00.15 |
| cryptopsy | that is entirely optional | 16:00.23 |
| pipitas | I start to understand now... | 16:01.18 |
| cryptopsy | whatever you've learnt today, it certainly isn't adding margins w/ ghostscrpit | 16:01.40 |
| ray_laptop | cryptopsy: you have been unresponsive, abusive and are minutes away from being bumped from this channel. pipitas and cryptopsy please take your discussion to a private chat | 16:03.01 |
| cryptopsy | ray_laptop: please don't encourage him to pm me | 16:03.19 |
| ray_laptop | pipitas: note that I am NOT proposing to bump you | 16:03.25 |
| cryptopsy | actually i think i have server-side ignore set, you may procede | 16:03.39 |
| ray_laptop | cryptopsy: IRC tools allow for the two of you to have a private chat to dsicuss your problem | 16:03.56 |
| | cryptopsy: but since you have NOT responded to my request for an input file, nor answered my questions, as an 'op' on this channel, I don't want you to solve your problem here | 16:05.20 |
| cryptopsy | ray_laptop: prove that i haven't responded | 16:05.53 |
| | i've answered your questions, but you don't hear me though | 16:06.11 |
| ray_laptop | has to go look up what the op commands are (trillian was the one that used to do it) | 16:06.24 |
| Robin_Watts | I believe: /kick cryptopsy | 16:06.59 |
| cryptopsy | Robin_Watts: total waste of time | 16:07.10 |
| | i guess it's appropriate since it's in the ghostscript hack style | 16:07.24 |
| pipitas | ray_laptop: I'm no longer having a private chat :) | 16:07.41 |
| cryptopsy | not sure what you're trying to do here (intimidate me?), you're wasting your time, esp pipitas contact me out of the blue, but then get offended when i'm pissed off i spend 1hr trying random commands, being intimidated to conforming to simple cases | 16:09.55 |
| | then the regular gs get cry out to champion the wrongs of my attitude, completely disregarding their purpose in GS project as providing solutions. in the end i'm temp-kicked because you got offended, and life goes on | 16:11.21 |
| henrys | just want to make sure Robin_Watts, ray_laptop, mvrhel_laptop and alexcher have an eye on the bug aging report, some of these have been lingering a long time ... maybe some qualify as enhancements. | 16:12.12 |
| | ^^^ mvrhel | 16:12.30 |
| Robin_Watts | henrys: 692870 is blocked on the bug you downgraded from blocker status earlier. | 16:14.05 |
| cryptopsy | i'd like to remark that it is completely lulzy when gs crybabies whine about me not reading chat, but propose solution pasted by myself within the time-frame of their alleged involvement in my charity case | 16:14.46 |
| kens | OK I'mm off goddnight folks | 16:16.16 |
| | Or even goodnight | 16:16.25 |
| henrys | Robin_Watts:got it. | 16:17.35 |
| ray_laptop | mvrhel: I have thousands of single pixel differences (on linux) with my patch for fill_rectangle_hl_color fixup, but on windows I don't see an differences. I've determined that these are rounding issues. | 16:53.21 |
| | mvrhel: the windows PDF is different to the linux output (both with and without the patch) -- even to having different scaling for the entire file. But all differences render at 300 dpi as single pixel diffs | 16:55.02 |
| | mvrhel: since it is really confused now I can (1) commit as is, OR (2) not change to 'int' coordinates, but just fix up the confusion -- What's your vote | 16:58.50 |
| | henrys: Robin_Watts: chrisl: (kens): alexcher: also please vote | 16:59.49 |
| | bbiab... | 17:00.56 |
| henrys | ray_laptop:and why can't it wait until after the release? | 17:01.03 |
| ray_laptop | BTW, my latest bmpcmp has shows the diffs. | 17:01.16 |
| Robin_Watts | On the strength of 0 and 1 in the bmpcmp alone, I say don't change to int :( | 17:02.38 |
| ray_laptop | henrys: it can. But it is really confused (broken) as is. There are many places that call with 'int' coordinates stuffed into the 'fixed_rect' but for the devices we test it doesn't show up | 17:02.50 |
| | Robin_Watts: of course, NEITHER output matches what 32-bit Windows produces (many MORE single pixel diffs) | 17:03.40 |
| Robin_Watts | ray_laptop: Do you have a 'correct' patch that causes fewer diffs? | 17:03.56 |
| ray_laptop | compared to EITHER output from 64-bit linux | 17:04.07 |
| | Robin_Watts: not currently -- but I _could_ do one. (I had it, but scrapped it) | 17:04.41 |
| Robin_Watts | If you can, I would go for a "correct, but with fewer diffs" patch. | 17:05.08 |
| ray_laptop | Robin_Watts: that amounts to approach (2) -- but I haven't done a regression on it | 17:05.15 |
| Robin_Watts | well, it's easy to try without losing your current work, with git, right ? | 17:05.38 |
| ray_laptop | Robin_Watts: that's the way I was leaning, but I wanted to know if the consensus might be "oh, what the heck -- just commit it" :-) | 17:06.07 |
| | so I'm going to do approach (2) and run a regression on it. | 17:06.56 |
| Robin_Watts | ray_laptop: I've got a stroke path here that gets written into the clist for multiple bands. | 17:33.59 |
| ray_laptop | Robin_Watts: OK -- isn't that a good thing ? | 17:34.19 |
| Robin_Watts | Is the representation within the clist identical for each band? | 17:34.19 |
| | or is the per band translation pickled into the path within the clist data? | 17:34.44 |
| ray_laptop | Robin_Watts: paths get munged for the band they are in to leave 'condense' information outside the band (iirc) | 17:34.57 |
| | s/leave // | 17:35.11 |
| Robin_Watts | OK, so it's a transformed/reduced path that gets written. | 17:35.44 |
| | The problem here is that the path overflows under transformation, so I'm seeing WierdAssShit(TM). | 17:36.18 |
| ray_laptop | Robin_Watts: but I _think_ it keeps the original coordinate system so that long edges don't end up with per band slope 'glitches' | 17:36.42 |
| Robin_Watts | ray_laptop: Yes, I don't think it 'truncates' segments. | 17:37.13 |
| ray_laptop | Robin_Watts: it's been a long time since I delved into that mess. If I were doing it, I would keep edges in pixel coordinates with an error term | 17:37.39 |
| Robin_Watts | It looks to me like all the data is going into the clist untransformed. | 17:45.32 |
| | but by the time I get the data into the stroke routine at the other end it's been vertically shifted. | 17:45.53 |
| | ok, the band stuff adds x0 and y0 to it as it decodes it. | 17:47.11 |
| mvrhel | Hi ray_laptop | 17:47.58 |
| | not sure I am following what the choices are above 1) or 2) | 17:48.19 |
| kens | ray_laptop : I'm concerned about the changes in your bmpcmp | 18:15.36 |
| | It looks like it might cause tiling gaps | 18:15.50 |
| ray_laptop | kens: I've agreed to do the approach (2) which is to keep the 'fixed_rect" in the call so that (in theory) the differences will disappear | 18:16.28 |
| kens | Ah, ok that obviously isn't in the logs yet, sorry | 18:16.47 |
| ray_laptop | kens: mvrhel: in process with those changes, should be able to test soon. | 18:17.00 |
| kens | will go away again | 18:17.00 |
| ray_laptop | kens: bye | 18:17.07 |
| Robin_Watts | mvrhel_laptop: I've pushed the change to make MAX_COMPONENTS 32 | 18:43.07 |
| ray_laptop | Robin_Watts: I just saw the bug about 'huge paths' | 18:43.11 |
| | Robin_Watts: I noticed that -- so it still has the bug 693234 I assume, but that's the only problem with 32 ? | 18:43.43 |
| Robin_Watts | ray_laptop: Yes. | 18:44.06 |
| | The huge paths bug is assigned to me as an enhancement. I can't think of how to fix it offhand, but at least I have the cutdown example file stashed somewhere. | 18:44.42 |
| ray_laptop | Robin_Watts: for the huge path issue, I think the best thing to do is to detect it and then fall back to the 'default' action (not high level path based) | 18:44.44 |
| Robin_Watts | could do. | 18:45.09 |
| | mvrhel_laptop: Many differences still left with MAX_COMPONENTS 64 - so I'll look into that next. | 18:46.01 |
| ray_laptop | Robin_Watts: the clist_fill_path does this if clist_disable_fill_path is set in the disable_mask | 18:46.44 |
| | Robin_Watts: I added comments to the bug | 18:49.58 |
| | the regression dashboard looks funny | 18:50.53 |
| Robin_Watts | The "ghostpdl" line ? | 18:51.36 |
| | It says that just before/after a job. Give it a mo. | 18:52.10 |
| ray_laptop | Robin_Watts: I've never noticed that before (at least for this long) | 18:52.31 |
| mvrhel_laptop | Robin_Watts: sounds good. | 18:57.41 |
| ray_laptop | keeps fingers crossed that this fix will resolve the >1000 diffs | 18:58.06 |
| | what the heck -- I get a compile fail due to gsromfs1.c having a stray character, but that isn't changed in my local version ??? | 19:13.35 |
| | henrys: I only get the compile error on your machine -- is henrysx6 OK ? (not disk full or anything) | 19:21.19 |
| | usually if I have a compile error it shows up for all machines | 19:23.00 |
| | must have been a glitch -- it's working this time | 19:31.44 |
| marcosw | Robin_Watts: have you had a chance to look at the WinRT issues with Ghostscript? | 20:21.10 |
| Robin_Watts | marcosw: Nope. | 20:26.16 |
| marcosw | okay, thx. | 20:26.26 |
| Robin_Watts | and I wasn't planning to in the next couple of days. | 20:26.51 |
| marcosw | I've let the potential customer know that it will be a while because of the upcoming release. | 20:39.44 |
| Guest31003 | Hi Guys, Shelly here, anyone still online that I can talk to about the cluster push script? | 21:31.24 |
| Robin_Watts | Damn. Missed Shelly. | 21:58.49 |
| d3c | just reported what I'm not sure is a bug but would be nice if someone would have a look at it anyway: http://bugs.ghostscript.com/show_bug.cgi?id=693236 - thanks | 22:21.43 |
| Robin_Watts | marcosw: Shelly is asking what files an svg test runs. | 22:40.49 |
| | Looking at the cluster.git stuff, I reckon the answer is "none at all". | 22:41.03 |
| marcosw | Robin_Watts: that's correct, SVG isn't tested by the cluster. It was at one point, but I disabled it for lack of interested in GhostSVG. | 22:42.02 |
| Robin_Watts | marcosw: OK, thanks. | 22:42.52 |
| | marcosw: More camera equipment incoming, I'm afraid. | 22:43.04 |
| marcosw | something arrived the other day, a padded envelope from butterfly photo | 22:44.21 |
| | Forward 1 day (to 2012/07/31)>>> | |
IRC Logs