| <<<Back 1 day (to 2015/01/25) | 20150126 |
kens | chrisl, since Marcos is off sick. THe latest email regarding a vulnerability in LibTIff. I can't see any way this can affect Ghostscript, what do you think ? The bug report in LibTiff is here: | 14:40.45 |
| http://bugzilla.maptools.org/show_bug.cgi?id=2494 | 14:40.45 |
chrisl | kens: that cannot affect Ghostscript's use of libtiff - that bug applies to reading, and we only use libtiff for writing. | 14:42.26 |
kens | It is in PackBitsEncode() though | 14:42.53 |
| The BMP has an incorrectly defined size, which causes PackBitsEncode to read off the end of memory (apparently) | 14:43.23 |
| THat said, I'm not sure we use PackBitsEncode | 14:43.40 |
chrisl | Oh, actually, that's not the bug I thought it was - hang on.... | 14:43.40 |
kens | I had to wade through 3 levels of indirection to find the code snippet | 14:44.02 |
chrisl | If I'm reading it correctly, the vulnerability relies on invalid input, which, again, with our integration, can't happen..... | 14:46.11 |
kens | The input has to be invalid,yes | 14:46.24 |
| OK so I htink it can't happen either, I'll pass that along to the customer. | 14:46.43 |
chrisl | The only way it could be exposed in Ghostscript would be to change the gs source, in which case, there are much easier ways to hack in | 14:47.35 |
kens | Yeah, I agree, just wanted a 2nd opinion | 14:47.52 |
| I wonder if we're going to start seeing more of tehse in the wake of Heartbleed and Poodlebleed | 14:50.51 |
chrisl | I suspect we may, yes. It probably means we (I) should be a bit more diligent in keeping the third part libs up to date..... | 14:52.47 |
kens | Well I guess we should probably review the 3rd party libraries just before we get round to a release | 14:57.14 |
chrisl | We can't really do it just before a release, especially lcms and freetype tend to introduce *loads* of diffs | 14:58.47 |
kens | Well, I meant before we start on our release process, however many weeks in advance we need in order to look at the libraries. | 14:59.38 |
wrexem | Good morning everyone. | 15:01.12 |
| I seem to be having a bit of trouble... not sure what I've done. Trying to use MuPDFLib-x86.dll | 15:01.37 |
| in C#.NET, 2013 | 15:01.44 |
| I think it was working fine in 2012... | 15:01.51 |
kens | Sounds like another job for Mr Vrhel | 15:01.58 |
| mvrhel_laptop : you listening ? | 15:02.14 |
| I guess that's a no. You'd better describe your problem and maybe he can help when he comes back | 15:02.48 |
| D'oh, forgot to 'Git add' new files, no wonder the cluster failed to compile. | 15:03.47 |
wrexem | So, I have these shiny .dll files - I'm not sure exactly where I got them... it was quite a while ago. But I had them listed as references. Now when I open the project, the references show as an exclamation mark. | 15:05.09 |
kens | Oh, you've updated from VS 2012 to VS 2013 ? | 15:05.48 |
wrexem | When I remove them and try to re-add the refs, I get "A reference to [ dll file location ] could not be added. Please make sure the file is accessible, valid assembly, COM component" | 15:06.03 |
| yes | 15:06.04 |
kens | Hmm, beats me :-( | 15:06.13 |
kens | is still using VS 2008 | 15:06.20 |
wrexem | Which project builds those .dll files do you know? | 15:06.48 |
kens | I'm afraid I don;t know, Robin_Watts might, possibly. Assuming these are MuPDF .DLL files ? | 15:07.15 |
wrexem | Yeah | 15:07.23 |
Robin_Watts | wrexem: The DLLs come from builds of mupdf (and possibly gs). | 15:07.29 |
wrexem | MuPDFLib-x86 | 15:07.33 |
Robin_Watts | They aren't built as part of the 2013 solutions. | 15:07.49 |
wrexem | Could I download one that has already been built somewhere? | 15:08.15 |
Robin_Watts | but rather they are built using their own solutions, and then copied into specific places, I think. | 15:08.18 |
wrexem | A newish one | 15:08.39 |
Robin_Watts | Hmm. Actually, the standard mupdf solution doesn't build a dll. | 15:08.52 |
| so you'd hope that the project for that should be part of mvrhels stuff. | 15:09.14 |
kens | It seems ot be hosted on Google code, not our code at all | 15:09.54 |
| https://code.google.com/p/mupdf-converter/source/browse/trunk/MuPDF/MuPDFLib-x86.dll?r=49 | 15:10.05 |
| Last versionseems to be form 2012 though | 15:10.13 |
Robin_Watts | wrexem: Sorry, where are you getting the code from? | 15:10.30 |
| wrexem: From the link that kens gave? or from mupdf.com or downloads.ghostscript.com/public ? | 15:10.59 |
halabund | I have some subtly broken PDF files written by Mathematica. Is Ghostscript able to read, process and then save PDF files without converting to PostScript first? If I re-save these files with Mac Preview, they get fixed, but Iâm looking for a command line tool to automate this âfixingâ. | 15:11.14 |
Robin_Watts | halabund: You'd do better with mupdf, and it's "mutool" tool. | 15:11.47 |
| mutool clean in.pdf out.pdf | 15:11.54 |
kens | halabund Ghostscript does not convert PDF to PostScript. However, it does completely process PDF input (and all other formats) to graphic primitives, which it then renders, or in the case of pdfwrite, re-emimts as a new PDF file. | 15:12.05 |
| I should say 'does not convert PDF to an intermediate PostScritp representation'. Ghostscript *can* convert PDF to PostScript, but it doesn't have to. | 15:12.36 |
halabund | Thanks, Iâll try mutool first since you already gave me the syntax! | 15:12.44 |
| installing now ... | 15:12.57 |
| Hm, mutool didnât fix it .. | 15:14.41 |
wrexem | derp. Robin_Watts, kens, I figured it out :) Somehow, I had lost the "parent" dll? idk where | 15:14.56 |
Robin_Watts | In what way is the pdf broken? | 15:14.56 |
wrexem | just MuPDF.dll | 15:15.04 |
| had to be added as the reference | 15:15.11 |
kens | halabund : might be easiest ot poitn us to an example of a broken file | 15:15.17 |
halabund | Robin_Watts: I am not 100% sure itâs broken, but this is what happens: I make figures using Mathematica, âplaceâ them in Adobe Illustrator, put annotiations on top, and then export as PDF. The âplacedâ files donât show in the exported PDF. This problem only shows up with Mathematica-generated PDFs. | 15:15.57 |
| âPlacingâ the file in Illustrator means that it just embeds it as-is, without making it possible to edit it. It also preserved the link to the âplacedâ file on disk, so when I update it, the main document also updates. | 15:16.37 |
| OK, Iâll show you such a PDF, let me make a simple one ... | 15:16.46 |
kens | SOunds liek it doens't put the 'placed' files in the PDF at all, it just points to them with an annotation. | 15:17.15 |
| This will only work if the files are available to the reader, and the reader supports that kind of annotation. | 15:17.39 |
halabund | This is the PDF made with Mathematica: https://dl.dropboxusercontent.com/u/38623/PDFs/plot.pdf | 15:18.28 |
kens | So all I see is a circle | 15:18.42 |
halabund | This is the one exported from Illustrator, with a rectangle put on top: https://dl.dropboxusercontent.com/u/38623/PDFs/plot_placed.pdf It should show both a circle and a rectangle, but it only shows the rectangle. | 15:18.59 |
kens | Rectangle is all I see ehre, just a mo | 15:19.24 |
halabund | If instead of plot.pdf I place plot_resaved.pdf, then the problem goes away. https://dl.dropboxusercontent.com/u/38623/PDFs/plot_resaved.pdf This was simple re-saved with OS Xâs Preview.app. | 15:20.45 |
kens | Hmm, the circle is in a form XObject,but its definitely in the file | 15:21.51 |
halabund | So maybe plot.pdf is not broken after all, and itâs Illustrator that is buggy? | 15:22.10 |
kens | No.... I'm not certain what's going on yet. | 15:22.33 |
| No PDF viewer displays the circle in your 2nd PDF file (plot_placed.pdf) | 15:22.53 |
| I'm not sure why though | 15:22.58 |
| Of course, Illustrator doesn't show you waht's in the PDF :-) | 15:23.21 |
halabund | Iâll be back in a minute, need to connect to VPN ⦠| 15:23.28 |
| OK, back, hopefully | 15:23.48 |
kens | You never went :-) | 15:23.56 |
| The circle seems to be drawn in white | 15:24.21 |
halabund | I want to try an older version of Illustrator on a computer at my office ⦠| 15:24.26 |
kens | Actually I take that last comment back, it changes colour to black before drawing it. | 15:25.05 |
| AH, the file is indeed 'broken', in a sense | 15:26.14 |
halabund | In what way? | 15:26.51 |
kens | The rectangle is shown in a form, and the form has various properties, one of which is the bounding box, which is declared as: | 15:26.52 |
| " /BBox [ 59.5028992 -7.86864996 372.272003 -7.86864996 ]" | 15:26.56 |
| That's llx, lly, urx, ury | 15:27.08 |
| Note that lly == ury | 15:27.16 |
| So any sensible viewer doesn't bother to render it | 15:27.32 |
| If I manually hack the ury to be 99.868... then I see stuff | 15:27.56 |
| Even at that I only see less than half the circle though | 15:28.57 |
halabund | You mean thatâs the bounding box for the circle, right? Not the rectangle. Itâs the circle thatâs missing. | 15:29.14 |
kens | Yes, sorry, I had done some other hacking | 15:29.25 |
| so I had two rectangles | 15:29.31 |
| But in your original file if I change the BBox then *part* of the circle appears | 15:29.48 |
| I could change it some more to get all of it I expect | 15:30.01 |
| It looks to me like you are experiencing *2* bugs, which happen to cancel out | 15:30.13 |
| THe Illustrator bug is that its writing the BBox incorrectly (htis could be a Mathematica bug) | 15:30.36 |
| Now OS/X Preview should leave this unchanged, but it clearly doesn't, and tha's another bug | 15:30.55 |
| You just seem to be in luck that they cancel each other out | 15:31.17 |
| OK so if I change the urx of the BBox to 400 then the whole circle appears | 15:32.13 |
| one minute while I look at the mathematica produced PDF file | 15:32.34 |
halabund | Is this bounding box present in the original file, plot.pdf, as well? Or only in plot_placed.pdf? I can only see these numbers in the latter. | 15:32.39 |
kens | One second, that's where I'm off to now | 15:32.50 |
| The Mathematica file looks perfectly fine to me. It doesn't use a form, so it has no BBox, and the media size seems to be correct. THis looks to me like an Illustrator bug | 15:33.55 |
| Of course, the Mathematica produced PDF uses Cairo, so it claims to use transparency, when it really doesn't. | 15:34.25 |
halabund | OK, so complaining to Wolfram wonât get me anywhere then, as itâs not their fault. | 15:35.23 |
kens | Nope, their file looks fine to me, you need to complain to Adobe. Good luck with that one :-( | 15:35.49 |
| I'm afraid that both GS and MuPDF will regard your 'broken' file as valid and won't try to fix it. While its an odd thing to do to have a degenerate BBox, its not invalid, and people do strange things all the time with PDF. | 15:36.41 |
| chrisl what's the magic runes for making a commit without the pre-commit hook complaining about tabs in the files ? I modified a makefile again..... | 15:38.46 |
chrisl | Erm, "commit -w" maybe? | 15:39.09 |
kens | could be let me look at man | 15:39.17 |
chrisl | No, "commit -n" | 15:39.50 |
kens | ah, 'no verify' thanks! | 15:40.44 |
halabund | kens: I just tried to process the original Mathematica-exported file though GS (not mupdf) and this also seems to fix the problem. Iâm just not sure that the GS command line Iâm using is sane, as I put it together mosly based on the ps2pdf script. Could you check it? | 15:47.38 |
| gs -q -sDEVICE=pdfwrite -sOutputFile=plot-gs.pdf -dBATCH -dNOPAUSE -c save pop -f plot.pdf | 15:47.39 |
kens2 | Network having a bad day :-( | 15:48.59 |
wrexem | kens; he just asked a question - did you see that? | 15:49.51 |
| [10:47] <halabund> kens: I just tried to process the original Mathematica-exported file though GS (not mupdf) and this also seems to fix the problem. Iâm just not sure that the GS command line Iâm using is sane, as I put it together mosly based on the ps2pdf script. Could you check it? | 15:49.56 |
| [10:47] <halabund> gs -q -sDEVICE=pdfwrite -sOutputFile=plot-gs.pdf -dBATCH -dNOPAUSE -c save pop -f plot.pdf | 15:49.56 |
halabund | Iâll re-post | 15:49.56 |
| thanks wrexem | 15:50.00 |
wrexem | (sorry, spammy) | 15:50.00 |
kens2 | Its OK I saw it | 15:50.05 |
| I don't know why processing the original with GS would 'fix' the problem | 15:50.16 |
wrexem | Thanks for the help you guys, I got it working. Off to the real world! | 15:50.21 |
kens2 | I would try it but I have my GS in little tiny pieces at the moment, I'll try an old version | 15:50.34 |
halabund | I mean I need to process it through GS *before* âplacingâ it in Illustrator | 15:51.11 |
kens2 | Yes, I can't see why that would fix it, but (*extremely* weirdly) I'm getting 2 end of page messages from GS | 15:51.58 |
mvrhel_laptop | kens2: I am listening now (or reading to catch up) | 15:52.42 |
halabund | kens2: Thanks for all the help, donât spend more time on this. Iâm going to report it to Wolfram, just in case, and will use GhostScript to reprocess the exported PDFs. Since itâs a command line tool, I can automate it and itâll save a lot of time for me. | 15:52.47 |
kens2 | mvrhel_laptop : wrexem has left, he got it sorted out | 15:52.58 |
| halabund : it 'looks like' we're stripping out the pointless transparency, and that seems to make Illustrator happy (which is very odd) | 15:53.29 |
mvrhel_laptop | ok good. I have been in email contact with a customer who is having issues with the .net stuff. gsview is working for him just his project is not working correctly. I am hoping he will share his project with me so I can have a look | 15:54.22 |
| otherwise it is rather difficult to know what the issue is | 15:54.30 |
kens2 | Certainly is :-( | 15:54.37 |
mvrhel_laptop | chrisl: After beating and beating on these dumb windows installers for gsview, I am going to try NSIS which ray said you used for ghostscript | 15:56.15 |
| bbiab | 15:57.39 |
chrisl | mvrhel_laptop: yep, the installer stuff is in psi/nsisinst.nsi | 15:57.43 |
kens2 | halabund : yes, the only thing I can see different after processing with GS is that we've removed the spurios transparency. Ghostscript does preprocess PDF files to see if they are transparent or not, and tries to get rid of pointless transparency. THis is for performance reasons, it wastes a lot of time and memory if we aren't actually going to *use* any transparency | 15:57.50 |
halabund | Iâm curious what will happen if I do use transparency, Iâll try that | 15:58.26 |
kens2 | Well, GS should preserve it (its a bug if it doesn't). I would be quite interested to know what happens, especially with OS/X preview as well | 15:59.03 |
halabund | Yes, in that case it doesnât âfixâ it. | 16:00.09 |
kens2 | That's sort of what I expected | 16:00.19 |
| It looks like the transparency is what is causing Illutrator to hiccup | 16:00.35 |
halabund | This one is a circle with transparency, as saved by an earlier version of Mathematica: https://dl.dropboxusercontent.com/u/38623/PDFs/plot-m9.pdf Illustrator doesnât have a problem with it. | 16:02.55 |
kens2 | iNTERESTING, IT HAS tRANSPARENCY IN IT | 16:03.37 |
| Oops caps lock | 16:03.48 |
halabund | I know they completely re-did the PDF export engine in the latest Mathematica. | 16:04.06 |
kens2 | Hmm, let me redo that | 16:04.39 |
| ah the old version doesn't use Cairo, and doesn't have nay nonsense transparency in it | 16:05.18 |
| The older version has some really weird constructs in it though | 16:06.39 |
| Looks like its trying to mazximise the clip path | 16:06.56 |
| The new code is more efficient, but includes silly transparency, which it seems is why Illustrator throws a wobbly | 16:07.37 |
| Looks like as long as you don;t actually use any real transparency processing the Mathematica files through GS shoudl remove tha,t and then Illustrator will be happy | 16:08.08 |
| Well, I've managed not to break anything by changing the code, not bad for 1 days :-) | 16:09.09 |
| I suppose I'd better hook it all up and see if ti works now | 16:09.32 |
halabund | kens2: Thanks for all the help again! :-) | 16:24.13 |
kens2 | No problem | 16:24.21 |
mvrhel_laptop | hmm so I wonder why the nsis compiler is not properly detecting that my machine is 64 bit | 18:59.14 |
| Forward 1 day (to 2015/01/27)>>> | |