| | <<<Back 1 day (to 2015/03/22) | 20150323 |
| kens | chrisl would you mind trying bug #695881 on a 64-bit Linux please ? | 09:42.04 |
| | Actually, what the heck is 'gsc' ? | 09:43.06 |
| tor8 | kens: google summer of code? | 09:54.11 |
| kens | You mean gsc ? :-) | 09:54.48 |
| tor8 | kens: yeah. | 09:54.55 |
| kens | Ah no, its 'gs' | 09:55.03 |
| | Except that on ArchLinux they seem to be calling it gsc. I *think* I've seen that before, but I can't recall where | 09:55.21 |
| tor8 | kens: oh... | 09:55.29 |
| kens | In any event I can't reproduce a crash, which is why I was asking chris to have a go on 64-bit Linux, but it';ll have to wait until he comes back. | 09:56.09 |
| Robin_Watts | tor8: So, the latest version on robin/merge_csi is dying with too many timeouts. | 09:57.06 |
| | I've got to look at a customer SOT thing for a few hours then I'll get back to it. | 09:58.16 |
| tor8 | I'm not happy with passing resources to all the functions | 10:00.54 |
| | no I'm going to try fixing it another way while you're banging on SOT then :) | 10:01.11 |
| | s/no/so/ | 10:01.17 |
| Robin_Watts | tor8: ok. | 10:03.57 |
| | My branch has more fixes in too. | 10:04.11 |
| tor8 | in the same 'fix' commit? | 10:04.24 |
| Robin_Watts | no. | 10:05.16 |
| | we can figure them out and pull them over later though. | 10:05.45 |
| | We could push the printf commit from robin/merge_csi though. | 10:06.29 |
| | I had to rework it slightly to avoid loads of warnings from the unix build (cos of the "printf_line" format checking) | 10:07.12 |
| | s/line/like/ | 10:07.27 |
| tor8 | Robin_Watts: okay. | 10:07.56 |
| Robin_Watts | tor8: What do you have in mind to avoid the passing of the pdf_resources ? | 10:26.46 |
| tor8 | Robin_Watts: top commit on tor/csi, or something along that line | 10:27.10 |
| Robin_Watts | oh, it wasn't the passing of resources that broke it. It was my attempted smask fix. hmm. | 10:27.40 |
| | Can that be right? bah. will look later. | 10:28.38 |
| tor8 | Robin_Watts: oh, the path fix you found is that merged in with the resource passing? | 10:28.58 |
| Robin_Watts | I don't believe the approach taken in tor/csi will work. | 10:29.31 |
| | Consider a page with 2 xobjects on. | 10:29.43 |
| | A and B. | 10:29.51 |
| | each of those X objects calls another xobject C. | 10:30.04 |
| | C calls an xobject D. | 10:30.14 |
| | C has no resources. | 10:30.27 |
| | object D is defined (differently) in A and B. | 10:30.37 |
| tor8 | Robin_Watts: yes. that's the case I've been worrying about. | 10:31.05 |
| | trying to run it on the cluster test to see if we actually have any such files | 10:31.15 |
| Robin_Watts | tor8: You could possibly fix that by setting xobj->resources, and then unsetting it afterwards ? | 10:31.26 |
| tor8 | I'd argue that they're pretty much broken. an XObject *should* have its own resource dictionary. | 10:31.28 |
| Robin_Watts | tor8: According to later versions of the spec, yes. | 10:31.42 |
| tor8 | Robin_Watts: I thought about adding a xobj->inherited_resources field for this | 10:31.47 |
| | but then you run into potential multi-threading issues | 10:31.58 |
| Robin_Watts | tor8: We only interpret in a single thread, so we're safe from that point of view. | 10:32.14 |
| tor8 | setting it at first use, and hoping that nothing breaks is what I'm hoping I can do :) | 10:32.22 |
| Robin_Watts | tor8: That feels bad. | 10:32.32 |
| tor8 | right. then that would work. | 10:32.39 |
| | the spec is bad. it should feel bad :) | 10:33.03 |
| Robin_Watts | much better to set xobj->resources on entry, then process the xobject, then remember that it was set and clear it, IMHO. | 10:33.15 |
| tor8 | but I need to extract the other fixes you did from your commit | 10:33.19 |
| | I'm not sure it's going to be that simple | 10:33.36 |
| | do we handle recursive XObjects at all? | 10:33.51 |
| Robin_Watts | We do. | 10:34.37 |
| tor8 | hopefully not, but that's a case that would break. but break more than one thing. | 10:34.38 |
| | so we bail? | 10:34.44 |
| Robin_Watts | No, we correctly handle them. | 10:34.51 |
| | I went to some pains to make sure we did it right, cos ken had an example file :) | 10:35.05 |
| tor8 | an xobject that calls itself (directly, or indirectly) is what I'm asking about | 10:35.07 |
| Robin_Watts | right. | 10:35.12 |
| | and that can even be legal. | 10:35.18 |
| | patterns etc. | 10:35.44 |
| | That would break the xobject->resources setting idea. | 10:35.52 |
| | In pdf_run_w, you need gstate = pdf_flush_text(ctx, pr); | 10:36.32 |
| tor8 | last resort idea: for softmasks, pass the resources only in the op_gs_SMask call | 10:36.33 |
| | for forms, pass it in Do_form | 10:36.39 |
| Robin_Watts | We need it for any operation that might set a softmask or start a group. | 10:37.09 |
| | (or flush the text) | 10:37.26 |
| | hence I decided it was easier to just pass it everywhere. | 10:37.34 |
| tor8 | save the resource object along with the SMask in the gstate->softmask struct | 10:37.59 |
| Robin_Watts | except the gstate stuff is specific to pdf_op_run, not all pdf_processors, right? | 10:38.28 |
| | and for processors that pass through, we'd always need to check if the resources have changed and pass them through too, right? | 10:39.10 |
| tor8 | a softmask / xobject form needs two things from the interpreter: itself, and the inherited resources if it's missing its own | 10:39.12 |
| | a softmask is only applied on every graphics operation in the same stream | 10:39.57 |
| Robin_Watts | op_s and op_F call op_S and op_f respectively. | 10:40.17 |
| tor8 | so the resources would never change for one softmask, on the same page | 10:40.34 |
| | same page or xobject | 10:40.47 |
| | run_w or run_W? | 10:40.57 |
| Robin_Watts | _w | 10:41.12 |
| | line width setting. | 10:41.17 |
| | Otherwise stroked fonts can unexpectedly change width. | 10:41.29 |
| tor8 | then we should flush text for *all* stroking changes as well, no? | 10:41.57 |
| Robin_Watts | (you could only flush if you're in a stroked font rendering mode, but...) | 10:41.58 |
| | tor8: probably. | 10:42.12 |
| | (I did originally, I think) | 10:42.21 |
| tor8 | nope, no flushing for miterlimits etc in the original code | 10:43.10 |
| Robin_Watts | ooh, that's bad. | 10:43.30 |
| tor8 | I'm thinking it's probably best to flush on most graphics state changes | 10:45.19 |
| Robin_Watts | tor8: I am very tempted by a PDFFlushTextIfInStrokedRenderMode function. | 10:46.02 |
| | (bah, my head is in SOT function name style :) ) | 10:46.12 |
| | tor8: The trick is to flush exactly when we have to :) | 10:46.37 |
| tor8 | the flushing is tricky, I think I need to work through all the examples properly | 10:46.59 |
| | flushing with an empty text buffer is not a problem | 10:47.19 |
| | and flushing when irrelevant state changes shouldn't be a problem in reality | 10:47.36 |
| | since hopefully a creator won't be changing irrelevant state in the middle of a text object | 10:47.50 |
| Robin_Watts | Yeah, cos PDF generators are always well written and sane. | 10:48.22 |
| tor8 | yeah yeah, point taken :) | 10:49.53 |
| | Robin_Watts: my bmpcmp, #6 through #17 look like unrelated progressions | 12:24.31 |
| Robin_Watts | Yes. | 12:25.30 |
| | Probably related to flushing at the correct point? | 12:25.38 |
| tor8 | doesn't seem to be affected by the flushing of stroking state commit :/ | 12:27.26 |
| | 18 | 12:28.14 |
| | 18-23 I don't understand | 12:28.24 |
| | evince, gs, and mupdf get it all different | 12:28.57 |
| | gs has a dark orange outline | 12:29.02 |
| | evince has no outline | 12:29.04 |
| | and old mupdf has no outline, and the csi branch has a white outline | 12:29.28 |
| | 24-31 look like noise | 12:29.49 |
| Robin_Watts | yeah, 18 I saw on my merged branch but hadn't got round to looking at yet. | 12:30.10 |
| tor8 | 53 looks bad :( | 12:30.26 |
| Robin_Watts | mmm | 12:31.11 |
| tor8 | but it's a seriously broken file | 12:31.57 |
| | zlib errors and garbage content streams | 12:32.21 |
| | the difference could be that we don't bail at the same locations | 12:33.05 |
| Robin_Watts | could be, but it would be nice to be sure. | 12:33.25 |
| | oh, wait... there was one more fix... | 12:33.38 |
| | after the 'unknown keyword' warning, you return 0. | 12:33.56 |
| tor8 | 65? | 12:33.57 |
| Robin_Watts | the old code returned 1. | 12:34.01 |
| | In pdf_process_keyword | 12:34.28 |
| | if (!csi->xbalance) .... | 12:34.37 |
| tor8 | oh, yeah. that fixes 53 | 12:34.40 |
| chrisl | kens: unfortunately, me trying 695881 won't tell us much, as my Ubuntu doesn't seem to have the glibc/pthreads updates that expose the problem. But I'll post on the bug, since it is virtually certain to be the same issue | 12:34.50 |
| Robin_Watts | That fixed another one too. | 12:34.51 |
| tor8 | I suspect I left that as return 0 so I could find unimplemented keywords during my rework :) | 12:35.02 |
| Robin_Watts | sorry, should have kept all these separate :( | 12:35.04 |
| tor8 | mmm, that fixes #65 as well | 12:36.43 |
| | Robin_Watts: #76 looks like a progression to me! | 12:39.09 |
| | and locally it makes no difference whether I use inherit_resources style, or just setting to the first resource dictionary used | 12:39.39 |
| Robin_Watts | kens: Do you have your patterns torture test file to hand? | 12:40.24 |
| | I think tor8 should look at that :) | 12:40.33 |
| tor8 | Robin_Watts: new commits on tor/csi | 12:41.01 |
| | including two variants of handling xobject resources | 12:41.08 |
| | the first variant is cluster testing now | 12:41.18 |
| Robin_Watts | tor8: Right. I've looked at all these before, I think, except for the last couple. | 12:43.20 |
| tor8 | yes. these are all the fixes you've mentioned and the old stuff you've already reviewed. | 12:43.53 |
| Robin_Watts | We should fix the remaining problems, then squash 'em all. | 12:43.54 |
| tor8 | yup. | 12:44.08 |
| Robin_Watts | assuming we can find a nice way to fix the remaining problems (some of which are smask related) | 12:44.20 |
| tor8 | and decide which of the xobj res commits to use | 12:44.20 |
| Robin_Watts | Let me look for the pattern torture test file. | 12:44.54 |
| tor8 | I suspect the second one, since that should cope with your case of A, B -> C (missing resources) | 12:44.56 |
| Robin_Watts | tor8: OK, see patterns.pdf in my casper home dir. | 12:45.40 |
| | (We need to keep the file private) | 12:45.47 |
| tor8 | Robin_Watts: hm, page 2 looks wrong | 12:49.31 |
| Robin_Watts | can almost hear the sounds of retching that will be forthcoming from Sweden when tor starts reading the file... | 12:50.11 |
| | It must have been created an impressively warped mind | 12:50.44 |
| | chrisl: Ever heard of 'Government Mule' ? | 12:52.36 |
| chrisl | Robin_Watts: Nope.... Should I have? | 12:53.24 |
| Robin_Watts | They were originally a spinoff from the Allman Brothers, but have developed a following of their own. | 12:53.50 |
| chrisl | Any good? | 12:53.59 |
| Robin_Watts | I've just got 'Dark Side Of The Mule'. | 12:54.00 |
| | I'm enjoying disk 1 :) | 12:54.18 |
| chrisl | I'll youtube them...... | 12:55.33 |
| Robin_Watts | You are welcome to a loan if you like 'em. | 12:56.35 |
| chrisl | They seem more bluesy than the Allman Bros | 12:58.24 |
| Robin_Watts | mmm | 12:58.46 |
| chrisl | The Allman Bros stuff I always felt they moved away from blues as time went on. | 13:00.29 |
| Robin_Watts | I don't know any AB stuff except Brothers and Sisters. | 13:00.53 |
| chrisl | Well, for (obvious) example, there's not a lot of blues influence in Jessica...... | 13:01.43 |
| Robin_Watts | indeed. But one datapoint doesn't give me much to chart a progression by :) | 13:03.12 |
| tor8 | Robin_Watts: so... with inherited_resources SoftMaskGroup.pdf comes out wrong | 13:05.04 |
| | but fixing an xobject to the first resource dictionary when it's used comes out right | 13:05.23 |
| | and oddly enough, the old code also comes out right | 13:05.54 |
| Robin_Watts | really? I would not have expected that. | 13:05.55 |
| tor8 | this is breaking my mind | 13:06.00 |
| Robin_Watts | mmm. | 13:06.03 |
| tor8 | yeah, something weird is going on. the 2 other files that differ between the approaches have the same issue... it can't find the sub-resources | 13:07.38 |
| | or maybe I'm not using the inherited_resources in all the places it should be | 13:07.56 |
| chrisl | Does mupdf evaluate soft mask groups lazily? | 13:08.07 |
| tor8 | chrisl: yes. | 13:08.25 |
| chrisl | And holds the entire gstate for use on evaluation? | 13:08.45 |
| tor8 | chrisl: yes, IIRC | 13:08.55 |
| chrisl | It's rare that the group doesn't set an ExtGstate explicitly, but does happen.... | 13:09.49 |
| kens | chrisl I'm pretty certain its the same bug, but when I asked that wasn't obvious, it was before he posted the gdb back trace | 13:13.01 |
| chrisl | kens: Yeh - I think we can expect a few more of these to appear, unfortunately :-( | 13:13.51 |
| kens | I expect so, yes. :-(( | 13:14.06 |
| | chrisl sorry about this, but can you comment on #695880 ? | 13:15.07 |
| chrisl | kens: done | 13:17.12 |
| kens | Thanks | 13:17.32 |
| | ah, user error :-) | 13:18.04 |
| chrisl | Well, I'd have thought it *fairly* obvious that if you want Ghostscript, you'd download the file called 'ghostscript....'! | 13:18.54 |
| kens | You would think so, yes. DO we care about #695882 ? | 13:19.12 |
| | Its a combination of an old copiler and a build policy I think. | 13:19.39 |
| chrisl | The pread/pwrite thing ain't my problem! | 13:20.17 |
| kens | Fair enough | 13:20.48 |
| chrisl | Well, I would say if the functions we need for threading aren't there, they should disable threading | 13:22.06 |
| kens | That would seem reasonable, yes :-) | 13:22.15 |
| chrisl | I guess the question is, should configure check for it.... <sigh> | 13:23.46 |
| kens | :-( | 13:23.58 |
| Robin_Watts | tor8: is this a case of an smask being set as part of gstate? | 13:41.33 |
| chrisl | <sigh> really not in the mood to deal with an enthusiastic maintainer right now :-( | 13:44.40 |
| henrys | late start today, have a doctor's appointment | 13:48.45 |
| | answers to all your standing desk questions: http://www.newyorker.com/humor/daily-shouts/switched-standing-desk-now | 13:49.38 |
| Robin_Watts | henrys: hehe | 14:31.08 |
| tor8 | Robin_Watts: okay, I've found the smask problem | 15:34.47 |
| | silly mistake when extracting the blendmode from the ExtGState dictionary | 15:35.04 |
| Robin_Watts | tor8: excellent. | 15:36.47 |
| | So what's the state of play with the tests then? | 15:37.01 |
| tor8 | clusterpushing now | 15:37.11 |
| Robin_Watts | pops to post office then while my tests run too. | 15:37.28 |
| tor8 | pattern.pdf looks like it should just by visual comparison | 15:37.28 |
| Robin_Watts | tor8: This is using inheritance, or using set when first used? | 15:47.09 |
| tor8 | set when first used | 15:52.32 |
| Robin_Watts | Given the choice, I would prefer inheritance. I think that's more in keeping with what we had before. | 15:53.07 |
| tor8 | yeah. going to try to figure out why it doesn't work first though :/ | 15:53.27 |
| Robin_Watts | ah, fair enough :) | 15:53.36 |
| tor8 | down to changes in 7 files is encouraging though :) | 15:53.54 |
| Robin_Watts | 7 is a much more reasonable number. | 15:54.26 |
| | Of course, I've just found 3 separate bugs in SOTs PDF handling in a single pdf file from a customer :) | 15:54.45 |
| kens | I saw that, tested the file with GS and it seeems OK | 15:55.11 |
| tor8 | Robin_Watts: now you're going to get royally confused, if you start trying to keep 3 pdf interpreters in your head at once ;) | 15:55.39 |
| | Robin_Watts: looking at my bmpcmp, I'd say the 7 differences are pixel noise and one progression (19-24) | 15:57.19 |
| Robin_Watts | tor8: I concur. | 16:02.27 |
| tor8 | Robin_Watts: d'oh! | 16:04.13 |
| | when inheriting resources, we reset the inherit_resource field too early | 16:04.32 |
| | for soft masks | 16:04.37 |
| | Robin_Watts: so, the page-resources commit on the tip of tor/csi makes zero difference on the cluster | 16:14.11 |
| | I'm okay with either solution, but I suspect you feel it's a better solution than just hardwiring the resource dictionary on first use | 16:14.58 |
| chrisl | Good grief, SPARC is a PITA - no wonder Sun struggled :-( | 16:27.27 |
| mvrhel_laptop | kens: are you here? | 16:35.46 |
| kens | yEP | 16:35.57 |
| mvrhel_laptop | I was just wondering if you had a gsprint64.dll in you gsview6.0/bin directory | 16:37.14 |
| kens | Let me go look | 16:37.22 |
| mvrhel_laptop | s/you/your/ | 16:37.23 |
| | hoping to get a new version of gsview up in a day or two and need to figure out why you can't print | 16:38.02 |
| kens | WHat's the path ? | 16:38.10 |
| mvrhel_laptop | Program Files | 16:38.16 |
| | Artifex Software | 16:38.21 |
| kens | Yes, and then ? | 16:38.21 |
| | Ah | 16:38.24 |
| | Yes I have gsprint64.dll i the folder | 16:38.43 |
| | I thought my printing problemwas on the Mac, I'mnot sure I tried WIndows did I? | 16:39.00 |
| | Let me try that now | 16:39.06 |
| mvrhel_laptop | oh | 16:39.07 |
| kens | Ah no that doesn't work | 16:39.59 |
| | DLLNotFoundException: gsprint DLL not found | 16:40.13 |
| mvrhel_laptop | odd. ok I will clean up my machine and try a clean install to see if I can replicate the issue. also I will try on windows 7 | 16:40.50 |
| kens | OK its WIndows 7 64-bit Professional I'm using | 16:41.04 |
| mvrhel_laptop | ok. I think my win7 machine is 32 bit. but that will be a good test too | 16:41.27 |
| kens | Certainly will yes | 16:41.36 |
| fredross-perry | OK, 32-bit Linux installer for gsview: http://www.ghostscript.com/~fred/gsview/linux/GSView-6.0-Installer-32 | 17:09.47 |
| Robin_Watts | tor8: back. | 17:18.49 |
| | tor8: Nothing on tor8/csi appears to use inheriting resources... ? | 17:21.37 |
| BenBB | Hey. Anyone here? | 18:24.38 |
| | Using Docsplit and getting an error with Ghostscript | 18:25.23 |
| | http://pastebin.com/GT7fQNTT | 18:25.24 |
| | Can anyone decipher what's going on here? Works okay on another machine. | 18:25.35 |
| Robin_Watts | Same version of ghostscript on both machines? | 18:26.16 |
| BenBB | The other machine has 9.07/9.08 I think | 18:26.42 |
| Robin_Watts | In order for us to be able to help you, you need to first test with the latest version. | 18:27.06 |
| | Then you need to give us the ghostscript command you are calling, with the file you are calling it on. | 18:27.21 |
| BenBB | This machine has 9.15 | 18:27.59 |
| | I assume the command being called is | 18:28.31 |
| | "gs" "-q" "-dBATCH" "-dMaxBitmap=50000000" "-dNOPAUSE" "-sDEVICE=ppmraw" "-dTextAlphaBits=4" "-dGraphicsAlphaBits=4" "-r150x150" "-dUseCropBox" "-dFirstPage=0" "-dLastPage=0" "-sOutputFile=/tmp/d20150323-39615-8v99kz/gmxMr7Y8" "--" "/tmp/d20150323-39615-8v99kz/gmvHxvoQ" "-c" "quit". | 18:28.32 |
| Robin_Watts | Indeed. | 18:28.37 |
| | It looks to me like /tmp/d20150323-39615-8v99kz/gmvHxvoQ contains the input postscript program. | 18:28.56 |
| | and it further looks to me like that program is part of DocSplit itself, because the first line of your paste is: | 18:29.16 |
| | Docsplit::ExtractionFailed (Error: /rangecheck in --run-- | 18:29.24 |
| | That looks like the code has spotted that something has gone wrong, and has thrown a rangecheck error. | 18:29.49 |
| | That's typically used by postscript operators when they are given an argument that is 'out of the permitted range'. | 18:30.12 |
| | Everything that then follows is just details of what's on the postscript stacks. | 18:30.26 |
| | It's not going to help us really. | 18:30.38 |
| | So, again, we'd need you to isolate the input file for us. | 18:30.58 |
| | Then if that same input file works on an old version and fails on a new version, that's a bug we should look into. | 18:31.30 |
| BenBB | Hmm.. files seem to be outputting correctly | 18:34.12 |
| | like PDF files | 18:34.22 |
| Robin_Watts | BenBB: presumably your problem is that you can't capture the file easily cos it's only created temporarily while you're calling Docsplit? | 18:38.08 |
| BenBB | It's through a Ruby gem. | 18:38.35 |
| | Thanks for the help by the way. | 18:38.50 |
| | Appreciated. | 18:38.54 |
| Robin_Watts | BenBB: You could temporarily replace the 'gs' exe with something that prints it's arguments to the screen, then starts a shell. | 18:39.16 |
| | Then you can copy the relavent file somewhere self. | 18:39.26 |
| | s/self/safe/ | 18:39.30 |
| BenBB | Thanks for the advice. I'm done for the day now. Have a nice day ;) | 18:46.41 |
| Robin_Watts | and you. | 18:46.49 |
| tor5 | Robin_Watts: the 'xobj res 2' commit | 19:53.37 |
| Robin_Watts | tor5: Yeah, sorry, being dim. | 19:54.54 |
| | If git will stop misbehaving here, I'll have a version ready to test with everything in. | 19:55.22 |
| | testing now. | 19:55.45 |
| | robin/merge_csi has everything in. | 19:56.02 |
| | tor8: I vaguely feel that for neatness we should: xobj->page_resources = NULL; at various points. | 19:57.46 |
| | Oh, hmm.... would setting xobj->page_resources = NULL after calling op_gs_SMask cause problems? | 19:58.16 |
| | cos the SMask is lazily evaluated? | 19:58.26 |
| | yeah, I think there is a pathological case we might get wrong here. | 20:04.18 |
| simon91 | Hi, | 21:18.12 |
| | anybody out there who likes to take a look at my little mupdf patch http://bugs.ghostscript.com/show_bug.cgi?id=695878 ? | 21:18.12 |
| Robin_Watts | simon91: We'll look at that if we get a mo before the release. | 21:20.20 |
| | Forward 1 day (to 2015/03/24)>>> | |
IRC Logs