If that setting is making no difference then something is wrong. It should materially and significantly affect the size of the resulting PDF file.

I'd suggest contacting their support folks.

This looked very promising.

Unfortunately, CutePDF has already set -dCompatibilityLevel=1.4 in its parameter file by default.

I tried to play a bit with the -dPDFSETTINGS= setting to create various output files from SkyDemon, but it made no difference.

Just to be clear - it's definitely not a resolution issue from SkyDemon. If you zoom in closely, you see the background tiles (the terrain) correctly rendered as a fairly low resolution bitmap (which proves SD isn't sending excessive data to the print driver). All the text is also vector based which is good. The issue is that the magenta line, airspaces and rivers (amongst other things) are translucent, and your driver is turning them into huge bitmaps.

What you need is either something that handles transparency correctly (PDF has been able to cope with transparency for many years), or at least lets you turn down the resolution of the internally generated bitmaps.

I've just had a poke around, it it seems the CutePDF uses the open source GhostScript library.

===
How to reduce the size of output PDF file?
You can alter the parameters used in a text file "%Program Files%\Acro Software\CutePDF Writer\PDFWrite.rsp". The key parameters are in the line:
  -dPDFSETTINGS=configuration

where configuration can be /screen, /printer, /prepress, /default.
===

Have a look here:-

http://www.cs.wisc.edu/~ghost/doc/gnu/7.05/Ps2pdf.htm

where it explains what the different options do. Try /screen and /printer

It looks like it defaults to producing 'Acrobat 3' compatible files as well which don't support transparency (this was introduced in Acrobat 5).

===
ps2pdf12 will always produce PDF 1.2 output (Acrobat 3-and-later compatible).
ps2pdf13 will always produce PDF 1.3 output (Acrobat 4-and-later compatible).
ps2pdf14 will always produce PDF 1.4 output (Acrobat 5-and-later compatible).
ps2pdf per se currently produces PDF 1.2 output (Acrobat 3-and-later compatible). However, this may change in the future. If you care about the compatibility level of the output, use ps2pdf12, ps2pdf13, or ps2pdf14, or use the -dCompatibilityLevel=1.x switch in the command line.
===

I don't know how you'd encourage CutePDF to use ps2pdf14 - perhaps contact their support folks?

It may be as simple as adding: -dCompatibilityLevel=1.4 to the above config file, or they may expose it in the GUI somewhere.

Okay, thanks, all - when I find an external solution (e.g. a better Print2PDF tool), I will post that here.

The document you uploaded is unusable on a Mac as well - which has the leanest and quickest PDF viewing engine I've ever come across. It took several minutes to open and was then impossible to navigate around. I had to terminate the application in the end.

Your PDF printing tool is producing nasty output I'm afraid. It is turning any areas with translucency into a heavily dithered high resolution bitmap. Unfortunately, lots of stuff on a typical SD chart has an element of translucency.

As already suggested, the next step would be to try some different PDF printing software.

"Sorry, there's no way we would make such sweeping changes to our chart rendering process just because print-to-PDF utilities produce large PDFs."

I can perfectly accept that - SD is a great product and each version has come with very useful and thought-through enhancements and I realize you guys must have a queue of things to realize that prioritize higher than this, but just for the sake of understanding...

"I am not altogether surprised, as there's a lot of vector detailing in our charts and we certainly wouldn't do anything to compromise that."

The vector detail is obviously a huge benefit within the application during planning and navigating. I do not see the advantage of "sending" that level of detail to a printer (regardless if it's a physical machine or a PDF converter). In both cases, the result will be a flat image with a set resolution anyway - why not (apart from the prioritization with other enhancements, see above) send bitmap image data (compressed?) to the printer?

For what it's worth, here's a sample file I generated from the Print Center:

https://dl.dropboxusercontent.com/u/28023189/document.pdf

Sorry, there's no way we would make such sweeping changes to our chart rendering process just because print-to-PDF utilities produce large PDFs. I am not altogether surprised, as there's a lot of vector detailing in our charts and we certainly wouldn't do anything to compromise that.

"Presumably you're using a "print to PDF" tool, which is a non-standard item on a PC. If that is the case, you might find that contacting the developers of the tool, or trying a different tool, yields better results."

Tim, my apologies for being inaccurate here. The last time I actually did it was some time ago and I picked this up today because it came up on euroga.org.

In fact, I'm using CutePDF writer, so it's exactly as you suggested.

However, it's still the case that CutePDF usually (with other programs) yields much better results and I'm thinking if it is not possible and beneficial to either convert/compress what's being sent to the printer internally (something like the option in MS Powerpoint to compress all images within the presentation to a certain resolution for print or screen display) or to implement a PDF export functionality directly in SkyDemon? I uses this a lot to create a trip kit that I then print at the airfield (containing the charts, the plog, the notams, ...).

I realize this is now a feature suggestion rather than a bug report.

I answered this same query on EuroGA - it must be your PDF generation tool that's creating the huge files.