3

I'm trying (in a script on a linux server) to shrink and rasterize several thousands PDF files that come from various CAD/CAM softwares and represent "big" drawings (as in, 800x600mm or the like) with lots of thin lines (as in, similar to a 0.2mm pen).

The rasterized files should have visible lines when printed on A5 or similar paper, so I have to kind of "shrink" the original drawing while preserving line thickness. As an example, when I open one of those PDF files on Mac OSX Preview, it does exactly that: when I zoom in and out it adjusts line thickness so they always look the same on screen.

I tried doing that with ImageMagick and tried lots of -density, -resize and various other settings without great success: the thin lines just get scaled down as anything else and end up being too thin (or to disappear completely, in some cases) to be discernible when printed to a small size. I've also read through its documentation without any success. Of course I'm also open to using other tools, as far as I can script it.

How could I "preserve line thickness" when rasterizing a vector PDF file in a script, just like Apple's Preview does when viewing the same file on screen?

Luke404
  • 10,282
  • 3
  • 25
  • 31
  • preserving thickness while shrinking would imply that your "shrunk" drawings are now lying about relative sizes. e.g. if you've got two thin lines close to each other and you shrink far enough while maintaining visual size of the lines, eventually they'll overlap and appear as a single line. – Marc B Jul 08 '14 at 14:28
  • @Marc B Not necessarily, according to the PDF spec the behaviour that the OP describes can be achieved by setting the line width to 0, this will have the effect that the line will always be drawn with a width of 1-pixel according to the target device, disregarding the zoom level. – yms Jul 08 '14 at 14:37
  • @yms: that in itself does not prohibit two close lines to be drawn as one. – Jongware Jul 08 '14 at 15:50
  • 2
    @Jongware right, but MarcB said "shrinking would *imply* xxxxx", and my point is that there is another possible scenario where this implication might not be true. – yms Jul 08 '14 at 15:55
  • 3
    Vector graphics can **not** be "lost" when rendering postscript (PDF), see PLRM (or PDF Reference), section "Scan conversion details" - smallest details (not necessarily of zero width) are guaranteed to be at least 1 device pixel. I think you "loosing" them because of scaling on resulting raster image (scaling either explicitly or implicitly through IM delegation). E.g., to prove, I created 800*600 mm PDF with 0.2 mm lines, then `gs -sDEVICE=pnggray -dDEVICEWIDTHPOINTS=800 -dDEVICEHEIGHTPOINTS=600 -dFitPage -o out.png in.pdf`. Lines in 800*600 px `out.png` are 1 px wide (i.e. – user2846289 Jul 09 '14 at 14:19
  • 1
    _(continued)_ already wider than they should be). And changing 800 to 100 and 600 to 75 gives 100*75 px `1.png` with, again, 1 px wide lines. I mean, try rendering to final image size with Ghostscript, directly. – user2846289 Jul 09 '14 at 14:19
  • 1
    @VadimR Good point. I second your suggestion of using GS directly. About the 0-width lines, I was mostly referring to this part of the question: "when I zoom in and out it adjusts line thickness so they always look the same on screen." This behaviour is exactly how a 0-width line looks like on the screen. – yms Jul 09 '14 at 15:31
  • If you want to try other tools, try `mudraw` from `muPDF`. – lhf Nov 06 '14 at 11:05
  • @VadimR: Nice comments. By any chance, you know the answers to my questions [here](http://unix.stackexchange.com/a/171941/674) and [here](http://unix.stackexchange.com/questions/171976/avoid-bloating-file-size-when-removing-ocred-text-from-a-pdf-file)? Thanks. – Tim Dec 07 '14 at 18:11

0 Answers0