| | <<<Back 1 day (to 2011/08/02) | 2011/08/03 |
| malc_ | tor8: time to go, bye | 00:04.07 |
| Robin_Watts | Morning chrisl | 09:50.37 |
| chrisl | Hi Robin_Watts | 09:50.49 |
| Robin_Watts | waves a magic wand he borrowed from #bugzilla over casper. | 12:41.05 |
| sebras | Robin_Watts: it's been upgraded? | 13:20.04 |
| Robin_Watts | no, I just applied a little hack. | 13:20.18 |
| henrys | sigh, bugzilla shouldn't be a help forum I wonder if we can customize bugzilla's new bug template to show what shouldn't be reported and kick them off to stack overflow or something. | 15:07.57 |
| Robin_Watts | henrys: Talking to one of the bugzilla guys this morning, he remarked that our bugzilla is getting long in the tooth (approaching EOL). | 15:11.43 |
| | Bugzilla 4.2 is due out soon, so it might be a good time to upgrade. | 15:12.02 |
| henrys | okay I'll add that to a list somewhere | 15:15.25 |
| Robin_Watts | Git hashes in bugzilla reports are now displayed as links. | 15:17.07 |
| | mupdf bugs point to ghostpdl sadly, but what can you do...? | 15:17.33 |
| henrys | oh cool - If I copy paste a web git mupdf link will it screw it up? | 15:20.16 |
| Robin_Watts | No. links that are links stay as links. | 15:20.32 |
| | but if it just sees a string of hex, it has no way of knowing if it's a ghostpdl or a mupdf link, so it guesses at ghostpdl. | 15:20.56 |
| chrisl | Robin_Watts: You don't have access to the "Product" setting at that point, then | 15:21.38 |
| Robin_Watts | chrisl: It's in a perl module that implements a 'quoteUrls' filter. | 15:22.02 |
| | I don't have access to anything other than the stream, AFAIK. | 15:22.11 |
| henrys | right - I'm already in the habit of copy pasting the links so I'm inclined to continue - presumably you'll have the same problems with all 3rd party stuff jbig2dec, openjpeg - etc. Not sure if this is a feature we really want. | 15:22.21 |
| chrisl | Robin_Watts: hmm shame. Still, an improvement | 15:22.52 |
| henrys | hopefully this bugzilla upgrade will be easier than the last. | 15:26.49 |
| chrisl | henrys: did you get anywhere with (or even get a chance to look at) the cups crash? | 15:39.10 |
| henrys | so tkamppeter_'s bug is the cups reallocation stuff like 690435 that was never really followed up on. We've got to get to the bottom of these things and not say something fixed it and close the bug. | 15:39.15 |
| chrisl | henrys: I think I know what the problem is - and it may relate to the previous problem, dunno...... | 15:39.51 |
| | The cups device is a real mess, to be honest :-( | 15:40.42 |
| henrys | yup is he around? | 15:40.53 |
| chrisl | Don' t know - I *literally* just stumbled on what I think is the problem a few minutes ago! | 15:41.35 |
| henrys | oh you probably have something more specific than I do, I just sustpect the resize in put params isn't sync'd or isn't done for some reason. | 15:42.27 |
| chrisl | That's pretty much it, yes, I have a fix, too. | 15:42.53 |
| | A very simple fix :-) | 15:43.00 |
| henrys | you are miles ahead of me. | 15:43.11 |
| chrisl | Well, leave it with me then. What I found is *definitely* wrong, so I'm optimistic it is the problem. | 15:43.39 |
| henrys | great. | 15:43.51 |
| chrisl | devcups calls gdev_prn_put_params() which gets the media size, and eventually sets up the raster memory. *After* that, devcups does it's own paper size matching (yuck!), and then calls gdev_prn_maybe_realloc_memory(), but it hasn't revised the existing with and height settings for the device, we so don't act on the new raster settings, but the device has new width and height setting - and bang! | 15:46.26 |
| Robin_Watts | henrys: Did you get a chance to try the memento squeezing stuff ? | 15:51.24 |
| henrys | okay that does seem odd since no paper size changes would ever work - well a change to a smaller size might not result in a memory violation. | 15:51.25 |
| | Robin_Watts:not yet should be today sometime. | 15:51.55 |
| chrisl | henrys: I know, I can only assume that the cups paper size almost always matches the Postscript one, but not in this case. | 15:52.42 |
| | yay! I'm going to clusterpush this, just as a precaution - both the "full" command line, and the short one in the bug report both run to completion | 15:52.52 |
| henrys | great news | 15:53.12 |
| Robin_Watts | chrisl: That's awesome. That had all the makings of a really nasty bug that we could have been hunting for for ages. | 15:53.41 |
| chrisl | Cheers! I love to enjoy a bit of glory - but relief is about all I can manage right now ;-) | 15:54.30 |
| | Fingers crossed for the clusterpush....... | 15:59.12 |
| | I need to run an errand - bbiab....... | 16:03.59 |
| | tkamppeter: Bug 692393 is fixed. | 16:57.06 |
| tkamppeter | chrisl, great, thank you. | 16:57.57 |
| chrisl | tkamppeter: I'm wondering if it could be related to 691586 as well, I'm just going to have a try at it | 16:58.49 |
| | tkamppeter: darn, Bug 691586 still crashes (with the interim fix you and Robin did removed) - ah well :-( | 17:02.10 |
| tkamppeter | chrisl, first confirmation of the fix, command lines in bug 692393 do not crash any more. | 17:09.17 |
| chrisl | tkamppeter: thanks. I did try them both, but it's good to have independent confirmation | 17:11.20 |
| tkamppeter | chrisl, henrys, I have another problem now: | 17:15.16 |
| | cat file.pdf | gs -dNOPAUSE -dBATCH -sDEVICE=cups -_ > x | 17:16.19 |
| | gives | 17:16.23 |
| | GPL Ghostscript GIT PRERELEASE 9.04: **** Could not open the file . | 17:16.35 |
| | GPL Ghostscript GIT PRERELEASE 9.04: Unrecoverable error, exit code 1 | 17:16.35 |
| | but | 17:16.38 |
| | cat file.pdf | gs -dNOPAUSE -dBATCH -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -_ > x | 17:17.05 |
| | works. | 17:17.12 |
| | Is "-sstdout=%stderr -sOutputFile=%stdout" required now in the command lines? Or is this a bug? | 17:17.32 |
| | chrisl, henrys ^^ | 17:17.44 |
| chrisl | tkamppeter: has gs -dNOPAUSE -dBATCH -sDEVICE=cups -_ > x ever worked? I get the same error from 8.71..... | 17:19.19 |
| | tkamppeter: from the docs "-" and "-_" only affect *input* (read from stdin), they have no effect on output. | 17:24.51 |
| tkamppeter | chrisl, then the first command line in bug 691586 is wromg. | 17:25.23 |
| | chrisl, and the short command line in bug 692393. | 17:26.08 |
| | chrisl, no I am wondering how they have once worked for me. | 17:26.29 |
| chrisl | tkamppeter: I can't answer that, but as I say, 8.71 shows the same behaviour, so it's not new. It may be for those bugs you never noticed the problem, because GS crashes before the error arises. | 17:28.02 |
| tkamppeter | chrisl, that can be the case. All real-live command lines seem to have at least "-sOutputFile=...". | 17:28.54 |
| chrisl | tkamppeter: generally, GS will only throw that kind of error when it's actually ready to emit the output, so unless it gets to the end of rendering (at least) the first page, you won't see it. | 17:30.03 |
| tkamppeter | chrisl, thanks, then I know why command lines without the "-sOutputFile=..." get into the crasher bug reports. | 17:31.00 |
| chrisl | tkamppeter: no problem. | 17:31.30 |
| tkamppeter | chrisl, I have also done a test on real iron now and the photos from digikam come out correctly again. Thank you very much for the quick fix. | 17:31.45 |
| chrisl | tkamppeter: I'm glad it worked. I must say, given what the problem was, I'm surprised it worked even slightly reliably - I'd have expected cases of corrupt output and crashes to be more common. | 17:33.18 |
| tkamppeter | chrisl, and I am glad that I succeeded in the years after the GS merger when Mike Sweet dropped maintaining gdevcups.c, to fix all the bugs, especiallyu crashers in that mess of code. | 17:38.38 |
| | chrisl, I even once suggested a rewrite of the device. | 17:39.20 |
| chrisl | tkamppeter: I could certainly say that, from a Ghostscript point of view, gdevcups.c is a poorly written device, but I think lack of time makes a full rewrite unlikely - however much we want it! | 17:39.59 |
| tkamppeter | chrisl, and so I continued patching this messy code, hoping that once it works completely reliably. | 17:41.01 |
| chrisl | tkamppeter: well, it can't be that bad, now, given how much it is used, but it would be good to get things like the media selection working "correctly" - right now, it does not follow Postscript rules. | 17:43.46 |
| | Okay, I am done for today - g'night, and may your god go with you...... :-) | 17:49.24 |
| Robin_Watts | night chrisl | 17:49.39 |
| | tor8: Aha! | 18:58.23 |
| | There's at least one patch waiting for you on casper | 18:58.38 |
| tor8 | evening! | 18:58.49 |
| Robin_Watts | I'm in clipping/blending/softmasking hell :( | 18:59.08 |
| | evening :) | 18:59.10 |
| | Do you know the hivemind file ? | 18:59.40 |
| tor8 | Robin_Watts: 3 patches pushed | 19:01.48 |
| Robin_Watts | tor8: Thanks. | 19:01.54 |
| tor8 | hivemind? no, can't say that it rings any bells. | 19:01.59 |
| Robin_Watts | It uses nested groups and softmasks. | 19:02.45 |
| | Just had a thought... | 19:03.00 |
| | Tile stuff; do we render a tile once and then blend it back several times? | 19:03.23 |
| | or do we run the commands that make up a tile several times ? | 19:03.43 |
| tor8 | render once and blend several times | 19:04.18 |
| | controlled by an #ifdef | 19:04.44 |
| Robin_Watts | right. so that's going to go wrong with non-isolated groups | 19:05.03 |
| | eh? where's the ifdef ? | 19:05.13 |
| tor8 | #define TILE at the top of pdf_interpret.c | 19:05.32 |
| Robin_Watts | oh, so we have code that works both ways ? | 19:06.02 |
| tor8 | yes. the non-tiled way doesn't invoke the begintile/endtile functions, and interprets the xobject multiple times instead | 19:06.39 |
| | if that would make the transparency case easier, go ahead and make it a runtime choice | 19:07.13 |
| Robin_Watts | I think that's in the wrong place. | 19:07.27 |
| | (in the wrong place for me to use it) | 19:07.35 |
| | Let's think about this... if a tile contains any non-isolated groups, we can't just render it once and then play it back many times. | 19:25.56 |
| | but we don't know whether a tile has non-isolated groups until we start to execute it. | 19:26.15 |
| | We could make the end_tile function return a bool, saying whether non-isolated groups were encountered or not. | 19:27.33 |
| | That way the pdf_interpret code could start to do the 'do it once then blend many times' way, but might get forestalled and just be able to blend it back once. Then it'd have to do the rest by steam. | 19:28.59 |
| | And in the 'list' case, we can keep the flag internal, so we only ever end up putting one copy of the commands in the list. | 19:30.10 |
| | but the list playback code would have to be smart enough to replay the commands into the tile many times. | 19:30.41 |
| | so the begin_tile would need to take the number of x and y repeats etc. | 19:30.59 |
| tor8 | wouldn't an isolated tile that contains other transparency groups with non-isolated blending work as expected as is? | 19:44.56 |
| | and a tile with a non-isolated group, that we can test for | 19:45.23 |
| Robin_Watts | tor8: yes. | 19:45.51 |
| | oh, right, I think I see. | 19:46.03 |
| | I was planning to ignore the problem for now :) | 19:46.33 |
| | until we find a file that shows it. | 19:46.40 |
| tor8 | works for me :) | 19:47.55 |
| | hopefully nobody is insane enough to create a tiling pattern using non-isolated transparency groups | 19:48.14 |
| | and if they are, we should be safe enough by just disabling the begin/endtile calls for that case | 19:48.33 |
| Robin_Watts | yeah. | 19:48.47 |
| pipitas | Hi, all. I'm more curious about the development roadmap for MuPDF since since I read in some IRC log about a thing you called "mupdf/ghostscript bridge". What's the idea behind this? | 19:56.13 |
| Robin_Watts | pipitas: Ghostscripr rendering, but with mupdf parsing. | 19:57.07 |
| | hence no need to implement all the PDF parsing in postscript. | 19:57.27 |
| pipitas | Robin_Watts: I thought Ghostscript had nearly all of PDF parsing already in place? (And covering more ground than MuPDF currently?) Or is it because of performance issues of PostScript vs. C++? | 20:00.04 |
| Robin_Watts | pipitas: C is much easier to maintain. | 20:00.36 |
| | And develop. | 20:00.43 |
| | and it's faster. | 20:00.49 |
| pipitas | I see. | 20:01.11 |
| Robin_Watts | MuPDF falls behind gs in its rendering, not it's parsing capabilities. | 20:01.18 |
| pipitas | Ah, ok. | 20:02.06 |
| | Forward 1 day (to 2011/08/04)>>> | |
IRC Logs