I'm able to convert it through an intermediary ps file (using gs, pdftops (v 0.24.3) or pdf2ps) but this convertion rasterize the whole PDF.
I tryed a lot of other things: normalize the PDF using qpdf (v 5.0.1) or pdftk (v 1.44), transform it to a svg file and back to a PDF via Inkscape (v 0.48.4)... nothing seems to work.

The only one solution I found (which is not suitable for me in production environment) is to use Preview on my Mac and apply a Quartz Gray Tone filter manually or with an Automator script.

Anyone find another working way to do it?
Or is it possible to normalize the PDF or fix the issue to prevent the Ghostscript message "Unable to convert color space..." or to force the color space in another way?

It gives this output and the PDF is still colored. GPL Ghostscript 9.10: Unable to convert color space to Gray, reverting strategy to LeaveColorUnchanged.
– GauravDec 4 '14 at 4:05

+1 worked out of the box on my OSX. adding $1 and $2 instead of out.pdf and page-27.pdf and turning this into a batch script is also helpful for more flexible every day use.
– Matt BannertFeb 17 '15 at 8:16

2

This isn't real grayscale. If I print out the ink converage it is using C, M, and Y to make gray.
– Ian GoodfellowApr 25 '15 at 6:07

I had to convert the backslashes to ^ in order for it to work, but then it worked great!
– Justin EldracherOct 14 '17 at 20:58

A bit late in the day, but the top answer doesn't work for me with a different file. The underlying problem appears to be old code in Ghostscript, for which there is a later version that is not enabled by default. More on that here: http://bugs.ghostscript.com/show_bug.cgi?id=694608

If you crack into the file, you'll find that most of the colors are determined through an RGB ICC based color space (look for 8 0 R to find all the references to this colorspace). Perhaps gs is complaining about that?

Who knows.

The take away is that converting a page from one colorspace to another without affecting the content is non-trivial in that you need to be able to render the page and trap all changes to the current color/colorspace and substitute an equivalent in the target space as well as convert all image XObjects in the wrong colorspace, which will require decoding the image data and re-encoding it in the target space, as well as all form XObjects, which will be a task similar to trying to convert the parent page since form XObjects (I think your doc has 4) also contain resources and a content stream of page marking operators (which may include more XObjects).

It's certainly doable, but the process is nearly the same as rendering but with some fairly special-purpose code.

You can use something which I created. It gives you the option to choose the specific page numbers that you want to convert to grayscale. Handy if you don't want to grayscale the entire pdf. https://github.com/shoaibkhan94/PdfGrayscaler.