| | <<<Back 1 day (to 2014/09/16) | 2014/09/17 |
| jogux | morning all | 09:38.28 |
| amyn | hello guys, is some one there to help me out with ghostscript? | 09:54.14 |
| Robin_Watts | amyn: ask your question, don't ask to ask your question. | 09:57.10 |
| amyn | is it possible to detect if the loaded pdf is colored or grayscale using ghostscript -sDEVICE=inkcov ? | 09:57.54 |
| | as is explained here: http://stackoverflow.com/questions/12299574/ghostscript-color-detection | 09:58.06 |
| | does this give an accurate result for every case? | 09:58.21 |
| Robin_Watts | amyn: There is *a* way to do that using gs. I don't know that inkcov is that way though. | 09:58.31 |
| | I was just involved in implementing such detection in mupdf though, so I can answer questions about that :) | 09:59.07 |
| amyn | great, how did u do that? can you explain please? | 09:59.29 |
| Robin_Watts | amyn: mudraw -T -d in.pdf | 09:59.56 |
| | amyn: Mupdf is a separate project. It shares no code with gs. | 10:01.43 |
| amyn | i am downloading mupdf-1.5-windows.zip | 10:02.40 |
| Robin_Watts | So the support in mupdf for testing color/greyscale is completely different (but to the same basic spec) | 10:02.43 |
| | It's not in the 1.5 release. | 10:02.52 |
| | It only went into git a week or so ago. | 10:03.03 |
| | It'll be in the next release, or you can download the current source and build your own. | 10:03.24 |
| amyn | so i cant get it now? | 10:03.54 |
| Robin_Watts | http://git.ghostscript.com/?p=mupdf.git;a=snapshot;h=758a9a75fd34bd8312b07f1be72aeee63522d2a0;sf=tgz | 10:03.54 |
| | amyn: You can't download a prebuilt binary, no. | 10:04.09 |
| amyn | so i will have to wait for the release? | 10:04.24 |
| Robin_Watts | or you'll have to build your own. Which is not hard. | 10:04.42 |
| amyn | i think i wont have time to build my own as i need to integrate color detection into my application | 10:05.14 |
| | can you explain me if the link i provided is one possible solution? | 10:05.31 |
| Robin_Watts | amyn: You want to integrate color detection into your application? So you'll be supplying gs (or mupdf) with your application? | 10:06.16 |
| | You are aware of the strictures of the GNU AGPL, right? | 10:06.31 |
| | Certainly using gs and inkcov may we one way of doing it. I've not been following that. | 10:07.00 |
| amyn | yes i am. i am currently in my testing phase and if the final results show that gs is required, then we will start the licensing procedure | 10:07.15 |
| chrisl | inkcov does not get you that information - not even close | 10:07.22 |
| Robin_Watts | chrisl: What is the neutral color detecting mechanism that michael implemented? | 10:07.54 |
| chrisl | Robin_Watts: nothing to do with inkcov...... | 10:08.14 |
| Robin_Watts | chrisl: right, that makes sense. | 10:08.26 |
| chrisl | At the mement, AIUI, the page neutral color stuff is available to devices, but does have an "external" interface. That's what Ray added recently-ish | 10:09.09 |
| | s/does/does not | 10:09.20 |
| amyn | isn't it possible to analyze the result from inkcov i.e. if C=M=Y=0, then it is definitely grayscale | 10:09.39 |
| Robin_Watts | amyn: AIUI, inkcov tells you how much ink is used on the page of each different component. | 10:10.05 |
| | so it can't tell the difference between 3 squares of C, M and Y separately on the page (which would be color), and 3 C,M,Y squares on the page on top of one another, which would be greyscale. | 10:11.32 |
| amyn | oh i see what you are saying here. i understand it now. | 10:12.11 |
| | then if pdf is not possible, detecting .png will also be not possible right? | 10:12.37 |
| chrisl | amyn: the ghostscript implementation is in a release candidate you could try..... | 10:12.59 |
| Robin_Watts | amyn: I don't follow that logical leap. | 10:13.15 |
| amyn | Robin_Watts: Is it possible to detect if an image (.png) is colored or grayscale? | 10:13.43 |
| Robin_Watts | It is perfectly possible to detect it at the pdf level. Both gs and mupdf contain code that does exactly that. | 10:13.46 |
| | I can tell you how to use the mupdf code. I can't tell you how to use the gs stuff, but within about 6 hours, someone will be here who can. | 10:14.12 |
| | But in both cases (for mupdf and gs) you will need to use the very latest code. | 10:14.42 |
| chrisl | amyn: for png, you'd open the png file, and decode the samples, and see if there are "color" samples in the png.... | 10:14.50 |
| amyn | but as u said, i dont have access to mupdf latest version that is not released yet | 10:15.03 |
| chrisl | amyn: it is available to you if you are willing to build it | 10:15.32 |
| amyn | will u be able to guide me through the building process? | 10:15.54 |
| chrisl | amyn: what platform are you using? | 10:16.04 |
| amyn | Visual Studio 2010 (C# and C++). I prefer using C# | 10:16.32 |
| Robin_Watts | amyn: Then it's trivial. | 10:16.40 |
| | Download the link I gave earlier. Unpack. Open platform/win32/mupdf.sln and let it update to the vs2010 format. Build solution. Done. | 10:17.18 |
| chrisl | amyn: and will you be calling an exe to get the information, or integrating a library (either mupdf or ghostscript)? | 10:17.40 |
| amyn | well i guess integrating a library would give better performance in terms of speed but for testing purposes, calling an exe would also work | 10:18.22 |
| chrisl | Well, as I said, the Ghostscript solution is available as a release candidate, but the mupdf one is probably simpler in its use | 10:19.25 |
| amyn | i opened mupdf.sln on visual studio 2010 and it is asking me to upgrade the project , should i go ahead? | 10:19.42 |
| chrisl | as Robin_Watts said: "let it update to the vs2010 format" | 10:20.23 |
| amyn | Project: vc8libcur failed to convert | 10:22.09 |
| | mupdf-758a9a7\thirdparty\curl\vs\vc8\lib\vc8libcurl.vcproj' was not found. | 10:22.43 |
| | in mupdf-758a9a7\thirdparty\ there are 7 folders and they all are empty | 10:24.03 |
| Robin_Watts | amyn: oh, ass. I'd forgotten the thirdparty stuff. | 10:28.16 |
| | amyn: Have you ever used git? | 10:29.00 |
| thebat | Hello | 10:30.41 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 10:30.41 |
| thebat | I have a PDF which contains white text surrounded by transparent space. I would like to know how to use gs to crop this PDF such that the bounding box surrounds the text. Right now, the bounding box has a height of 0 since it is not able to recognize the text in the document. I'll be posting a link to a sample PDF shortly. | 10:33.09 |
| | https://dl.dropboxusercontent.com/s/mcf154aik5wxu0m/sample%20pdf.pdf?dl=0 | 10:34.11 |
| | This PDF has the text "This is rotten" in the bottom left corner. | 10:35.13 |
| | Following is the command we used to determine the cropping bounding box was incorrect: gs -sDEVICE=bbox -dBATCH -dNOPAUSE -c save pop -f sample\ pdf.pdf | 10:36.44 |
| chrisl | thebat: if it doesn't work like that, it probably can't be made to work with the current code | 10:38.03 |
| thebat | chrisl: are there any flags we can pass to gs so that it returns the proper bounding box? or alternatively, is there another set of parameters we can pass to gs so that it takes transparency as the background? | 10:39.55 |
| chrisl | thebat: be careful how you use the word "transparency" it has a specific meaning in the PDF world | 10:40.44 |
| amyn | yes i have used git | 10:40.55 |
| Robin_Watts | amyn: http://ghostscript.com/~robin/mudraw.exe That's an unofficial build that you can use for now. There will be an official release within 2 weeks or so. This should be enough to let you see whether it works etc. | 10:40.57 |
| thebat | chrisl: can you explain what that specific meaning is? i'm not sure what you're referring to | 10:42.40 |
| chrisl | thebat: it's easier to explain what it does not mean: it does *not* mean "unmarked" areas of the page. For a fuller explanation, you'd have to read the PDFRM - it's *way* too involved for an explanation here | 10:43.54 |
| Robin_Watts | simplistically, transparency in PDF means "semi opaque shapes" | 10:46.06 |
| thebat | chrisl: i have given the link to a sample pdf above. perhaps that can give more context to the specific problem i'm facing here | 10:46.18 |
| Robin_Watts | thebat: chrisl was very clear above. "if it doesn't work like that, it probably can't be made to work with the current code" | 10:46.50 |
| thebat | Robin_Watts: oh, so by "current code" chrisl was referring to the current implementation of gs, right? | 10:47.57 |
| chrisl | Okay, so there is no "transparency" in that file | 10:50.07 |
| thebat | chrisl: oh, so by "current code" you were referring to the current implementation of gs, right? | 10:51.57 |
| chrisl | thebat: more specifically, to the current implementation of the bbox device, but yes | 10:52.26 |
| thebat | chrisl: okay, thanks! | 10:52.53 |
| | chrisl: do you know of any way i can achieve the same? | 10:53.13 |
| chrisl | thebat: no, not really. I'm getting weird results, though.... | 10:54.50 |
| thebat | chrisl: or alternatively, do you know any way i can use ghostscript to change color of the text in a pdf or eps? | 10:55.21 |
| chrisl | thebat: that would be possible, but extremely non-trivial | 10:55.50 |
| | FWIW, I think this is a bug..... | 10:56.35 |
| thebat | chrisl: yeah, i think so too. | 10:57.24 |
| | chrisl: thanks anyway! | 10:58.57 |
| chrisl | thebat: I'd encourage you to open a bug so this gets investigated | 10:59.16 |
| thebat | chrisl: sure, i'll do that | 11:01.01 |
| chrisl | thebat: as an experiment, you could draw a non-white object on the page, then the white text, and see if the bbox output includes the text at that point | 11:01.43 |
| thebat | chrisl: i already tried that. the results were, as you mentioned, weird | 11:04.19 |
| | check out these PDFs | 11:04.26 |
| | ORIGINAL PDF - https://dl.dropboxusercontent.com/s/at5c7mfbol86790/before_crop.pdf?dl=0 | 11:06.03 |
| | CROPPED PDF - https://dl.dropboxusercontent.com/s/9kk6qagds4wnvlo/after_crop.pdf?dl=0 | 11:06.23 |
| chrisl | thebat: the bbox device, it seems, has a setting that configures whether "white" is considered "transparent" and that defaults to "white == transparent", but there doesn't seem to be any external way to influence that...... | 11:14.39 |
| amyn | Robin_Watts: this is great. exactly what i am looking for. please provide procedure for licensing so I can take it forward to my managers | 11:15.00 |
| thebat | chrisl: that looks really interesting | 11:15.32 |
| chrisl | thebat: actually, hang on..... | 11:15.32 |
| | thebat: bingo! Add -dWhiteIsOpaque to your bbox command line - that should get you what you need | 11:17.09 |
| thebat | chrisl: awesome!! just tried it and it works great! thanks a ton! :) | 11:19.33 |
| chrisl | thebat: sorry took a while - I'm not too familiar with the bbox device.... | 11:19.54 |
| thebat | chrisl: not a problem, you just saved us a couple of hours :) | 11:22.01 |
| chrisl | Well, I do think the default is confusing, but, hey, at least it can be configured | 11:22.43 |
| thebat | chrisl: yeah | 11:23.16 |
| amyn | can someone here tell me about licensing mudraw? | 12:07.17 |
| tor8 | Robin_Watts: mupdf builds and runs fine on the emulator using the latest sdk and ndk versions | 12:17.48 |
| | Robin_Watts: though it crashes with a NullPointerException if there is no sdcard | 12:18.06 |
| Robin_Watts | amyn: Mail sales@artifex.com and ask there. | 12:37.21 |
| | amyn: If you don't get a reply, come back here, and we'll chase it for you. | 12:37.37 |
| tor8 | Robin_Watts: did you run into any of these unresolved symbol errors on any of your android builds? | 13:27.21 |
| | or are we only going by what users have told us? | 13:27.38 |
| Robin_Watts | tor8: users. | 13:53.43 |
| | but I've not tried anything newer than r8e. | 13:53.57 |
| tor8 | Robin_Watts: right. well, they must be doing something unusual, because I can't reproduce it. should we go ahead and make a release? | 13:57.56 |
| | I would expect they're not following instructions and trying to use Eclipse | 13:58.18 |
| Robin_Watts | tor8: Sure. Possibly we should put a note in platform/android/ReadMe.txt and say "if you're seeing crashes when trying to load the shared library, check that you are using the correct configuration of tools" | 13:59.21 |
| tor8 | Robin_Watts: yeah. I put in a comment in the latest such bug report with exactly what configuration of tools I used | 13:59.54 |
| | hopefully we'll get some useful reply back | 14:00.02 |
| Robin_Watts | Morning michael. | 14:04.39 |
| mvrhel_laptop | Good mornng robin_watts | 14:06.11 |
| Robin_Watts | So the morons can't tell the difference between 0.4 and 0.04. | 14:23.04 |
| | "Do you understand decimal numbers?" | 14:23.30 |
| chrisl | "We don't have to, you understand them for us" | 14:23.51 |
| pedro_mac | to be fair, they lookl very similar, apart from the zeros | 14:26.36 |
| | guess thatâs why I never have any money left | 14:26.47 |
| tor8 | Robin_Watts: https://github.com/nothings/stb/blob/master/stb_image_resize.h would be interesting to try out and compare with what we have, both quality and performance wise | 14:31.18 |
| kens | THis must be a tough school district: | 14:31.37 |
| | http://www.reuters.com/article/2014/09/17/us-usa-california-school-weapons-idUSKBN0HC0N320140917 | 14:31.37 |
| Robin_Watts | tor8: I've spent way too much of my life messing with such things. | 14:32.34 |
| | but feel free :) | 14:32.39 |
| tor8 | Robin_Watts: in particular, it has stbir_resize_subpixel, to allow for subpixel offsets like we need for type 3 bitmap fonts | 14:33.58 |
| Robin_Watts | right. | 14:34.42 |
| | IIRC we don't do image gridfitting inside type 3s, so we should do subpixel in mine too. | 14:35.19 |
| | (with the constant assumption that I haven't ballsed something up of course) | 14:35.45 |
| jogux | hm. mupdf displays the invoice attached to the email I just got about an order I didn't place as a blank white page. I wonder if it would do something funky if opened in adobe reader :) | 14:40.29 |
| Robin_Watts | All your bank accounts are belong to us now. | 14:42.17 |
| henrys | kens: you should see what civilians can get without government red tape ;-) | 15:11.46 |
| kens | An armoured car ? Grenade launchers ? O.O | 15:12.33 |
| | For school police ? | 15:12.55 |
| henrys | I like this part: The Mine Resistant Ambush Protected vehicle, and the grenade launchers, would only have been used in "very specific circumstances," he added, without elaborating. | 15:14.19 |
| kens | Presumably only when the students would otherwise have a firepower advantage ? | 15:14.54 |
| Robin_Watts | "i.e. in compton" | 15:15.08 |
| | tor8: so the latest failure report does indeed come from someone trying to use the 64bit version. | 15:24.35 |
| | BUT... Android L headers are only available in the 64bit ones, so people are going to be moving to that one. | 15:25.21 |
| | So we should retest with the 64bit versions of the sdk. | 15:25.44 |
| | ndk | 15:26.44 |
| tor8 | Robin_Watts: okay. I'll try that tomorrow then. | 15:33.40 |
| | android-ndk32-r10b-linux-x86_64.tar.bz2 is the version I tried | 15:34.00 |
| Robin_Watts | tor8: oh, right, so that is the 64bit one. | 15:34.29 |
| tor8 | no, it's the 64-bit targeting 32-bit | 15:34.43 |
| | I should try the 64-bit targeting 64-bit | 15:34.52 |
| | android-ndk64-r10b-linux-x86_64.tar.bz2 | 15:35.10 |
| Robin_Watts | The guy reporting the problems says: http://dl.google.com/android/ndk/android-ndk64-r10b-darwin-x86_64.tar.bz2 | 15:35.25 |
| | oh, I see, yes. | 15:35.36 |
| tor8 | Robin_Watts: it's a shame that the file name is a lie though ... x86_64 it ain't | 15:36.31 |
| | there are binaries in there that require i386 | 15:36.37 |
| | Robin_Watts: yes, now I can reproduce the dlopen error | 15:45.31 |
| Robin_Watts | tor8: great. | 15:47.18 |
| tor8 | Robin_Watts: this is strange. rand() can be found in both the header files and the .so in the 64-bit android-ndk-r10b/platforms/android-L/arch-arm include and lib directories | 15:55.47 |
| Robin_Watts | tor8: strange indeed. | 15:56.40 |
| | Is it just rand that's the problem? | 15:56.57 |
| tor8 | probably not, but it fails at rand | 15:57.12 |
| Robin_Watts | If it's just rand, we could patch around it. | 16:00.32 |
| jogux | is it the .so on the device that matters in this failure? | 16:00.38 |
| Robin_Watts | jogux: MuPDF, when built with the 64bit version of the ndk fails to load libmupdf.so cos of various standard functions being missing. | 16:02.36 |
| | Like isinf, isnan, strtof, and rand. | 16:02.50 |
| | We've patched the mupdf headers to cope with the first 3. | 16:03.09 |
| | The annoying thing is that it doesn't complain at build time, just when it tries to resolve them when loaded. | 16:03.36 |
| jogux | robin: right. but it fails when you try to load it on the device, so the .so we'd need to look at would be the libc.so /on the device/ to see if it contains rand or not. | 16:04.17 |
| Robin_Watts | yes. | 16:05.04 |
| jogux | though presumably it doesn't. and it doesn't change how we'd fix it anyway. | 16:05.31 |
| kens | A fairly classic email form the muppets | 16:16.06 |
| henrys | Robin_Watts: I could come up with a pretty good case for an NRE from your color detection customer? Do you think that is in order or would you rather just carry on with them? I don't know how much time they are consuming now. | 16:22.46 |
| Robin_Watts | henrys: I think I could come up with a fairly good case for involuntary committal for that customer. | 16:23.18 |
| henrys | yup the nre would amount to an idiot tax | 16:23.49 |
| Robin_Watts | Their 'we can't do decimal numbers' email is just stupid. | 16:23.53 |
| | Their 'stuff gets bigger when we extract pages' may be true. | 16:24.05 |
| mvrhel_laptop | finally I have the tiff images getting packed into the xps zip file. stupid seeking of tiff was causing a few issues with respect to the byte counts in the zip archive for the file | 17:02.26 |
| | henrys: now onto the mark up and then I will have at least in a rudimentary form, images working for xpswrite | 17:02.45 |
| henrys | mvrhel_laptop: I had an idea to significantly speed up text. | 17:03.14 |
| mvrhel_laptop | I am hoping this will be much simpler code than what you had in the pcl stuff. I don't need to do all the transform stuff since I can just set the matrix in the markup | 17:03.40 |
| | for the image | 17:03.43 |
| | henrys: oh that would be great (about the text) | 17:03.53 |
| henrys | my idea is to detect when a character is being rendered... capture the path and translate it to the origin and store it as a static resource. Essentially a cache of paths. | 17:05.19 |
| | it should be simple to add, I'll do it after you finish with the images. | 17:07.24 |
| | famous last words | 17:07.38 |
| | mvrhel_laptop: so the rationale for tiff was for cmyk but xps is an rgb device everything should be converted, or have you changed that? | 17:10.28 |
| jogux | Apple actually fixed the iOS 8 bug that meant you couldn't delete files in mupdf! woot :) | 17:12.55 |
| mvrhel_laptop | henrys: oh interesting point. let me try a cmyk image and see what comes across here | 17:13.19 |
| | henrys: doing the glyph paths as a cache of static resources is a great idea | 17:15.50 |
| mvrhel_laptop_ | henrys: so cmyk source images are stored as cmyk images in the xps archive | 17:21.30 |
| | along with the cmyk profile | 17:21.33 |
| | no conversions needed | 17:21.40 |
| | so this part should zip along. working on adding the markup now | 17:22.06 |
| mvrhel_laptop | this is of course for high level images | 17:22.58 |
| henrys | so presumbably the color conversion to rgb would happen if the image were decimated to rectangle | 17:24.02 |
| | s | 17:24.04 |
| amyn | i came here a few hours ago looking for a solution to detect if a specific page of pdf is colored or grayscale | 17:27.40 |
| | and i was told after some time there would be people here who would be able to guide me in this regard | 17:29.17 |
| | i am using Visual Studio 2010 (C++/C#) - C# preferred | 17:29.45 |
| mvrhel_laptop | henrys: yes that is correct | 17:31.54 |
| | in that case, we would go to rgb | 17:32.03 |
| | amyn: using mupdf or gs? | 17:32.31 |
| | heading to coffee shop for change of venue.. bbiab | 17:33.22 |
| Robin_Watts | amyn: Did the mupdf binary I gave you not work? | 17:35.38 |
| amyn | Robin_Watts: yes the .exe u gave worked like a charm. | 17:38.27 |
| | but is it possible that i get the source code so i can integrate it into my application? | 17:38.50 |
| Robin_Watts | amyn: Yes, absolutely. | 17:39.04 |
| | git clone --recursive git://git.ghostscript.com/mupdf.git | 17:39.37 |
| | Then that'll have everything in it you need. | 17:39.49 |
| amyn | great. also, does mupdf provide pdf to image conversions? | 17:41.25 |
| Robin_Watts | mudraw -o out.png in.pdf | 17:41.41 |
| | For PDF (as opposed to PS) and for screen use, Mupdf is a better bet than gs, generally. | 17:42.25 |
| | For PS you need gs. | 17:42.31 |
| | For print, you're probably better off with gs too. | 17:42.43 |
| amyn | PS meaning? | 17:46.26 |
| Robin_Watts | postscript. | 17:46.41 |
| amyn | does mudraw allows controlling the output image dpi? also does it support outputting to .tiff? | 17:47.05 |
| Robin_Watts | yes, and ... no. I think. | 17:48.11 |
| | ppm, pam, png, but not tif, unless I'm forgetting. | 17:48.33 |
| | pnm and tga too. | 17:49.50 |
| chrisl | marcosw: are you here? | 17:55.34 |
| marcosw | chrisl: yes, i'm here | 18:05.58 |
| chrisl | Aha! | 18:06.07 |
| | I cannot reproduce that crash with BGPrint | 18:06.22 |
| marcosw | I was expecting you to say that :-) | 18:07.05 |
| | I'll see if I can reproduce it on peeves. | 18:07.05 |
| chrisl | Also, was that the smallest file it happens with? | 18:07.17 |
| marcosw | tests_private/comparefiles/246-01.ps | 18:09.00 |
| | that's with DEVICE=pkmraw | 18:09.28 |
| | I'm trying to see if valgrind finds anything, but it takes a long time to run and so far no seg faults with it. | 18:10.48 |
| | the only warnings are: | 18:10.56 |
| | ==10525== Conditional jump or move depends on uninitialised value(s) | 18:11.12 |
| | ==10525== at 0x96DF16: write_color_index (gsovrc.c:62) | 18:11.12 |
| | ==10525== by 0x96E168: c_overprint_write (gsovrc.c:151) | 18:11.12 |
| | ==10525== by 0x732577: clist_create_compositor (gxclimag.c:1465) | 18:11.12 |
| | ==10525== by 0x62276E: pdf14_clist_create_compositor (gdevp14.c:7378) | 18:11.12 |
| | ==10525== by 0x99B31F: gs_state_update_overprint (gsstate.c:647) | 18:11.12 |
| | ... | 18:11.13 |
| chrisl | Those are usually benign..... | 18:12.06 |
| marcosw | I assumed so, which is why I didn't update the bug with the info. | 18:12.35 |
| chrisl | Aha, I did get 246-01.ps to seg fault..... | 18:12.53 |
| marcosw | that's good news. | 18:13.04 |
| chrisl | But not so far with a debug build :-( | 18:15.08 |
| marcosw | yeah, I'm just trying that too. was thinking that's why the valgrind test never fails. | 18:15.35 |
| | I'll try a memento build. | 18:15.52 |
| chrisl | It's likely it's some kind of race condition, so anything that messes with the timing will be problematic | 18:16.31 |
| marcosw | I think that maybe it happens more if the cpu is really busy with other stuff. | 18:17.41 |
| mvrhel_laptop | looks like an image fill comes in with a clip path. need to do a bit of xps review. I used to know all this... | 18:17.48 |
| marcosw | never mind my last comment, testing shows that this is not the case. | 18:21.14 |
| mvrhel_laptop | henrys: question for you | 18:21.59 |
| henrys | mvrhel_laptop: there is some unsupported clipping I know about. Is that your question? | 18:22.54 |
| marcosw | chrisl: the memento build seg faults: | 18:23.02 |
| | *** glibc detected *** ./ghostpdl/gs/membin/gs: corrupted double-linked list: 0x0000000004cd5f80 *** | 18:23.04 |
| mvrhel_laptop | is it fine if I extend gdevvec.c a bit. I want to pass along some additional knowledge about what exactly a path is getting filled with. I.e. an image for example | 18:23.20 |
| marcosw | chrisl: I'll update the bug with the memento build stack trace, not sure if this is the problem, since it happens on page 1 and that never happens with the non-debug build. | 18:25.05 |
| chrisl | marcosw: okay, but I suspect this will have to go to Ray - as I said in the bug thread, there is no way the commit of mine you referenced can actually have caused this problem | 18:27.19 |
| | mvrhel_laptop: given the graphics library is largely based on the PS/PDF imaging model, I doubt it has a concept of a path being "filled" with an image | 18:28.11 |
| mvrhel_laptop | right. that is true now | 18:28.31 |
| marcosw | chrisl: presumably your commit just moved things around in memory. I'll reassign it to Ray. | 18:28.48 |
| chrisl | marcosw: I assume that's the case, yes. That commit was all PS changes, and only messed with how we create the contents of some fonts | 18:29.34 |
| henrys | mvrhel_laptop: I wouldn't fool with gdevvec voodoo... | 18:29.42 |
| mvrhel_laptop | chrisl: hence my desire to add a bit more information. During gdve_vector_begin_image, the clip path for the image is passed along to be drawn. I only want to add a bit more knowledge to the xps path logic that we are dealing with an image so that I can set the proper brush. | 18:30.14 |
| | right now I only have the current stroke or fill color. | 18:30.31 |
| | in this sense the xps stroke or fill color needs to be settable to other types. e.g. image | 18:31.05 |
| chrisl | mvrhel_laptop: but that path isn't "drawn" it's a clip | 18:31.13 |
| mvrhel_laptop | well, it will be "drawn" as a clip path in the xps mark up | 18:31.32 |
| | as part of the path that the image is going to fill | 18:31.40 |
| | essentially there will be a path with an image brush fill that also includes a clip path | 18:31.59 |
| | I realize it is not drawn | 18:32.16 |
| | but it certainly is used in the drawing | 18:32.22 |
| chrisl | I didn't think xpswrite was based on gdevvec.c anyway...... | 18:33.00 |
| mvrhel_laptop | it is | 18:33.06 |
| chrisl | My very vague memory is that if you fill a path in XPS with an image that isn't large enough, it will tile the image to fill the entire path | 18:33.46 |
| mvrhel_laptop | tell you what. I will push forward and I cause someone heartburn then we can deal with it at that time. | 18:33.57 |
| | chrisl: no. that depends upon your tiling settings | 18:34.19 |
| chrisl | It's most likely to break pdfwrite/ps2write..... | 18:34.19 |
| mvrhel_laptop | not if it is a parameter that those devices don't use | 18:34.33 |
| | they don't have to know anything about this | 18:35.17 |
| | it is essentially some extra information that only the xps device will be using | 18:35.38 |
| chrisl | Also, I can't remember how that stuff works: the clip path may not cover the entire image | 18:36.18 |
| mvrhel_laptop | that is certainly true | 18:36.50 |
| | hence the image drawing will consist of a path, with a clip path inside | 18:37.15 |
| | in the xps markup | 18:37.22 |
| | let me push on and see what breaks/explodes | 18:37.50 |
| | the code reviewer will have fun with this one | 18:38.49 |
| henrys | mvrhel_laptop: I'm confused you have a pattern as input? | 18:38.51 |
| chrisl | Can't you capture the information at the enumerator level? | 18:38.59 |
| mvrhel_laptop | henrys; no no no | 18:39.00 |
| | no patterns | 18:39.06 |
| | but we could have such a case later | 18:39.12 |
| | just an image | 18:39.21 |
| chrisl | marcosw: I suspect memento isn't thread safe :-( | 18:40.53 |
| mvrhel_laptop | but right now the vector device is passing along a clip path during the begin_image. So, the plan will be to go ahead and create the path for the image with the clip path and to set the brush to the image resource. right now though, there is really no knowledge that we are in the image fill situation during the path drawing | 18:41.04 |
| | instead it is always wanting to fill with a solid stroke or fill brush | 18:41.19 |
| | maybe I can do this differently | 18:41.49 |
| | hold on | 18:41.50 |
| | aha | 18:41.55 |
| | ok. I think I see how I can avoid fooling with the vector device | 18:42.06 |
| | ok . so you and chrisl can sleep well tonight ;) | 18:42.28 |
| henrys | mvrhel_laptop: I'm not following fillling a path with an image is a pattern? | 18:42.39 |
| mvrhel_laptop | during the xps_being_image, I will get the device set up with the proper brush | 18:42.51 |
| | henrys: there is no pattern | 18:42.59 |
| | just an image | 18:43.30 |
| chrisl | mvrhel_laptop: tbh, I was more worried that what you'd get from the graphics library wasn't what you were expecting in all cases, rather than you breaking other stuff | 18:43.47 |
| mvrhel_laptop | right. I think now I see how to do this. talking with you and henrys got me on track | 18:44.37 |
| chrisl | henrys: there is an image brush mode in XPS that, if the image is smaller than the path, it will tile image to fill the path - but that's not the same as a pattern (although similar) | 18:45.01 |
| henrys | -Z_ will show what clip paths are reaching the device as I recall, mvrhel_laptop | 18:45.39 |
| mvrhel_laptop | ok thanks henrys | 18:45.49 |
| chrisl | Robin_Watts: ping | 18:46.08 |
| Robin_Watts | pong | 18:46.23 |
| chrisl | Am I right in my assumption that memento isn't thread safe? | 18:46.39 |
| henrys | chrisl: I thought mvrhel_laptop was saying the input (PDF) was a path filled by an image which would be a pattern. I wasn't thinking about the XPS | 18:47.14 |
| Robin_Watts | Urm... | 18:47.15 |
| | probably not. | 18:47.40 |
| chrisl | henrys: right, cross purposes..... | 18:47.45 |
| Robin_Watts | It could be made so without too much problem. | 18:47.49 |
| chrisl | Robin_Watts: not a big deal, just double checking what I was seeing. | 18:48.23 |
| | Hmm, so we have a gdev_prn_put_params() in one thread and a igc_reloc_ref_ptr_nocheck() - my guess is that the garbage collector is moving stuff whilst the background rendering thread is trying to read it...... Oh my :-( | 18:53.56 |
| Robin_Watts | ouch. | 18:58.03 |
| mvrhel_laptop | off to lunch... | 18:59.31 |
| chrisl | And I'm done for the day..... | 19:00.23 |
| amyn | Robin_Watts: i cloned the git repo as u suggested, but in this case as well, all the folders in the third part folders are empty | 19:18.57 |
| rayjj | hi, all. | 19:28.59 |
| | Had a medical appt earlier. 2.25 hours there (in traffic) < 1 hr returning :-( | 19:29.35 |
| | I saw a discussion earlier about mono/color page detection. The bug 695298 has the "magic" args.gs that print out mono/color per page using Ghostscript | 19:33.01 |
| | chrisl_away: as far as changing text color using Ghostscript, we _do_ have the capability to use a separate ICC profile for text -sTextICCProfile=<path to profile> | 19:37.26 |
| rayjj | should have been here earrlier | 19:43.47 |
| | amyn: If you don't get what you want from mupdf, you can use the pre-built Ghostscript release candidate that chrsl mentioned with the command line in the above bug: http://bugs.ghostscript.com/show_bug.cgi?id=695298#c10 | 19:45.00 |
| amyn | rayjj: can you explain this a little? | 19:53.10 |
| | what command to run exactly to check if a page in a pdf file is colored or grayscale | 19:53.41 |
| rayjj | amyn: the comment (that I posted the link for) has the command line example | 20:00.39 |
| | amyn: gswin32c @args.gs yourfile.pdf | 20:01.26 |
| | amyn: that prints out the color/mono page detection (and even works with PostScript _or_ PDF input files) | 20:02.28 |
| amyn | will this tell page wise or for the whole document? | 20:03.03 |
| rayjj | amyn: so, if you have the Ghostscript example files: gswin32c @args.gs examples/colorcir.ps says: Page:1 is monochrome:false | 20:03.19 |
| | amyn: but gswin32c @args.gs examples/alphabet.ps says: Page:1 is monochrome:true | 20:03.55 |
| | amyn: each page is identified individually | 20:04.18 |
| | amyn: and gswin32c @args.gs examples/alphabet.ps examples/colorcir.ps prints out: | 20:05.13 |
| | Page:1 is monochrome:true | 20:05.15 |
| | Page:2 is monochrome:false | 20:05.16 |
| | (each of these PS input files has one page) | 20:05.44 |
| amyn | i get the following error: unable to open command line file args.gs | 20:06.39 |
| | i am using ghostscript 9.14 | 20:06.54 |
| rayjj | amyn: you have to get the file from the bug tracker (or cut and paste from the comment into that file). The easiest way is to get it from http://bugs.ghostscript.com/attachment.cgi?id=11110 | 20:08.09 |
| amyn | where should i paste this file? | 20:08.41 |
| rayjj | amyn: and, as I mentioned, you have to use the 9.15 release candidate *NOT* 9.14 -- 9.14 doesn't have the feature | 20:08.44 |
| | amyn: put it where you can find it :D -- I put such things in my "temp" folder c:\Temp (which you may or may not have) | 20:09.41 |
| amyn | but it should be in my working directory right? or should i add the path to my system variable path? | 20:10.28 |
| rayjj | if you do put it in c:\temp\args.gs then: gswin32c @c:/temp/args.gs yourfile.pdf | 20:10.28 |
| amyn | oh ok | 20:10.37 |
| | let me try | 20:10.41 |
| rayjj | it doesn't need to be on your path, or cwd if you explicitly give the absolute path starting with C: | 20:11.13 |
| amyn | where can i get the 9.15 release? | 20:11.25 |
| rayjj | one place is: http://www.ghostscript.com/~chrisl/gs915rc2w32.exe | 20:12.24 |
| | that's the 32-bit Windows installer version | 20:13.00 |
| | that puts the executable in: "C:/Program Files/gs/gs9.15/bin/gswin32c.exe" or if on 64-bit Windows, in: "C:/Program Files (x86)/gs/gs9.15/bin/gswin32c.exe" | 20:16.32 |
| amyn | ok so i was able to run the command without errors | 20:19.27 |
| | but the result is not accurate. | 20:19.35 |
| | muPDF is more accurate as per my testing | 20:23.25 |
| rayjj | amyn: Ghostscript uses a "threshold" of 5/255 as "close enough" | 20:23.26 |
| amyn | is there a way to improve this in ghostscript? is it possible to alter the threshold? | 20:23.59 |
| rayjj | amyn: Please attach your sample file to the bug 695298 so I can see what it might be. | 20:24.21 |
| | amyn: and mupdf doesn't handle colors the same as Ghostscript (gs generally is more "accurate" in color handling) | 20:25.15 |
| amyn | ok uploading it now | 20:25.31 |
| rayjj | amyn: but we'd be interested in "problem" files. | 20:25.47 |
| | I'm going to grab lunch. bbiab | 20:26.08 |
| amyn | btw, monochrome means black and whte? | 20:30.04 |
| | rayjj: btw, monochrome means black and white or grayscale? | 20:35.52 |
| chrisl_t530 | rayjj: I just couldn't leave Bug695483 alone, so I've done a bit more debugging, and posted a link to a commit with a couple of suggested changes | 20:45.12 |
| rayjj | chrisl_t530: OK. thanks | 20:45.32 |
| amyn | rayjj: i have uploaded the file to the bug 695298 | 20:49.35 |
| rayjj | amyn: thanks. I see it there | 20:51.19 |
| amyn | rayjj: btw, monochrome means black and white or grayscale? | 20:52.02 |
| rayjj | gray -- i.e. "neutral" | 20:52.46 |
| amyn | ok. are u testing the file that i uploaded? | 20:54.07 |
| rayjj | amyn: BTW, since the file says "CONFIDENTIAL" I marked that attachment "Private" (only Artifex staff can see it) | 20:55.39 |
| amyn | thanks. i was worried about that | 20:56.02 |
| rayjj | amyn: yes, I see that page 1 is wrong. I'll look at why... | 20:58.07 |
| amyn | error is not just page 1, page 10,11 says monochrome = false. this is also wrong | 20:59.08 |
| | and mudraw gives accurate result but is slower then gs | 20:59.59 |
| rayjj | amyn: interesting -- usually mudraw is faster :-/ | 21:01.12 |
| chrisl_t530 | rayjj: I've set a script running which is running the two files that marcosw indicated were seg faulting in an infinite loop, with the changes I came up with. The script will exit if it sees a seg fault | 21:02.07 |
| amyn | when i tested mudraw in my office, it was very quick for the same file but on my personal laptop its a little slow | 21:02.32 |
| | btw, what would u suggest: mupdf or gs? | 21:02.48 |
| rayjj | amyn: well if mupdf gives you the correct results, use it. Ghostscript is definitely wrong. There is "1 0.753 0 rg /GS0 gs 119.25 646.85 82.15 61.45 re f*" in the PDF that paints the "orange" rectangle. | 21:05.47 |
| | Page 1 has transparency, so probably the pageneutralcolor state isn't getting bubbled back out from the compositor | 21:06.35 |
| amyn | meaning there is some problem with the current gs version? | 21:06.39 |
| rayjj | amyn: yep. and it won't get fixed in this release (it's not a "blocker" type of bug). | 21:08.10 |
| | amyn: thanks for the file | 21:08.40 |
| amyn | ok no problem. i think mupdf would work for me | 21:09.03 |
| | no problem. i just hope i dont get into any trouble as i provided to few other forums for testing purposes | 21:09.38 |
| | btw, can u tell me how to convert that same pdf to .png (multiple files) using mudraw? | 21:10.24 |
| | and do u suggest using mudraw or gs for pdf to png conversions? | 21:10.47 |
| chrisl_t530 | mudraw in.pdf out%d.png should do it I think | 21:11.49 |
| amyn | chrisl_t530: thanks. do u suggest using mudraw for this or gs? | 21:13.23 |
| chrisl_t530 | oops, sorry, not quite: mudraw -o out%d.png in.pdf | 21:13.29 |
| amyn | yeah i got that. and it worked. :) | 21:13.46 |
| chrisl_t530 | amyn: that's a hard question to answer: although there is a lot of overlap, they really have different target audiences. | 21:14.16 |
| | For example, if you might need to support Postscript at some point, it has to be Ghostscript. | 21:14.39 |
| | If you need "production" quality color, it should be Ghostscript. | 21:15.07 |
| amyn | well what i want is this: open a pdf file, for each page, check if it is colored (using mudraw). if it is, then convert to .png else convert to .tiff grayscale | 21:15.30 |
| | i want to be able to control the output image dpi | 21:15.56 |
| chrisl_t530 | both mupdf and gs let you set the resolution | 21:16.14 |
| | IIRC, mupdf doesn't do tiff output. | 21:16.26 |
| rayjj | amyn: both use -r### | 21:16.30 |
| amyn | yes it doesn't. for that i can use gs. but png conversion takes time with mupdf | 21:17.04 |
| | and with gs as well. so which one is faster? | 21:17.16 |
| chrisl_t530 | Usually, mupdf is faster. | 21:17.38 |
| rayjj | amyn: TIFF compression takes time (if you use it) | 21:17.49 |
| | mupdf is _usually_ faster | 21:18.04 |
| | mudraw can write uncompressed (ppm) files quickly | 21:18.47 |
| amyn | well i do need to compress as size of the image files should be small | 21:19.18 |
| chrisl_t530 | Given you're having to use gs for tiff, for simplicity, I'd use it for both - but I like simplicity | 21:19.23 |
| amyn | and i want output images to be at 300 dpi which with mupdf is taking a lot of time | 21:19.42 |
| rayjj | amyn: what type of TIFF compression would you use ? | 21:19.50 |
| amyn | lzw may be | 21:20.12 |
| | or tifjpeg | 21:20.20 |
| chrisl_t530 | Nooooooo! | 21:20.33 |
| rayjj | chrisl_: yeah, but if it doesn't detect color correctly, mudraw -T -d would be the only way (until we get the bug fixed) | 21:20.54 |
| chrisl_t530 | rayjj: sure, that's not ideal..... | 21:21.21 |
| rayjj | amyn: JPEG is lossy. PNG (Flate) or LZW are lossless | 21:21.22 |
| chrisl_t530 | amyn: using jpeg compression defeats the point of using tiff..... | 21:21.55 |
| rayjj | but I don't think TIFF has Flate compression, and LZW is almost as good | 21:22.01 |
| | chrisl: right --- might as well just write the JPEG | 21:22.30 |
| chrisl_t530 | Exactly | 21:22.38 |
| amyn | what about this: TifJpeg411 the file size is very small at 300dpi | 21:23.24 |
| rayjj | our TIFF only supports: -sCompression=none | crle | g3 | g4 | lzw | pack | 21:23.47 |
| amyn | in my current implementation that uses gs for tiff as well as png, tiff is using compression ccit g4 but isn't it for bitonal only? and not for grayscale? | 21:25.06 |
| chrisl_t530 | Yes, 1 bit only | 21:25.26 |
| | You can use lzw or packbits with 8 bit | 21:25.38 |
| amyn | so is it possible with mudraw? | 21:26.07 |
| | or gs only? | 21:26.10 |
| chrisl_t530 | Is what possible? | 21:26.19 |
| amyn | tiff export | 21:26.29 |
| rayjj | amyn: if you tell gs to use the tiffg4 device, you will get halftoned bitonal output | 21:27.04 |
| amyn | meaning it wont be grayscale? | 21:27.28 |
| rayjj | i.e., shades of gray will be shaded as patterns of dots (halftone pattern) | 21:27.45 |
| chrisl_t530 | amyn: mudraw doesn't do tiff, no | 21:28.10 |
| rayjj | and all of the dots will be either 100% black or white | 21:28.11 |
| | mupdf doesn't do bitonal halftoning, either | 21:28.42 |
| amyn | ok so i think i will suggest the following to my superiors: use mudraw to detect if a page is colored or not. if its not, use gs with tiffg4 device and save as .tiff. if the page is colored, either use gs or mudraw or leadtools(i tested it and results are pretty good) | 21:29.33 |
| | what do u say guys? | 21:29.41 |
| chrisl_t530 | amyn: well, hopefully, it won't be long before gs color detection is fixed, and if you can build it yourself, you don't have to wait for the next release..... | 21:31.07 |
| rayjj | using tiffg4 won't be gray (just halftoned b&w), but it _will_ be a LOT smaller than -sDEVICE=tiffgray -sCompression=lzw | 21:31.14 |
| amyn | chrisl_t530: can you tell me how can i build it myself? | 21:32.12 |
| rayjj | amyn: you probably want to compare the output of mono pages between tiffg4 and tiffgray (lzw) for quality / size tradeoff | 21:32.39 |
| chrisl_t530 | amyn: sure, it's not hard.... | 21:32.49 |
| rayjj | amyn: build which ? | 21:32.51 |
| | (I think Robin already has told you how to build mudraw) | 21:33.13 |
| amyn | rayjj: yeah i agree. well that is something which is not a problem right now | 21:33.18 |
| chrisl_t530 | amyn: but not right now - it's getting quite late for me | 21:33.25 |
| amyn | chrisl_t530: sure. what time suits u? its late for me too right now | 21:34.02 |
| rayjj | and you don't need to build ghostscript yet because the bug isn't fixed yet. When it is you can use gs for page color detection as well as for rendering | 21:34.12 |
| amyn | rayjj: yes i know how to build mudraw | 21:34.32 |
| chrisl_t530 | amyn: I'm based in the UK, so approximate European office hours are best the time to get me | 21:34.57 |
| amyn | chrisl_t530: will u be available after 10 hours? or even later? | 21:35.34 |
| rayjj | amyn: building gs is also easy -- download the source (http://git.ghostscript.com/?p=ghostpdl.git;a=snapshot;h=ed4a0d170a7872077231a794e099c8c0c7bca34d;sf=tgz) | 21:35.40 |
| amyn | i'm based in pakistan | 21:35.47 |
| | is it possible to access the above chat later? for my reference? | 21:36.53 |
| chrisl_t530 | I usually start work quite early, so I'll be around again in about 9 hours | 21:37.03 |
| rayjj | then from Visual Studio open the ghostscript.vcproj (from the top directory), let it convert the project if needed, then use Build/Configuration Manager to select release (and 32 or 64 bit) and "Build" | 21:37.24 |
| amyn | chrisl_t530: great. that time is perfect for me | 21:37.55 |
| chrisl_t530 | amyn: this channel is logged, yes: http://ghostscript.com/irclogs/ | 21:38.10 |
| rayjj | amyn: and chrisl: good night (I'll be up for many more hours since I'm on the west coast of the US -- 2:40pm here) | 21:38.48 |
| amyn | chrisl_t530: rayjj: thanks u guys. u people have been really helpful. really appreciate. have a nice day :) | 21:39.19 |
| rayjj | but I (most likely) won't be 10 hours from now | 21:39.37 |
| amyn | its 2:40 a.m. here :P | 21:39.44 |
| rayjj | amyn: thanks | 21:39.49 |
| chrisl_t530 | rayjj: FYI: the script testing the BGPrint change is still running, so neither file has seg faulted - I'm leaving it running over night | 21:40.04 |
| | rayjj: have a good afternoon! | 21:40.58 |
| Robin_Watts | amyn: I can't agree with your suggestion. | 23:24.37 |
| | Just because a page is greyscale doesn't mean that it's a good idea to render it in monochrome. | 23:24.54 |
| | For screen use you want to render it to a greyscale bitmap. | 23:25.24 |
| | (For the logs on the offchance he reads them) | 23:25.36 |
| | Forward 1 day (to 2014/09/18)>>> | |
IRC Logs