1

Strongly related to Convert a PDF to greyscale on the command line in FLOSS?

My go-to command has been

gs \
-sDEVICE=pdfwrite \
-dCompatibilityLevel=1.3 \
-dPDFSETTINGS=/printer \
-dBATCH \
-dNOPAUSE \
-dQUIET \
-dPDFA \
-sProcessColorModel=DeviceGray \
-sColorConversionStrategy=Gray \
-dOverrideICC \
-sOutputFile=output-printer.pdf \
   $1

However, this increases the file size and reduces the print quality. In particular, text written in fonts turns into bitmaps.

What I really need is a program that takes a pdf file, replaces color commands with equivalent black-and-gray shades while removing all transparencies (to make the file pdf/a compatible). Rendering a pdf to a bit device for my purposes --- whether printer or ebook or screen --- seems like a fundamentally flawed approach. for this matter, using Acrobat Pro with its 6,236 GUI options also seems painful.

commercial or uncommercial, are there command line utilities that can do this?

barring this, are there configuration files for Acrobat Pro that can accomplish this for unsophisticated untrained users?

ivo Welch
  • 160
  • 5
  • 1
    Your main complaint seems to be the fact that the content can be rendered. There is no real alternative since PDF/A-1 does not support transparency. 'Removing' transparency doesn't make any sense, unless you render the content because the result will be incorrect. You could use -dNOTRANSPARENCY instead but any real use of transparency will be wrong. You should drop OverrideICC (does nothing here) and PDFSETTINGS and also -sProcessColorModel. But fundamentally what you are asking for will lead to incorrect output. – KenS May 03 '23 at 07:28
  • this is true. however, there are programs (such as R's CairoPDF) that seem to open the transparency channel "for evil fun" --- they don't really use them. similarly, some of my external pdf plots claim to use it, but do not. this is enough to mess up pdf/a. I do understand that when I ask to remove transparency, it would mean drawing on top of. [a more sophisticated 'render and rewrite overlaps' is not what I am asking for.] and the real big problem is not even the transparency, but just that fonts seem to be lost to bitmaps. – ivo Welch May 03 '23 at 21:10
  • actually, I think omitting those two items has fixed the font problem, so already mille grazie. this was a big deal for me here!! – ivo Welch May 03 '23 at 21:14
  • make the latter a "maybe." I have not found rhyme or reason yet in how gs rasterizes bits and pieces of my pdfs. – ivo Welch May 04 '23 at 06:04
  • 1
    Yes we know Cairo (and other tools) have a habit of inserting 'no effect' transparency operations into PDF files, unfortunately there's no simple way to determine if these are spurious or not. I very much doubt if removing OverridICC and ProcessColorModel will do anything useful. If you are certain the transparency has no effect then -dNOTRANSPARENCY will tell the PDF interpreter not to handle transparency operations. For files which genuinely use transparency ops this will result in incorrect output of course. The content will only be rendered if it cannot be preserved, usually transparency. – KenS May 04 '23 at 07:10

0 Answers0