| | <<<Back 1 day (to 2016/11/02) | 20161103 |
| hamsheet | hey guys I am getting this Subsample filter does not support non-integer downsample factor (9.036437) | 02:57.10 |
| | when I am trying to optimize a pdf | 02:57.23 |
| | When i try bicubic I get another error ;( my pdf goes from 10mb to 200mb because fails to optimize | 02:58.11 |
| | http://pasteall.org/98034 | 03:00.16 |
| | I tested it on Debian and Cygwin | 03:00.32 |
| | GPL Ghostscript 9.19 (2016-03-23) | 03:00.40 |
| chrisl | hamsheet: I'm going to guess your file has transparency in it, and that's what's causing the increase in size | 07:54.18 |
| Robin_Watts | sebras: The luratech integration gives lots of signed/unsigned warnings in 32bit builds. | 14:16.03 |
| | and lots of nastier warnings in 64bit builds. | 14:16.14 |
| Robin_Watts | grabs lunch, then will keep bashing at it. | 14:16.26 |
| hamsheet | chrisl: is there a way to do it another way? | 14:21.19 |
| | The file chokes my readers | 14:21.33 |
| sebras | Robin_Watts: really?! I get a few unused variable warnings. | 14:23.51 |
| kens | hamsheet : do what another way ? | 14:29.08 |
| sebras | Robin_Watts: are we talking in my bindings or in the luratech library itself? | 14:36.42 |
| | Robin_Watts: I rebuilt uding clang-3.8 just now and I see no problems, being on 32-bit. | 14:37.02 |
| | I do see a single varning about jpx_alloc() haviny the wrong prototype using their latest code drop though. | 14:37.30 |
| Robin_Watts | sebras: In your bindings. | 14:57.09 |
| sebras | Robin_Watts: ouch, that doesn't sound good. | 14:59.09 |
| | Robin_Watts: are you preparing a log for me or how do we do this? | 15:00.05 |
| Robin_Watts | sebras: I'm trying to get what I've got now ready for commit, then we can think about that. | 15:01.26 |
| sebras | ok. | 15:02.20 |
| hamsheet | kens: "this Subsample filter does not support non-integer downsample factor (9.036437)" | 15:27.08 |
| | kens: "+chrisl> hamsheet: I'm going to guess your file has transparency in it, and that's what's causing the increase in size" | 15:27.25 |
| deekej | chrisl: Hello Chris, I see you have already fixed the issue about segfaulting *.ps file | 15:27.38 |
| kens | hansheet The subsample filter only supports integer or near integer factors. | 15:27.47 |
| | This is not related to the increase in size of your PDF file | 15:27.56 |
| deekej | chrisl: thank you very much, I will backport the package and let customer test it :) | 15:28.00 |
| hamsheet | kens: I just need to optimize the pdf so I can read it, it is super painful to open it in desktop or mobile clients | 15:28.53 |
| kens | hamsheet : pdfwrite does not 'optimise' PDF files. It creates new PDF files from its input. | 15:29.28 |
| hamsheet | I see, what do you recommend? | 15:29.46 |
| | I am guessing that this pdf has alot of vector elements in it, downloaded from archive.org | 15:30.16 |
| kens | The reason your created PDF file is larger than the original is (probably) because your roiginal has transparency, and you have set the output to be PDF 1.3, which does not support transparency | 15:30.48 |
| | as a result, the content of the output file is a large image. | 15:30.49 |
| | hamsheet : no vector or not is irrelevant. | 15:30.49 |
| | The presence of transparency is what causes the increase in size. It is also (probably) what causes your mobile viewer to run slowly | 15:30.52 |
| hamsheet | the file is 10mb originally, after I run the gs script it goes up to 200mb, | 15:31.20 |
| kens | If you want to 'flatten' the transparency, then the only solution is to have images. | 15:31.21 |
| | hamsheet : Yes, what did you expect ? Its a full page image at 720 dpi | 15:31.41 |
| hamsheet | kens: that is fine, i do not know much about the details of the pdf write or gs in general, i am just trying to optmize so that it is a reasonable file | 15:31.52 |
| kens | You can reduce the resolution. The output will be smaller, at teh expense of quality | 15:32.09 |
| hamsheet | that is what I was trying to do with the script | 15:32.31 |
| kens | That command line doesn't affect the resolution | 15:32.50 |
| hamsheet | "-dColorImageResolution=72 -dGrayImageResolution=72 -dMonoImageResolution=72" | 15:33.04 |
| | hmmm | 15:33.07 |
| kens | You are still rendering at 720 dpi. | 15:33.08 |
| | If you want to reduce the resolution that transparency gets rednered at use -r | 15:33.22 |
| hamsheet | -r as in? instead -d" | 15:33.44 |
| kens | hamsheet : yes, that's what resolution images *in the original PDF file* get reduced to | 15:33.49 |
| hamsheet | I see | 15:33.56 |
| | kens: let me try it | 15:34.19 |
| kens | Since you are creating a brand new image (by flattening the transparency), the device assumes you have set the rendering resolution appropriately | 15:34.38 |
| hamsheet | ok thanks for your help I will try it | 15:35.48 |
| ray_laptop | hamsheet: BTW, if you are reducing the resolution with -r### you may also want to add -dGraphicsAlphaBits=4 -dTextAlphaBits=4 to smooth edges (hide jaggies) | 20:17.24 |
| | hamsheet: and if you want to minimize the PDF file size for the image at some reduction to quality, force JPEG (pdfwrite *might* choose Flate otherwise) with -dColorImageFilter=/DCTEncode | 20:24.18 |
| Robin_Watts | Using jpeg for anything that has text in it is asking for problems. | 20:25.26 |
| ray_laptop | Robin_Watts: yes, I know, but if the text is smoothed with AA, it helps a bit | 20:26.25 |
| Robin_Watts | it helps compression, it harms readability. | 20:26.52 |
| ray_laptop | I sure have seen plenty of scanned PDF pages that are JPEG, so it isn't that uncommon | 20:27.11 |
| | it depends a lot on how low the resolution is relative to the text size | 20:28.15 |
| | Forward 1 day (to 2016/11/04)>>> | |
Log of #ghostscript at irc.freenode.net.