| | <<<Back 1 day (to 2014/11/02) | 20141103 |
| melih | hi, sometimes I'm getting "an error occured when call to 'gsapi_init_with_args' is made: -100" how to fix it ? | 12:33.47 |
| Robin_Watts | melih: Gonna need more information than that for a start :( | 12:35.02 |
| melih | for same pdf file, sometimes process start successfully sometimes getting this error. everything same but I don't understand what is the problem | 12:36.04 |
| Robin_Watts | melih: What arguments are you passing? | 12:36.21 |
| | -100 is an e_Fatal error. Not the most helpful one... | 12:36.55 |
| melih | I'm passing pdf path and path of created by ghostscript | 12:38.30 |
| | http://i.imgur.com/wjQRLS4.jpg | 12:38.57 |
| | check error screenshot | 12:39.13 |
| | my code below | 12:39.29 |
| | public static void Export_Thumbnail_Png(string orginalfile, string thumbPath) { GhostscriptJpegDevice dev = new GhostscriptJpegDevice(GhostscriptJpegDeviceType.Jpeg); dev.GraphicsAlphaBits = GhostscriptImageDeviceAlphaBits.V_4; dev.TextAlphaBits = GhostscriptImageDeviceAlphaBits.V_4; dev.ResolutionXY = new GhostscriptImageDeviceResolution(32, 32); dev.JpegQuali | 12:39.31 |
| Robin_Watts | melih: OK, so you're using Ghostscript.net | 12:39.37 |
| melih | yes | 12:39.51 |
| Robin_Watts | We can't really help you with Ghostscript.net problems, as we're not set up for that here. | 12:40.04 |
| | If you can reproduce the problem with normal ghostscript, we will be better placed to try to help you. | 12:40.26 |
| | I have no idea what happens between your call to Ghostscript.net and the actual call that arrives within gs. | 12:41.09 |
| melih | OK thanks for attention | 12:41.44 |
| Robin_Watts | It could easily be a problem with ghostscript.net passing in an invalid path or something, and no amount of hunting within gs will get us the answer. | 12:42.02 |
| | Sorry. | 12:42.12 |
| kens | Robin_Watts : ping | 13:33.15 |
| neosimsim | Can someone help me out using muPDF. I'm trying to extend the framework so I can open (PDF) file wich are enrypted with AES. I do NOT mean the PDF internal encryption. | 13:35.05 |
| | I would try to override/replace fz_stream somehow. | 13:35.45 |
| kens | tor8 ping, question there for you | 13:36.30 |
| tor8 | neosimsim: yes. you'd need to use fz_open_document_with_stream with a fz_stream that decrypts | 13:37.30 |
| kens | tor8 I'm trying to use mutool with -d and also a pages argument, but that doesn't seem to work ? | 13:38.15 |
| chrisl | kens: I don't think that's supposed to work | 13:38.45 |
| tor8 | neosimsim: the decrypting fz_stream would look much like the existing ones we have for arc4 and AES | 13:38.49 |
| kens | Oh :-( | 13:38.53 |
| tor8 | you may even be able to reuse them | 13:38.56 |
| | kens: mutool clean? | 13:39.08 |
| kens | yes, sorry mutool clean -d | 13:39.16 |
| chrisl | kens: remember, that's what that irksome customer wanted..... | 13:39.33 |
| kens | There are 6 zlib errors, and I wanted to know which pages they were on | 13:39.38 |
| tor8 | kens: are you sure it does not work? | 13:40.18 |
| kens | It won't work for me | 13:40.30 |
| | If I miss off -d then the command works, add -d and I get the whole file | 13:40.40 |
| tor8 | kens: mutool clean -dggg pdfref17.pdf 1 gets me an uncompressed pdf with the 1 page | 13:40.48 |
| kens | Hmm, let me try that | 13:40.59 |
| tor8 | you need to add the -g command or it won't garbage collect/delete the unused pages | 13:41.00 |
| neosimsim | OK. Thank I'll take a closer look. | 13:41.04 |
| tor8 | the -d just rewrites the page tree | 13:41.08 |
| | I'm sorry, s/-d/page argument/ | 13:41.20 |
| kens | OK, interesting :-) | 13:41.22 |
| | OK so that does work, thanks! | 13:41.52 |
| tor8 | -gg is the sweet spot | 13:42.05 |
| kens | interestingly throws 2 errors, which GS doesn't seem to. | 13:42.12 |
| tor8 | the -ggg runs in bad time complexity, since it compares every object with every other object | 13:42.17 |
| kens | FWIW I have a counter example file which MuPDF renders mostly blank but GS and Acrobat render, GS specifically ignores the zxlib error. | 13:42.34 |
| chrisl | Ooohh, that's right, that customer wanted mutool to explode the file into individual pages..... | 13:42.47 |
| kens | Oh yeah, that one :-( | 13:43.02 |
| tor8 | chrisl: yeah, customer wanted %d to work for mutool clean | 13:43.04 |
| kens | THis way works perfectly well for me | 13:43.20 |
| kens | bogglesw | 13:43.52 |
| Robin_Watts | kens: Sorry, missed that. | 13:44.05 |
| chrisl | I think that file is just broken 9 ways from Sunday...... | 13:44.13 |
| kens | If I run the whole file I get 6 errors, if I run page 27 I get 2 errors, if I run pages 1-26 and pages 28-end I get no errors, huh ? | 13:44.21 |
| | chrisl it is definitely totally borked | 13:44.40 |
| tor8 | neosimsim: decrypted_stream = fz_open_aesd(encrypted_stream, key, keylen) might be enough for you | 13:44.49 |
| | depends on the details of your AES encryption | 13:45.01 |
| kens | Sadly I cannot use the zlib error, because that breaks other files that Acrobat will handle | 13:45.06 |
| tor8 | neosimsim: if that doesn't work, look at the code in source/fitz/filter-basic.c for how to implement a filtering fz_stream | 13:45.26 |
| chrisl | kens: Is it really the zlib error causing the corruption? | 13:45.41 |
| kens | I think the best I can do is alter pdftokenerror so that if PDFSTOPONERROR is true it will throw an error and exit. The co-orindates being returned are monstrous, and stroking the resulting paht is taking forever. | 13:45.55 |
| | chrisl I can't be certain of that, but the page is zlib compressed, and MuPDF throws an error on it | 13:46.14 |
| | 'incorrect data check' so the zlib data *is* corrutped | 13:46.34 |
| chrisl | kens: could we tweak the number parsing code? | 13:46.46 |
| kens | To reject stupidly large co-ordinates ? Possibly | 13:47.10 |
| chrisl | No, I was thinking to make more of an effort to make sense of broken numbers | 13:47.31 |
| kens | Oh, well the problem isn't the nonsensical numbers, they get set to 0 | 13:47.58 |
| | Its the 16 digit numerics which are causing the problem | 13:48.09 |
| | The co-ordinates that result in the path are gigantic | 13:48.26 |
| chrisl | Oh, that's not what I thought the problem was..... | 13:48.41 |
| kens | I could be wrong, I'm not completely au fait with the rendering routines, but it seems to be spending a lot of time bisecting an absolutely huge path | 13:49.14 |
| | If you look at the co-ordinates in the PDF file, the ones which aren't broken are many digits long | 13:49.39 |
| chrisl | Yeh, I thought the problem was the way matrix transforms worked out, the "0" coordinates were ending up huge | 13:49.57 |
| kens | Hmm, well you could be correct, but I thought it was just the massive numbers in the path construction | 13:50.21 |
| chrisl | I can't see any way we can reasonably reject numbers that seem "too large"...... | 13:50.32 |
| kens | Me neither | 13:50.41 |
| | Nor can we reject files that have broken checksums, since we have an example that Acrobat reads. | 13:51.00 |
| chrisl | IIRC, the path is basically from MIN_INT to MAX_INT isn't it? | 13:51.17 |
| kens | Which leaves me with modifying the corrupted number recovery code to throw an error if PDFSTOPONERROR is set | 13:51.25 |
| | chrisl I assume so, I seem to rec all seeing negative co-ordinates in there too | 13:51.47 |
| chrisl | Yeh, MIN_INT would be negative | 13:52.04 |
| | Or possible max_fixed/min_fixed | 13:52.20 |
| kens | Hmm, not sure at that poing, just a moment while I recompile and I'll try and see where it is again | 13:52.45 |
| chrisl | I'm wondering if the graphics could throw an error if the path bbox is min_fixed...max_fixed | 13:53.29 |
| kens | OK we're running in gx_subdivide_curve_rec | 13:54.23 |
| | Which is allocating a monstrous number of segments | 13:54.37 |
| | gx_flattened_iterator__next keeps not terminating | 13:55.24 |
| chrisl | kens: so, I reckon we should calculate the bbox of the path, and if it's outside (min_coord_fixed,min_coord_fixed) (max_coord_fixed,max_coord_fixed) we throw a rangecheck | 13:56.55 |
| kens | I'm not certain, because I think these are fixed precision numbers, but they don't look quite lime min_fixed and max_fixed | 13:57.01 |
| | chrisl that does throw away potentially possible paths, though I admit they are unlikely | 13:57.46 |
| chrisl | kens: no, it doesn't: "Currently the path drawing routines can't handle values close to the edge of the representable space" - base/gspath.h | 13:58.21 |
| kens | Hmm, hadn't seen that | 13:58.36 |
| chrisl | I won't comment on why the coordinates aren't being clamped to that..... they may come from FAPI. Is it a charpath? | 13:59.02 |
| kens | I see, so our maximum co-ordinte is less than max_fixed | 13:59.10 |
| | chrisl no, its an explicit stroke in the PDF file, the S operator | 13:59.27 |
| chrisl | kens: my guess is we need a little "wiggle room" inside the coordinate space. Possibly for just this type of case | 13:59.59 |
| kens | THe maxcros there look like they were intended to be used to clamp the co-ords | 14:00.13 |
| chrisl | Yeh | 14:00.21 |
| kens | Hmm, so if bbox_set is false for the path, what forces it to be calculated, any ideas ? | 14:01.13 |
| chrisl | I think there's a function for setting it | 14:01.43 |
| kens | Yeah I'm trying to find it, I'm sure I've used it before.... | 14:01.54 |
| | Probably in eps2write..... | 14:02.03 |
| chrisl | Oh, maybe not - I have vague memory of some confusion over that that meant..... | 14:02.16 |
| | gx_path_bbox ? | 14:03.05 |
| kens | There is a gs_setbbox but its in gsdps1.c which sounds wrong | 14:03.09 |
| chrisl | gx_path_bbox() and gx_path_bbox_set() | 14:04.12 |
| kens | Both of them ? O.O | 14:04.25 |
| | Oh one is 'to be used byt the pathbbox operator' | 14:04.53 |
| | And why does it need a special one I wonder ? | 14:05.09 |
| chrisl | <shrug> | 14:06.49 |
| kens | Well the regular one is complex enough | 14:07.02 |
| | Complete with its own macro | 14:07.14 |
| | Oh, apparently bbox_set is 'set by setbbox' | 14:07.44 |
| | But gx_path_bbox says that ppath->bbox_accurate means that it was set by setbbox. Nice to see some consistency :-( | 14:08.23 |
| | OK we already cal gx_path_bbox in gx_stroke_path_only_aux, so the bbox is valid | 14:10.10 |
| chrisl | But can you know that? | 14:10.53 |
| kens | Well I was going to chekc it there, so I guess os | 14:11.10 |
| chrisl | If it doesn't set either bbox_set nor bbox_accurate | 14:11.19 |
| kens | I agree, I can't see how we ever know if a bbox is valid, unless we actually explicitly call gx_path_bbox. I have a sneaky suspicion we end up calling that far more often than we need to, because we can never tell if its valid | 14:12.05 |
| | Well the bbox is not min_fixed to max_fixed | 14:13.07 |
| | Its 0,0 to some vcery large number | 14:13.16 |
| | 0x7212f980, 0x7ffc17ff | 14:13.39 |
| | I think I'm back to modifying pdftokenerror to throw an error if PDFSTOPONERROR is true | 14:14.56 |
| chrisl | Hmm, oh well...... | 14:16.35 |
| kens | Well, teh file definitely is broken, so I think that's as good as its going to get | 14:17.02 |
| chrisl | My only other thought was some kind of maximum number of subdivisions of a path | 14:17.26 |
| kens | I'd be wary of that one, I think it could cause problems | 14:17.48 |
| chrisl | Final thought would be to look at how zlib is handling the errors, and see if we could do something better | 14:20.29 |
| kens | To be honest, I'm not even getting the errors from zlib | 14:20.46 |
| | MuPDF is, but the stream decoder in GS isn't, I have no idea why | 14:21.02 |
| | Possibly the zlib errors belong to a different stream | 14:21.30 |
| | Interestingly the stream does recover, so presumably there's some kind of reset in it | 14:24.00 |
| | Oh great PDFSTOPONERROR doesn't work :-( | 14:27.59 |
| | It just ignores the error and carries on..... | 14:28.10 |
| | OK I cna fix that too at the same time | 14:31.30 |
| mvrhel_laptop | bbiaw. dr. appt | 18:37.01 |
| | Forward 1 day (to 2014/11/04)>>> | |
IRC Logs
