| | <<<Back 1 day (to 2015/10/27) | 20151028 |
| ManDay | Is it possible to make mupdf call something other than "xdg-open" when clicking a link? | 10:23.30 |
| kens | Yes, its a simple matter of coding I should think | 10:23.56 |
| bvx89 | Hi, can anyone point me in the direction of how I can adjust the JPEG quality when writing to a PDF? | 10:26.21 |
| kens | bvx89 MuPDF, Ghostscript, something else ? | 10:26.38 |
| bvx89 | ghostscript | 10:26.43 |
| | ps2pdf, I assume | 10:26.50 |
| kens | I wouldn't think so | 10:27.00 |
| | Tell me what you rcurrent Ghostscript command line is | 10:27.13 |
| bvx89 | gs -dBATCH -dNOPAUSE -dPDFA=1 -sColorConversionStrategy=RGB -sProcessColorModel=DeviceRGB -sDEVICE=pdfwrite -dPDFACompatibilityPolicy=1 -dAutoFilterColorImages=false -dColorImageFilter=/DCTEncode -dPDFSETTINGS=/$5 -sOutputFile=$2 $3 $4 -c "($1) << /PageSize 2 index viewJPEGgetsize 2 array astore >> setpagedevice viewJPEG" | 10:27.32 |
| kens | Oh, and what's the nature of your input ? | 10:27.38 |
| bvx89 | This is from a bash-script | 10:27.40 |
| kens | I can't read bash | 10:27.49 |
| ManDay | kens: ok | 10:28.02 |
| bvx89 | $1 is input jpeg, $2 is output path, $3 is the path to PDFA_def.ps, $4 is the path to viewjpeg.ps | 10:28.34 |
| kens | If you are using pdfwrite, and you specifically want JPEG in the output PDF then you want to alter teh ColorImageDict | 10:28.46 |
| bvx89 | And $5 is my attempt at using dPDFSETTINGS and setting it to different presets, but no effect | 10:29.08 |
| kens | If you are reading a JPEG as the input then you specifically *DON'T* want to use JPEG as the output | 10:29.11 |
| | Set the COlorImageFilter to FlateEncode | 10:29.29 |
| bvx89 | Well, the resulting PDF gets huge | 10:29.49 |
| kens | If your input is JPEG, then when you write a JPEG in the output, it will suffer badly from compression artefacts | 10:30.23 |
| ManDay | kens: in fact, the code already has it. BROWSER env var | 10:30.29 |
| tor8 | ManDay: set the BROWSER environment variable | 10:30.31 |
| ManDay | thanks | 10:30.32 |
| | tor8: you're too late ;-P | 10:30.39 |
| kens | All the losses in the original JPEG will be magnified by the second quantisation process | 10:30.42 |
| | In addition to adding new ones. | 10:30.58 |
| bvx89 | I understand | 10:31.19 |
| kens | So if your input is JPEG, there's no way to get decent output in JPEG, unless you simply don't alter the input JPEG at all. pdfwrite is not currently capable of ths | 10:31.33 |
| | If all you want to do is wrap up a JPEG as a PDF file then there are probably other tools whch will do it, it isn't hard | 10:32.23 |
| bvx89 | Well, I need it to be PDF/A1-b compliant | 10:32.51 |
| kens | That's harder | 10:33.02 |
| | If the JPEG image is in the wrong colour space, tehn you have no choice but to decode it and convert it to the desired colour space | 10:33.29 |
| bvx89 | Yes, that's why I needed the PDFA_def.ps file | 10:33.31 |
| | And can I do that without losing to much data from the JPEG? | 10:33.53 |
| kens | No | 10:34.04 |
| | The decoding and re-encoding process is wheret he4 problem almost certainly lies | 10:34.22 |
| | In order to avoid that, you can decode the JPEG and then re-encode with something other than JPEG but then the resutling image will be larger. | 10:35.42 |
| bvx89 | Well, I don't visually see any artifacts on the output, I used the pdfimages tool to export the jpg from the PDF, and graphicmagicks tool to check the quality parameter for the jpeg which is defined as 55 | 10:36.13 |
| | It seems quite low | 10:36.55 |
| kens | I was assuming you had a problem with the quality. If you don;t have a problem with the quality, why do you want to change the settings? | 10:36.58 |
| bvx89 | I was using a very large file, approx. 100MB, and the resulting file was 15MB | 10:37.38 |
| kens | THen almost certainly you have triggered image downsampling | 10:38.00 |
| | A NJPEG wrapped up as a PDF is not going to be smaller then the original JPEG | 10:38.30 |
| bvx89 | I do have to decode and encode it to get the correct color profile (as you said), so is it at that point that the downsampling happens? | 10:39.41 |
| kens | No, you only have to decode it and re-encode it if the otiginal image isn't in the desired colour space (eg its RGB and you want a CMYK PDF/A) | 10:40.16 |
| | The downsampling happens when writing the image to the intermeditate temporary file, but it doesn't really matter when it occurs | 10:40.57 |
| | Look at the original JPEG< get its dimensions, look at the JPEG in the PDF file, compare its dimensions | 10:41.22 |
| bvx89 | Okay | 10:41.32 |
| kens | But I@m not clear on what your actual problem is. If the quality isn't a problem for you, why bother to change anything ? | 10:41.47 |
| bvx89 | Well, it's not a problem for me, but the requirements for the project was that it should be possible to adjust the quality of the output | 10:44.05 |
| | Okay, so I have checked and the resolutions are the same | 10:44.16 |
| kens | You can (as I said earlier) modify the COlorImageDict to change the 'quality' | 10:44.59 |
| bvx89 | However, ColorImageResolution is set to 72 instead of 300 | 10:45.13 |
| | So it seems as though -dPDFSETTINGS=/prepress doesn't have any effect? | 10:45.47 |
| | Well, my output file became over 200MB when I used FlateEncode | 10:46.31 |
| kens | You can't reasonably mix and match -dPDFSETTINGS and individual controls, at least not unless you have a very clear idea what you are doing. In practice if you want control over your output, don't use PDFSETTINGS | 10:46.37 |
| | ColorImageResolution is hte resolution which the image is downsampled to if it exceeeds the ColorImageDownsampleThreshold, *and* DownsampleColorImages is true | 10:47.44 |
| bvx89 | Well, I haven't changed that, and the default is false | 10:48.21 |
| kens | Not if you start playing with PDFSETTINGS | 10:48.50 |
| bvx89 | But I only used the /prepress property. Both that and the default property is set to false according to the documentation | 10:49.34 |
| kens | You said you'd tried 'various' settings | 10:49.47 |
| | 'differeing presets' in fact | 10:50.04 |
| | Seems to me you are discovering that there are an awful lot of parmaters, they interact in subtle ways, and you don't really know whjat they all are doing. | 10:50.32 |
| bvx89 | yes, that was to see if the quality of the output jpeg came out differently | 10:50.43 |
| kens | YOu need to figure out what it is you want to achieve | 10:50.44 |
| bvx89 | That is very true | 10:50.49 |
| kens | And then consider which parameters you need to alter to achieve your goal | 10:51.08 |
| | Startign fomr an image, the output PDF will only contain image data, so you need to look at the various paramters which affect that. I wouldn't mess with -dPDFSETTINGS, because it will (in the location you've put it) override the paramteres you have set previously on the command line | 10:52.08 |
| | And it changes a wholw slew of options, many of whch you don't care about | 10:52.33 |
| | SO just dro it altogether, use the defaults, and change the ones you need to | 10:52.48 |
| bvx89 | Alright, I will follow your advice | 10:52.59 |
| kens | The ones you will be intrested in mainly will be COlorImageDict, ColorImageDepth, ColorImageFilter, ColorImageDownsampleThreshold, ColorImageDownsampleType, ColorImageResolution, EncodeColorImages, DownsampleCOlorImages | 10:54.09 |
| | Note that the content of ColorImageDict varies depending on the COlorImageFilter | 10:54.34 |
| | However note 7 to 10 in the documentation contain examples for DCTEncode | 10:55.00 |
| | Hmm, interesting, the customer bug report only seems to fail with TiffG4, the display device is correct at 600 dpi | 10:56.24 |
| bvx89 | Hmm... Yes, I remember reading about QFactor, VSamples and HSamples for JPEG quality | 10:56.24 |
| kens | Right. | 10:56.30 |
| bvx89 | So what do I specify in the commandline if I want to achieve the note 9 quality specification? | 10:58.08 |
| bvx89 | going to lunch | 10:58.27 |
| kens | You need to add a setdistillerparams call, because you can't set dictioanry values on the command line | 10:58.54 |
| | Hmm jpeg output fails as well as tiff output | 11:00.17 |
| | I wonder if this is a clist problem | 11:00.46 |
| tor8 | Robin_Watts: kens: question about MSVC... in the project properties, I set "Compile As" to "C++". The Command Line properties update to use /TP. | 11:00.58 |
| kens | OK | 11:01.09 |
| tor8 | but when building, and in the BuildLog.htm that gets generated ... it's using /TC | 11:01.11 |
| kens | Presumably ths isn't Ghostscript :-) | 11:01.31 |
| tor8 | no, it's MuPDF's project files I'm messing with | 11:01.43 |
| kens | Did you set it for the current configuration ? | 11:01.53 |
| tor8 | Yes. I set it for all configurations. | 11:02.07 |
| kens | Hmm, odd | 11:02.12 |
| tor8 | Very odd. Is there an override setting somewhere? | 11:02.26 |
| chrisl | And for each sub-project? | 11:02.27 |
| kens | Well as chrisl says, the sub projects can override it | 11:02.41 |
| | So if they have it specifically set they won't inherit the parent | 11:02.57 |
| tor8 | the project hierarchy in the mupdf solution is very flat | 11:03.44 |
| kens | I'm having trouble finding the solution in my (old) MuPDF sources | 11:04.06 |
| | let me update it | 11:04.17 |
| | Oh ths may take a few minutes | 11:05.06 |
| | <sigh> And now it wants to convert the solution | 11:05.58 |
| | OK so where in the project properties are you looking tor8 ? | 11:06.47 |
| tor8 | huh. if I set it to something non-default and then back to C++ it seems to trigger properly. | 11:06.49 |
| kens | Weird | 11:06.56 |
| tor8 | something must be overriding the 'default' setting | 11:07.01 |
| | looked at the .vcproj file and after setting compile as C (which added a key CompileAs="1" to the project file) | 11:07.23 |
| | and then back, it leaves a key CompileAs="2" and now it seems to do what I expect | 11:07.36 |
| | stupid microsoft crap :) | 11:07.43 |
| kens | Well I guess if its working..... | 11:07.49 |
| tor8 | ... yeah, now I'll leave it alone and go for lunch. | 11:08.09 |
| kens | FWIW hte project I just opened here has the command line set wioth /TP already | 11:08.20 |
| | MuPDF debug build | 11:08.33 |
| chrisl | tor8: before you push the commit, close and reopen and make sure the setting has stuck.... I had problems with changes disappearing a while back | 11:09.19 |
| tor8 | chrisl: thanks, will do | 11:10.20 |
| chrisl | WTF, the entire content stream in a fairly complex PDF all on one "line"!?!? And this is the second PDF like that I've encountered in as many days! | 11:45.50 |
| kens | I thnk its a clist problem | 11:46.01 |
| | Oh perhaps not | 11:46.18 |
| chrisl | I (think) I ran it without clist and it still shows the problem | 11:46.54 |
| kens | The windows display device renders it correctly at 600 dpi, the other rendering devices don't | 11:47.02 |
| | I've cut the file down, its till stupidly complex | 11:47.22 |
| | It has a page with a form both of which have (useless) transparency groups | 11:47.41 |
| chrisl | Yep, 'cause I'd also thought it might be a transparency problem..... | 11:48.10 |
| kens | It still might be, I'm going to cut those out now | 11:48.25 |
| chrisl | Running with -dNOTRANSPARENCY did not (meaningfully) change the output | 11:48.58 |
| kens | Yeah but if its something in the PDF interpreter, removing the groups might be important | 11:49.24 |
| | Apparently the producer is Python PDF Library, which probably explains a lot | 11:49.42 |
| | Well removign all the transparency made no difference | 11:52.33 |
| | THe bizarre co-ordinate system doesn't make it any easier to figure out either | 11:53.49 |
| chrisl | Clearly not a problem with the actual font, since it's not embedded........ | 12:07.50 |
| kens | Doesn't *seem* to be a problem with teh PDF interpreter, as far as I can tell | 12:10.25 |
| | I wonder if its something to do with the werid co-ords | 12:10.35 |
| chrisl | Well, weirdly, I get more calls to the glyph rendering code for the 600 dpi case than the 300 dpi case | 12:11.18 |
| kens | THat's strange | 12:11.30 |
| Robin_Watts | In clist mode ? | 12:16.00 |
| chrisl | What in clist mode? | 12:16.19 |
| Robin_Watts | "I get more calls to the glyph rendering code for the 600 dpi case than the 300 dpi case" | 12:16.39 |
| chrisl | clist is irrelevant to that | 12:16.50 |
| Robin_Watts | In clist mode, at 600dpi, we'll have bands 4 times as thin than at 300dpi, so more text will be split into 2 bands. | 12:17.06 |
| chrisl | "Text" doesn't survive the clist | 12:17.26 |
| kens | Lunch..... | 12:21.03 |
| chrisl | But that difference does not seem relevant, either, because disallowing "external" font substitutions gives the same problem without the out, but equal calls to the glyph rendering code | 12:21.10 |
| bvx89 | kens: Thanks for the help, finally got it to work now | 13:24.52 |
| kens | good nes :-) | 13:29.56 |
| | news* | 13:29.59 |
| | One for tor8 and Robin_Watts : | 13:55.07 |
| | http://stackoverflow.com/questions/33390735/extract-text-of-the-current-page-from-a-pdf-using-mupdf | 13:55.07 |
| tor8 | Robin_Watts I think, it's java and android | 14:03.01 |
| chrisl | I'm stepping out for a bit - try to shake of a headache. bbiaw...... | 14:18.33 |
| Robin_Watts | kens: He's answered it himself. | 14:29.00 |
| kens | That's handy :-) | 14:29.11 |
| | you sure its right ? Sometimes people make bad answer posts and that juts comes back to haunt me as they turn up in searches | 14:29.51 |
| | kind of looks sensible though | 14:30.41 |
| bvx89 | kens: Okay, so I can adjust the image quality now, but it doesn't seem like I am able to change the DPI attribute | 15:13.07 |
| henrys | marcosw: I believe I have added my machine to the cluster. The readme needs some sprucing up. I'm probably missing something but I'll discover what that is soon shortly. I could not find the scripts cluster_nmake.bat and cluster_md5sum.bat, I don't know if those are obsolete or what. | 15:14.32 |
| kens | bvx89 : the Resolution of the image can't be increased above the original | 15:22.11 |
| | If you want it decreased then you need to alter teh ColortImageDownsampleThreshold and select a ColorImageDownsampleType | 15:22.42 |
| | And then a ColorImageResolution | 15:22.52 |
| bvx89 | I don't want it to be increased, I want it to stay the same | 15:23.16 |
| kens | It won't be changed | 15:23.24 |
| bvx89 | It goes from 400DPI to 72DPI | 15:23.27 |
| kens | A JPEG can't really have a resolution | 15:23.38 |
| | It just has image samples | 15:23.43 |
| | When it is printed then it is spread across a section of media and you get the resolution by dividing the number of image samples by the width/height in inches | 15:24.18 |
| bvx89 | Yes, so the DPI is just a attribute that is set in the JPEG-s metadata | 15:24.49 |
| | an* | 15:24.52 |
| kens | pdfwrite defaults to 72 dpi, so I imagine that viewjpeg.ps is drawing the JPEG at a size and location which makes it come out that way | 15:24.54 |
| bvx89 | Ah, so I have to alter viewjpeg.ps then | 15:25.10 |
| kens | Well possibly | 15:25.16 |
| bvx89 | It's probably overwriting my distillerparams | 15:25.25 |
| kens | No, defintely not | 15:25.33 |
| | It will be calling setpagdevice to set the media size though | 15:25.48 |
| | You could also change the default resolution of pdfwrite | 15:25.59 |
| bvx89 | -r? | 15:26.07 |
| kens | yes | 15:26.10 |
| bvx89 | Didn't work | 15:26.16 |
| kens | THen its something else | 15:26.22 |
| bvx89 | Would it help if I gave you the command I'm using now? | 15:31.53 |
| kens | Probably not | 15:32.05 |
| | You need to take your JPEG file, walk through viewjpeg.ps and see what its doing | 15:32.19 |
| bvx89 | Alright | 15:33.03 |
| chrisl | viewjpeg.ps doesn't call setpagedevice | 16:10.44 |
| kens | OH well it must just scale the JPEg to the current media then I guess | 16:10.59 |
| bvx89 | I'm using the last command in viewjpeg.ps | 16:11.29 |
| chrisl | Right, so you are explicitly doing setpagedevice yourself | 16:11.45 |
| bvx89 | Well, I don't know PostScript, so I'm not sure what is happening | 16:12.11 |
| | All I know is that it changes the JPEG's DPI property | 16:12.39 |
| kens | Earlier you said : | 16:13.01 |
| | << /PageSize 2 index viewJPEGgetsize 2 array astore >> setpagedevice viewJPEG | 16:13.01 |
| bvx89 | Yes, that's the one I use | 16:13.12 |
| kens | There's a setpagedevice in there so you are setting the media size. | 16:13.12 |
| | Using setpagedevice | 16:13.19 |
| | Assuming viewjpeg.ps scales the jpeg to fit the requested media, then the DPI of the result will be dependent on the number of image samples and the size of the media | 16:13.53 |
| chrisl | As kens said earlier, images in PDFs don't have an inherent DPI | 16:14.20 |
| kens | And as I said before, jpeg images can't have a resolution, just dimensions | 16:14.27 |
| | echo :-) | 16:14.36 |
| bvx89 | Really? | 16:14.49 |
| kens | Yes really | 16:14.54 |
| | How can a jpeg have a resolution ? It doesn't have a media size, just a number of xsamples in the x and y directions | 16:15.20 |
| | The resolution depends on how many of those you print in each inch | 16:15.33 |
| | If I print a 600 sample wide image at 600 dpi, it will be one inch wide | 16:15.48 |
| | If I print it at 300 dpi it will be 2 inches wide | 16:15.59 |
| | Or I can fix the media size, and then the resolution depends on that. | 16:16.20 |
| tor8 | kens: actually, there's a way to encode resolution in the EXIF tag for JPEG which XPS uses | 16:16.33 |
| kens | If I print a 600x600 sample JPEG to a one inch square, then it will be 600 dpi | 16:16.43 |
| | tor8 yes but that's metadata | 16:16.52 |
| bvx89 | Yes, it's the EXIF tag i want to keep | 16:16.53 |
| tor8 | and in the APP13 marker | 16:16.56 |
| kens | bvx89 : you can't | 16:17.00 |
| tor8 | kens: XPS uses that metadata to position and size the image on the page... | 16:17.13 |
| kens | We won't write it as far as I recall | 16:17.18 |
| | tor8 with XPS that doesn't surprise me, what does it do if its missing ? | 16:17.37 |
| bvx89 | So all EXIF tags will be removed? | 16:17.40 |
| Robin_Watts | kens: JFIF contains X and Y pixel densities. | 16:17.57 |
| tor8 | kens: it looks in three places, in descending priority. EXIF, APP13 and then finally the JFIF wrapper | 16:18.02 |
| kens | We decode the image into raw samples, and tehn re-=encode them to a brand new image, *everything* gets washed clean | 16:18.05 |
| | Well we are talkign about viewjpeg.ps whch doersn't look at any of that | 16:18.40 |
| Robin_Watts | I like to think that images with resolutions (rather than dimensions) in them specify a 'suggested' or 'source' resolution. | 16:18.57 |
| bvx89 | Yes, I agree | 16:19.12 |
| kens | Possibly, you can certainly resize them after the fact. | 16:19.13 |
| Robin_Watts | Clearly kens is right when he says the resolution within a jpeg file does not necessarily have any bearing on how it will appear when displayed in any given program. | 16:19.29 |
| kens | And it doesn't affect the point at all. You cannot use such information from a JPEG file, and 'preserve it' because the image we write out isn't the image you put in. | 16:19.46 |
| | It just looks the same. And in the case of JPEG in to JEPG out, even that isn't true | 16:20.14 |
| bvx89 | Understood | 16:20.42 |
| | I was told by the one in charge of this project that he had problems with DPI in PDF's before | 16:21.17 |
| | He could not remember what, but based on what you're saying it shouldn't be a problem | 16:22.03 |
| chrisl | Well, PDF is scaleable, by design, so...... | 16:22.05 |
| bvx89 | Yes, and I'm aware that DPI for the JPEG is only a description of how big the JPEG was during the initial scan (it's mostly scanned documents). | 16:24.50 |
| kens | Jesus, now we have to read some crappy broken PDF file because the *current* version of Acrobat seems to, even though older versions do worse than us :-( | 16:25.28 |
| chrisl | kens: are you still hacking on 696305 ? | 16:26.31 |
| kens | No I left that one with you | 16:26.53 |
| | Unless you think it should be mine ? | 16:26.59 |
| chrisl | I don't know, at this stage - can I have your cut down file? | 16:27.18 |
| kens | Sure, one moment | 16:27.24 |
| | It also has the transparency groups removed | 16:27.32 |
| chrisl | It just saves me repeating the same steps | 16:27.54 |
| kens | OK its on the way | 16:28.40 |
| chrisl | Ta | 16:28.43 |
| kens | Its only 9k now | 16:28.44 |
| | My next step was going to be to reduce the media size to see if that affected it | 16:29.08 |
| | chrisl if I reduce the media size then the text appears once more | 16:39.47 |
| | All I did was hack out the rotate and change the vertical size of the media | 16:40.06 |
| | D'Oh forgot the resolutoin.... | 16:40.24 |
| | Oh, no I didn't its there | 16:40.33 |
| | What's the magic incantation for running with clist forced on ? | 16:41.16 |
| chrisl | It's really strange: at 599 dpi and 600 dpi the text disappears, but at 598 and 601 it displays..... | 16:41.59 |
| Robin_Watts | -dMaxBitmap=1000 | 16:42.05 |
| kens | Thanks Robin_Watts | 16:42.11 |
| | WSell its still present with the reduced media size, even if I force clist mode | 16:42.45 |
| | Aha! Removing the /Rotate, the text renders at 600 dpi | 16:45.24 |
| | SO I thnk its something CTM related, maybe, perhaps.... | 16:45.37 |
| | chrisl I'm starting to feel pretty bad again so I'm off now, let me know if there's anything else | 16:47.56 |
| | I'll read the logs later | 16:48.07 |
| mvrhel_laptop | bbiab | 17:03.21 |
| henrys | mvrhel_laptop: I'm looking at the Marvell 6270 board block diagram and I see a big GPU. Are you certain GG is not using that. Did you ask MQ? | 17:26.31 |
| mvrhel_laptop | henrys: I did ask him if they were using any of the specialized hardware on the board and he said no. But that was about the specialized hardware for color, halftoning etc. It is possible they are using the GPU. I am supposed to chat with him this week. He just got back from Korea. I will follow up with him today | 17:28.37 |
| | finally found the crash issue with 696290 | 17:28.59 |
| | gx_hl_fill_linear_color_scanline is relying upon the device bit depths in its calculation. psdcmyk and tiffsep are not setting up that information in their color info for some reason | 17:30.55 |
| henrys | mvrhel_laptop: I'm sure I'm missing something but nothing should work without a bit depth? | 17:33.31 |
| mvrhel_laptop | henrys: I would have thought so too | 17:33.42 |
| | they are planar devices which may have been assumed to be 8bit | 17:34.30 |
| | in other parts of the code | 17:34.41 |
| | It took forever to find this, and when I did I thought that is odd | 17:35.13 |
| | I am going to fix on the device setup side | 17:35.59 |
| | hmmm it is specified in the def. | 17:36.48 |
| | need to dig a bit more | 17:36.54 |
| | oh interesting. Since these devices are defined in their body as being GX_CINFO_SEP_LIN then check_device_separable, which sets up some of the color info in regard to the bit depth in each colorant, never happens. This function assumes everything is known in this case | 17:48.31 |
| | It is a bit of a special case. Since there is no comp_shift to set up for example | 17:48.53 |
| | since we are planar | 17:49.07 |
| | I suppose it falls upon the device to set up comp_bits itself | 17:49.27 |
| | which for these devices would be an array of 8s | 17:49.43 |
| | I need to do this for the psd devices and tiffsep | 17:50.16 |
| | it is rather surprising that we had not run across this before. I guess the only place this is coming up for the planar devices is in the shading smoothness calculations. | 17:50.59 |
| diemex | I have been trying to get mupdf to work as a android library project all day long and it just doesn't work. Either it can't load the system library or it can't find the MuPDFCore open function or it can't find the MuPDFCore.java file. :'( | 18:07.31 |
| Robin_Watts | diemex: By "android library project" do you mean some kind of packaging so that it can easily be reused in other projects ? | 18:09.49 |
| bvx89 | I don't know if it was anyone that's still in here, but someone posted a github gist a while ago for including JPEG in a PDF without having to resample the picture. Does anyone have a link for that? | 18:10.06 |
| Robin_Watts | bvx89: This channel is logged. If it was here, there will be a record of it in the logs. See the link at the top of your irc client :) | 18:10.45 |
| bvx89 | aaah | 18:10.58 |
| | Reading comprehension is a good thing | 18:11.13 |
| chrisl | Of course, you won't get PDF-A out of that...... | 18:11.46 |
| diemex | Robin_Watts, no I meant as an android library gradle module. Previously I just copied the .so file and the java files into my application module. But now I would prefer it to be in a seperate gradle module. | 18:11.48 |
| bvx89 | I am aware, but I need a temporary solution | 18:12.05 |
| chrisl | Well, there is no solution that allows PDF-A in the general case, without resampling | 18:13.01 |
| bvx89 | chrisl: Yeah, I wanted to just be able to make PDF's without loss at first, and then perhaps figure out the resampling later (what algorithm to choose and such) | 18:18.01 |
| chrisl | bvx89: fair enough | 18:18.37 |
| bvx89 | Does the jpeg tags get removed after i convert to PDF/A-1b no matter what I do? | 18:19.22 |
| chrisl | bvx89: It depends. Anything that requires the JPEG to be decoded and re-encoded will almost certainly lose the tags | 18:20.21 |
| | I confess, I don't really see why you need to keep the tags, anyway..... | 18:21.00 |
| bvx89 | Well, I asked my manager about it. When the output pdf had the wrong dpi, Acrobat Reader couldn't print the document to the right size (A0) | 18:22.47 |
| | But when the image inside the PDF had the correct tag, the A0 option was available | 18:23.13 |
| chrisl | Page sizes are stored in the PDF, and have nothing to do with the image data inside it. I strongly suspect the tags difference was coincidental, and the real issue was the media size(s) in the PDF | 18:24.53 |
| bvx89 | Hmm... Is there any easy way to check for the media sizes of a PDF? | 18:27.24 |
| | So that I can see if there's any difference | 18:27.33 |
| chrisl | gs comes with a utility file called in pdf_info.ps (in the "toolbin" directory) which outputs the "boxes" | 18:28.45 |
| bvx89 | Nice, will check it out tomorrow. Thanks :) | 18:29.22 |
| chrisl | As with viewjpeg and co, there are comments in the file which show how to use it | 18:29.45 |
| mvrhel_laptop | marcosw: I committed a fix for the error in 696290. Hopefully that will be the end of the bug | 18:33.49 |
| bvx89 | Yes, I've read the comments, but I don't know what to alter in the code if I wanted to do so. | 18:39.08 |
| chrisl | bvx89: You shouldn't need to alter the code, just at the top of the file is a comment with an example command line for how to use the utility | 18:41.34 |
| bvx89 | Yeah, and as for viewjpeg.ps I used the last script in order to insert a JPEG into the PDF and have the page size fit around the JPEG | 18:42.53 |
| henrys | tkamppeter: my friend thought the generic gdi printer driver would work. | 19:30.24 |
| mvrhel_laptop | lunch time. | 19:31.37 |
| jogux | https://pspdfkit.com/blog/2015/pspdfkit-ios-5-0/ is interesting - apparently they wrote their own pdf parser now, and have 20+ engineers working on their product | 19:32.56 |
| | parser+renderer I mean. | 19:33.42 |
| tkamppeter | henrys, there is no generic GDI driver in GS, the output device named "gdi" is for a series of GDI printers by Samsung. | 20:23.13 |
| henrys | tkamppeter: he just said he recalled this driver worked: http://www.openprinting.org/printer/Generic/Generic-GDI_Printer... I have no idea if it uses gs or not. | 20:32.25 |
| rayjj | mvrhel_laptop: I updated bug 695277 with the info that transparency_example.ps is not expected to work on any other PS interpreter other than Ghostscript since it uses our custom extensions | 21:21.45 |
| mvrhel_laptop | rayjj: ok thanks. | 21:21.57 |
| | looking like the error is caused by the usual mix-up in clist color writing/reading | 21:22.32 |
| rayjj | mvrhel_laptop: the PS is fairly easy to read since it was hand written | 21:22.37 |
| mvrhel_laptop | should have a fix soon I hope | 21:22.49 |
| rayjj | mvrhel_laptop: not again/still :-( | 21:22.53 |
| | it's such a simple file, just doing setrgbcolor and rectfill that I'm surprised that it causes problems (that we haven't seen before) | 21:23.56 |
| | and I'm surprised that problems are just showing up now with that file. Did marcosw just start testing psdcmyk ? | 21:25.34 |
| mvrhel_laptop | looks like another mix up with int ncomps = dev->color_info.num_components; and the pdf14 device | 21:25.56 |
| | rayjj: no psdcmyk has been getting tested for a long time | 21:26.15 |
| | This is looking like there is some confusion in regard to the push device compositor values | 21:40.59 |
| | very suspicious about a ps file that has pdf14 compositor commands | 21:41.28 |
| | but I will continue | 21:41.35 |
| rayjj | mvrhel_laptop: I understand your point, but since our PDF interpreter is PostScript and uses these same custom operators in order to control transparency they should be fine (assuming that we haven't changed the parameters expected by the operators) | 21:48.30 |
| mvrhel_laptop | sure | 21:51.40 |
| | there is some confusion on the device push during the clist write vs. the device push during the clist read that is the source of the issue | 21:52.15 |
| | during the read, the device is setting its components based upon ptempdevproto->color_info.num_components = | 21:53.04 |
| | ptempdevproto->devn_params.num_std_colorant_names + | 21:53.06 |
| | pdf14pct->params.num_spot_colors; | 21:53.07 |
| | during the write it is set with pdev->color_info.num_components = target->color_info.num_components; | 21:55.28 |
| | and unfortunately params.num_spot_color during the readback (and during the write) was set to -1 | 21:56.10 |
| | due to the fact that there were no spot colors on the page | 21:56.26 |
| | I am going to need to get these things in sync | 21:56.45 |
| | I am a little surprised this has not come up before | 21:57.00 |
| | rayjj: one issue with this is that in pdf we know how many spots are on the page and push the appropriately sized pdf14 device. in PS we do not know and of course we don't usually push pdf14 devices | 22:16.26 |
| | this is where I feel that this problem is a little odd. The interaction of spot colors for the sep devices and the pdf14 device is a bit unique and currently depends upon us knowing what is needed for the page | 22:18.18 |
| rayjj | mvrhel_laptop: I guess we could modify the test file the add <</PageSpotColors 0>> setpagedevice (to mirror the usage by the PDF interpreter more closely) | 22:39.44 |
| | mvrhel_laptop: that'll let it run with a larger band size than assuming 'max_components' when PageSpotColors == -1 | 22:40.52 |
| | Forward 1 day (to 2015/10/29)>>> | |
IRC Logs