| | <<<Back 1 day (to 2019/11/04) | Fwd 1 day (to 2019/11/06) >>> | 20191105 |
| kens | manf5 | 08:02.28 |
| | to report a bug please visit bugs.ghostscript.com | 08:02.41 |
| scramblez | Hi All, I run -sDEVICE=pdfwrite along with -sColorConversionStrategy=CMYK and -dProcessColorModel=/DeviceCMYK on a pdf produced with Inkscape containing many svg + 1 bitmap + some filter effects. The output pdf has a 1px white line at the top and right hand edge of the A4 page. I was wondering what may be causing this. | 11:18.53 |
| kens | Can't be 'one pixel' if its a PDF file | 11:19.30 |
| | Without seeing the original file its impossible to say more | 11:19.47 |
| | Also, as I think I mentioned before, if you set -sColorConversionStrategy you don't need to (and dhould not) set ProcessColorModel | 11:20.12 |
| scramblez | kens: you're right of course, it just /looks like/ 1px on the screen and on the test print. | 11:20.32 |
| | Ahh! OK, I'll run it again. | 11:20.57 |
| kens | Not setting it won't make a differemnce, its just that ColorConversi0nStrategy sets it for you already | 11:21.32 |
| | Or at least it does with any reasonably recent version of Ghostscript.... | 11:22.31 |
| scramblez | OKie dokie, I was reading "VectorDevices.htm" and it said "...If you plan to create a device-independent color PDF file then you should set the ProcessColorModel " | 11:23.27 |
| kens | Yes, but I thought you were creating a CMYK file ? | 11:23.50 |
| | That's not device-independent colour | 11:23.56 |
| scramblez | When you set ProcessColorModel, are you meant to define your own CMYK icc? | 11:24.32 |
| kens | Not especially | 11:24.44 |
| scramblez | scratches head ... | 11:24.58 |
| kens | If you want to do full colour correction then you will need to do so. You will also need to define your own RGB and Gray profiles | 11:25.12 |
| scramblez | I C | 11:25.22 |
| | Let me run it again and see what we get. | 11:25.32 |
| | I got the same effect. | 11:28.10 |
| kens | I don't doubt it, I did say that it wouldn't make a difference | 11:28.25 |
| scramblez | Quite so. | 11:28.33 |
| | The thing is the white line is not visible on the input pdf (RGB) only the output pdf (CMYK). | 11:29.17 |
| kens | As I said, I really can't comment without seeing the files | 11:29.31 |
| | But... *Any* time you process a PDF file to create a new PDF file, there is the possibility of losing fidelity. You shouldn't do this unless strictly encessary | 11:30.09 |
| | The explanation at teh top of vectordevices.htm tries to explain this | 11:30.22 |
| scramblez | Yes, it is clear enough, but the printers asked for a PDF with CMYK colour space. | 11:31.25 |
| kens | As I said, your pritner is nuts :-) | 11:31.40 |
| | Or more accurately, they want to be able to blame you if you don't like the result | 11:31.53 |
| scramblez | Pretty much ... garbage in -> garbage out. | 11:32.19 |
| chrisl | I would guess the white space is a rounding error from rendering the entire page to an image | 11:32.48 |
| kens | They are basically saying 'we don't really understand colour; so you need to get your PDF made so that it prints 'as expetced' on out printer with this paper' | 11:32.55 |
| | chrisl that's my guess, but its impossible to say without seeing teh file | 11:33.06 |
| scramblez | Just a sec pls | 11:33.19 |
| chrisl | The PDF does have transparency of some form | 11:34.00 |
| kens | Hmm and the output is PDF/X-1 ? So it'll be a raster | 11:34.25 |
| | so yeah, probably a rounding error | 11:34.31 |
| scramblez | I've experimented with PDFX, but I gave up and went back to v1.7 which handles transparency better. | 11:37.35 |
| kens | Well, at all | 11:37.49 |
| scramblez | I've uploaded the two files:http://www.lakesidefishery.com/poster-christmas-2019-final.pdf and poster-christmas-2019-A4-CMYK-final-600dpi.pdf | 11:42.18 |
| kens | OK I'll need a minute | 11:42.39 |
| | got to context switch | 11:42.45 |
| scramblez | Thanks! | 11:42.49 |
| kens | I can't seem to get teh second one A4-CMYK | 11:44.10 |
| chrisl | http://www.lakesidefishery.com/poster-christmas-2019-A4-CMYK-final-600dpi.pdf | 11:44.50 |
| kens | Yeah I missed the 600dpi | 11:45.00 |
| chrisl | Um, did you set the 600dpi on the command line? | 11:45.04 |
| scramblez | No, on inkscape export to PDF | 11:45.22 |
| | I guess cairo | 11:45.36 |
| | did the exporting | 11:45.46 |
| chrisl | Oh, I assumed the "600dpi" one was after running through gs | 11:46.05 |
| kens | It is | 11:46.21 |
| | and the right edge is not continuous alll the way down | 11:46.31 |
| | whiel the original also has a white edge at teh top | 11:46.39 |
| | Ah but it goes away if I turn off Acrobat anti-aliasing | 11:47.26 |
| scramblez | Sorry, I didn't make myself clear: The file 'poster-christmas-2019-final.pdf' is the original as exported from Inkscape. The file 'poster-christmas-2019-A4-CMYK-final-600dpi.pdf' is as processed via gs. | 11:47.28 |
| | Ken: Interesting! Are you using Adobe Acrobat to view them with? | 11:48.06 |
| kens | I have several techniques | 11:48.17 |
| | That's just one | 11:48.21 |
| scramblez | :) | 11:48.24 |
| | Using mupdf I can't see a line in the source file, only the output. | 11:49.47 |
| | More importantly so does the local printer (cheap Brother laser) | 11:50.11 |
| kens | So the reason the right edge is not tiotally white is because one of the objects on the page extends past the edge of the page (in the original file) whereas the other objects do not. Due ot rounding, the other objects fail to quite reach teh edge, while the one which extends beyond the edge carries on, resulting in the remaining green stripe at the bottom right | 11:50.26 |
| | The green backdrop appears to be a single objects which has the stars, text, etc placed onto it | 11:51.51 |
| scramblez | The user disabled antialiasing for images and it made no difference. However, as created at least I'm told it was exactly the same width, starts at 0 and ends at 216 ... :-/ | 11:53.20 |
| kens | If I start with the original file and remove everything except the green gradient fill backdrop, it also does not reach the top or right edges | 11:53.44 |
| | Oops no wrong file. | 11:54.14 |
| scramblez | Hold on, we have an admission ... the user found a loose snowflake on the left in the original, this may throw things out. | 11:55.01 |
| kens | OK reduced the original to just the gradient | 11:55.05 |
| | So simply running the original PDf to a new outptu file doesn't show the problem | 11:57.03 |
| | But settign ColorConversionStrategy does, so lets try that with the simplified file | 11:58.14 |
| | Hmm, no that doesn't cause the problem | 11:58.44 |
| | Ah, typo in the command line | 11:59.37 |
| | Now I can reproduce this with just the single backdrop gradient | 11:59.48 |
| scramblez | Hmm ... moved everything into the mediabox, rerun gs and there is still a white line. So is this the result of a rounding algo thing? | 12:01.43 |
| kens | It looks like its due to rounding | 12:02.19 |
| | The MediBox you specify cannto be preserved precisely | 12:02.39 |
| scramblez | FAir enough, thank you for looking into it. It should be cropped within the bleed anyway. | 12:03.07 |
| kens | The construction of that backgroudn is insane | 12:03.44 |
| | There appear to be some 200 Form XObjects used to draw it | 12:04.13 |
| scramblez | TELL ME ABOUT IT!!!! | 12:04.13 |
| | Completely mad. | 12:04.22 |
| | 362 svgs or some such. O_O | 12:04.40 |
| kens | That could be it | 12:05.00 |
| | But bear in mind this is *just* the green background gradient fill not any of the other content | 12:05.17 |
| scramblez | It's a repurposed image from what I'm told. | 12:05.28 |
| kens | Clearly its not a gradient | 12:05.29 |
| | Its nto an 'image' in PDF terms because its (mostly) not a bitmap | 12:05.46 |
| scramblez | Yes, only the tree is bitmap. | 12:06.12 |
| kens | We're ending up converting somethign into a bitmap | 12:06.41 |
| scramblez | I used the term 'image' loosely | 12:06.43 |
| | So from your helpful expert look into this I conclude: start with a sane(r) source file and we'll arrive at a better output. | 12:07.41 |
| kens | Ah, looks like we are converting the shading into an image. I would imagine this is because we are colour converting it | 12:07.48 |
| | IBecause shadings are functions, its well nigh impossible to take a n-input, 3 output function and convert it into an n-input, 4-output function | 12:08.41 |
| | We do try but if we fail we fall back to a bitmap image | 12:09.03 |
| | aha, the original shading has /Extend [true true] | 12:09.47 |
| | Which we cannot replicate with an image, so we end up clipping it to the page boundaries. | 12:10.07 |
| | Your MediaBoox is: | 12:11.01 |
| | and our output is (due to rounding): | 12:11.01 |
| | Ba, liens with starting / | 12:11.09 |
| | input is: /MediaBox [ 0 0 612.283447 858.897644 ] | 12:11.25 |
| | outptu is: /MediaBox [ 0 0 612.280029 858.900024 ] | 12:11.39 |
| | I strongly suspect that, because hte shading is defined to extend in oth dimensions, ti will reach teh edge of the media. However, you can't define an image like that, and when we render it, the rounding errors mean it ends up slightly too small | 12:12.32 |
| | You might be able to address that by putting a flat green fill under the shading, that is as the first thing on the page. | 12:13.02 |
| | But fundamentally, this is what that paragraph in vectordevices.htm is all about; if you process a PDF file liek this, the output is not the same as the input, and some loss of quality is possible | 12:13.42 |
| scramblez | User found suspect snowflake which was extending to the left of the page. She's cropped it now and I'll rerun gs to see what we get. | 12:14.37 |
| kens | I don't think it will make any difference, teh problem is the fact that the shading is rendered to an image, and the rounding errors associated with that and the media size | 12:15.12 |
| scramblez | Yes, I understood primitives will do what they can, but there are no guarantees reprocessing will arrive at the same output. | 12:15.36 |
| kens | If I don't colour convert, then the shading is not crendered to an image, and the white aresa does not appear | 12:15.42 |
| | My solution would be to bleed a green rectangular fill outside the media as the first (in z-order terms) object on the page, tehn put all the other content on top | 12:16.29 |
| scramblez | You're right, squeezing the flake into the media box didn't fix it. | 12:16.57 |
| | She's extending the background. Let's see. | 12:17.37 |
| kens | That wasn't wquite what I mean (though I may misunderstand) | 12:18.04 |
| | The first object on the page currently is a gradient fill, which we render to an image. That fill is already extended | 12:18.30 |
| | But you cna't extend an image that way | 12:18.39 |
| | So my solution would be to put a brand new object, a simple rectangle which bleeds out past the media boundaries the colour of the last step of the gradient (green) | 12:19.18 |
| | That should be colour converted easily, because its a simple fill | 12:19.34 |
| scramblez | Understood kens, thank you. She's on the case. | 12:19.59 |
| kens | I'm afraid I don't see s solution form our POV, this is just one of the possible problems when processing a PDF file | 12:20.25 |
| scramblez | How much bigger should the rectangle be? As much as the white line we're trying to cover? | 12:21.20 |
| kens | Ideally outside teh media box. At the very least outside teh crop box. 1/72 inch should be enough (a PostScript/PDF unit) | 12:21.53 |
| kens | is off to lunch now | 12:22.13 |
| scramblez | kens: the Overview sections explains it clearly enough. Re-processing PDFs with primitives can have some impacts. THANK YOU! and enjoy your lunch. | 12:22.46 |
| kens | :-) Its nice to meet someone who actually read it :-) | 12:23.07 |
| scramblez | kens: more than once! I had to educate myself starting from level zero! :-) | 12:23.39 |
| | BTW, your suggestion worked a treat. Thank you again for your help and for gs! | 12:24.01 |
| kens | Ah that's good news, I hope you manage to get it printed OK | 13:05.40 |
| HenryStiles` | chrisl: error messages from bugzilla? | 13:17.03 |
| | nvm I don't need error messages, if there are any, I see the problem. | 13:52.27 |
| | <<<Back 1 day (to 2019/11/04) | Forward 1 day (to 2019/11/06)>>> | |
Log of #ghostscript at irc.freenode.net.