Subscribe to this thread
Home - General / All posts - What Print to PDF software do you recommend?

4,596 post(s)
#23-Nov-17 11:15

With the new layout capabilities in Future it's exciting to be able to print to a PDF if you have a PDF "printer" installed.

So far the documentation for Future and the video use the Microsoft Print to PDF facility that is a built in "printer" within Windows 10. Unfortunately, Microsoft Print to PDF is not available in all Windows editions.

Many users within Manifold also have the Adobe PDF printer, a product installed with some Adobe commercial products, and some users have installed freeware alternatives such as FreePDF. Both Adobe PDF and FreePDF work fine as "printers" for Future layouts.

What other print to PDF software is good? It would be great to have a list of print to PDF options that are either affordable or free, and which do not install or risk installing adware or malware.

240 post(s)
#23-Nov-17 11:46

I used to use and like CutePDF Writer. After Microsoft Print to PDF available (starting with win7 I think) I have not used it anymore. I am not printing much pdfs lately anyway.


530 post(s)
#23-Nov-17 20:48

CutePDF writer as well for anything other than Manifold.

Working within Manifold, Iexport my layouts as pdf files from within manifold.

jsperr50 post(s)
#23-Nov-17 15:49

I use doPDF -- it is the free "lite" version of novaPDF.

Requirements and support

doPDF requires .NET (v4) to be installed and works on the following operating systems: Windows 10/8.1/8 (32 and 64-bit), Windows 7 (32 and 64-bit), Windows Server 2016, Windows Server 2012, Windows 2008 Server (32 and 64-bit), Windows Vista (32 and 64-bit), Windows 2003 Server (32 and 64-bit), Windows XP SP3 (32-bit).

[post edited by admins to remove references to adware]


4,596 post(s)
#23-Nov-17 18:10

I tried doPDF and it seems to work quickly and to produce PDFs that are compact.

However, it features advertising in the print dialog with active click-through buttons, and... surprisingly,... it just popped open a window all on its own to spam the products they want to sell. I could live with the advertising but I don't like products that lurk in sleeper mode and every now and then pop open spam windows. So I uninstalled it. Sigh!

jsperr50 post(s)
#24-Nov-17 18:27

I'm using version 8 of doPDF and I see none of that. I use it almost every day here at work.

It does announce when a new version is available, but that is the only time I have ever seen it push anything my way.

I declined the update to version 9 recently -- is that the version you installed?

Mythman39 post(s)
#23-Nov-17 19:05

I have used PrimoPDF by Nitro PDF Software with considerable success.


777 post(s)
#24-Nov-17 04:09

We have found Foxit Phantom PDF quite good.

Is the printing better in Manifold future than 8?

I've found the export to PDF in 8 far better than printing to PDF. Even when physically printing, the quality is far better if you export to PDF and print the PDF than to print directly.

I hope Manifold future retains ability to export directly to PDF too, and improves the deficiencies of 8 by

-allowing jpeg compression,

-keeping text as text without messing up the size and position

-producing a PDF which includes the blank page/margins etc behind the print

But keeps nice features like the quality and switchable layers.


4,596 post(s)
#24-Nov-17 06:51

Is the printing better in Manifold future than 8?

Yes, far better.


1,029 post(s)
#24-Nov-17 08:24

I prefer doPDF, cause there i have the option to print DIN A0.

In Windows Print to PDF there is only the option max. DIN A3.


4,596 post(s)
#24-Nov-17 09:11

Take a look at FreePDF. They don't have A0 as an option in the drop-down list but they do have a custom paper size, so you can specify 841 x 1189 mm for A0. I just tried it and it works great.

Plus... FreePDF is a German product with (if you want) German documentation and it has absolutely zero advertising, pop-up spam, malware, etc. Sehr gut! :-)


1,029 post(s)
#24-Nov-17 09:31

Thanky ou Dimitri. FreePDF sounds good.

hphillips11 post(s)
#24-Nov-17 16:20

I don't understand the effective difference between 'export to PDF' and 'print to PDF' and why one or the other would be preferable (mikedufty indicates 'export' works better). However whatever method is used by Manifold I would like the ability to write a geospatial PDF file for later use with Avenza Maps or Paper Maps. A limitation I can easily live with: georeferencing of the PDF based on only one frame in a layout.


4,596 post(s)
#25-Nov-17 06:58

I don't understand the effective difference between 'export to PDF' and 'print to PDF' and why one or the other would be preferable (mikedufty indicates 'export' works better).

Some background, and a somewhat simplified to avoid going into all the intricacies:

PDF is not a format but a language, like Visual Basic or C#. PDF is a language for working with and for creating visual displays of data that is often found within documents, such as text, or images.

When an application creates a PDF file, what it is really doing is writing a program and putting that program into a file along with some data upon which that program works.

When a different application displays a PDF file, what it is really doing is executing that program, following the instructions in the PDF programming language to create a visual display. For the most part that usually is all about how to format, scale, transform, edit and display the packet of data that is encapsulated within the PDF file along with the program, but it can be just the execution of programming instructions to create totally new items for visual display.

The idea is that if you have an application like Microsoft Word, which displays data in visual form to appear as a document, Word can automatically write a program in PDF language that, when containing within it an encapsulated chunk of subject data, can be run by a PDF interpreter to follow the instructions in the PDF program to take that data and display it the same way Word does. If that sounds complicated and error-prone, it is.

But when you consider how it is that Word does something even as simple as displaying some text in a document, well, it's not that simple. Word doesn't just take letters and number and print them like a 1960's teletype might. It composes a paper sheet of a given size, applies a font that has all sorts of graphical characteristics, aligns text into lines and paragraphs with very subtle spacing and margins and all that, and it applies zillions of effects. How a given program like Word does that might be very different than how some other program does that.

One approach to reproducing a document that Word creates is to create an image at some resolution. The image is then what it is, a sea of pixels, that represents what the document looks like. But that only works for an image at a given resolution, when Word can print to printers with higher (sharper text) resolution or lower (blurrier text) resolution. Adobe PDF language is designed to get around that by writing a program that can, in theory, better mimic what Word would display without requiring Word.

The problem with all that is that there is no other program that does everything exactly the way Word does except Word. Clever though PDF language may be, it cannot cover all the bases, and the PDF spec allows different applications to try to program how to duplicate a display using very many different possible programs.

Whenever an application creates a PDF it is writing a program in PDF language that has the objective of duplicating a given display. Any application that displays what is in a PDF has the objective of being able to run PDF programs to reliably duplicate what the author of those programs intended to be seen.

Applications that write PDF language obviously must understand how to use that language correctly. Some are better than others, and are more able to use more complex features of the language to create more reliable PDF programs or smaller PDF programs.

But applications that write PDF programs also must be able to understand what the source display is all about. For example, if an application tries to create PDF programs to duplicate how a Microsoft Word document is supposed to appear, it better understand all the various features within Word that are used to create the appearance of such documents. That's not so easy.

In fact, it is darned near impossible for anybody who wants to create a general purpose PDF writer to understand each and every possible source application, from Microsoft Word to Manifold Future, that might be the source of displays. So instead such programs take a different approach: they expect any such source application to do part of the work, to encapsulate what the display is supposed to be by preparing it as if it was going to be sent to a printer.

The idea of using an intermediate step, preparing a display as if it were to be sent to a printer, is a good idea because just about all applications have to be able to print in any event. The PDF writing application thus wraps itself in an interface that says "Hi! I'm a printer!" and any application that can prepare a display for a printer can then send that off to the PDF "printer" and then the PDF writing application takes it from there. The job for the PDF writing application now becomes one of taking a print job and writing a PDF program that will duplicate that print job using PDF language.

Whenever you see "print to PDF" that is what is going on.

Whenever you see "export to PDF" directly from within an application, like Release 8, what is going on is that Manifold itself wrote a PDF-writing application that understands what is going on inside Release 8 and which takes whatever 8 intends for display and based on that creates a program in PDF language. There is no intermediate step of first prepping the display for printing and then handing off that print job to some generic print-job-to-PDF-language writer.

Both approaches have their advantages and disadvantages.

The advantage of print-to-PDF is that vendors who create print-to-PDF can put all their energies into an understanding of writing PDF language programs that will be reasonably well executed by the very many, very different PDF interpreting viewer packages. They don't know anything about how applications like Word or Future work, they just take it on faith that whatever they get as a print job has already been scrunched into some printable, intermediate form.

The disadvantage of print-to-PDF is that they cannot go past whatever are the limitations of typical printers. Printers hammering out hard copy don't know anything about georeferencing, for example, so that's not part of a print job and thus not part of print-to-PDF. Printers don't do layers either (it's just one sheet), so that's not usually part of print-to-PDF.

The advantage of an application like Manifold writing its own PDF is that awareness of things like layers or georeferencing could be built in, to take advantage of advanced features of PDF language. In theory, such PDFs could also be smaller and faster because more efficient use of the language could be made to optimize the PDF program, instead of using lowest-common-denominator intermediate forms suitable for printers.

The disadvantage of an export-to-PDF being built into an application is that writing a reliable PDF writer is a truly huge effort. Do you really want your GIS vendor re-inventing a wheel when what almost all users (to the 99% level) want can be had off the shelf using an existing, third party, print-to-PDF package? Wouldn't it be better for that GIS vendor to invest the several man-years required into, say, a better GIS?

The other disadvantage with export-to-PDF is that because it is tied to only one application it will not have the zillions of users that an application like Microsoft Print to PDF gets, so it never will be as well debugged or as well optimized or as well-understood for as many PDF viewers as a generic print-to-PDF facility, and the big players are not going to modify their PDF display engines in response to any issues.

If Adobe's print-to-PDF application (part of Adobe Elements) writes a perfectly valid PDF program and Microsoft Edge displays that PDF incorrectly, Microsoft will fix Edge. If Manifold Release 8, or Future or 9 were to write the same perfectly valid PDF program that Microsoft Edge displayed incorrectly, Microsoft isn't going to change a thing. They'll tell us, instead, to alter our PDF program creation so that our PDF programs don't step on Microsoft's bug. That's life in the big leagues.

Print-to-PDF technology has become reliable, mature, very well advanced and is supported by very many different vendors, with a wide range of marketing models for darned near every taste and economic philosophy. Using print-to-PDF has such immediate, huge, benefits for 99% of our users that supporting such things must come first in Future, as it has. Already it delivers far better results than export to PDF as exists in 8.

Now, one reason that is the case is because Future has a far better printing system than 8. If 8's printing system was as good as Future then you could use print-to-PDF in 8 with similarly improved results. But there you see the positive results of the print-to-PDF assumption that "the source application has to have good printing in any event."

It's not clear that a custom export to PDF facility should be in Future at all. If people want something like writing to geoPDF there is no reason why that couldn't be (as with other programs) an optional add-in, perhaps with an upcharge for those folks who want to author geoPDF for situations where other interchange formats do not meet their needs.

It's not a religious item either way. Print-to-PDF does such a superb job that it really does fit what 99% of users want. When users ask for other things, Manifold is all ears and eager to know exactly what is required. If it takes adding export to PDF Manifold will surely do that, as it did in 8. But the key word is required. So, anything that anybody wants, you know the drill. Send in a suggestion.

Mike Pelletier

1,461 post(s)
#27-Nov-17 15:48

How difficult and practical would it be to add the ability to import a PDF? If it's reasonable, then it could be a good way to transfer labels from another GIS into Future. That would be a big deal for many GIS shops. Are there better ways to transfer labels without losing formatting?


7,643 post(s)
#01-Dec-17 08:30

It wouldn't work for scenarios where labels are converted into vector glyphs, for example. This is frequently done in order not to bother embedding a font, and I would expect this to be done regularly for labels following lines or curves.

What is the original format you want to import labels from? There are labels in CAD formats, we mostly import them without issues, it's the rendering of what we imported that is currently lacking (working to improve it). What else?

Mike Pelletier

1,461 post(s)
#01-Dec-17 15:33

Thanks for the explanation Adam. It still would be nice to be able to open a pdf in Mfd because so much info is in this form. I fairly often open a pdf in Canvas (graphics program) or Globalmapper to get info that I then bring into Mfd. Neither program does a super job but I'm happy for what it gives me.

I was thinking of transferring labels from ESRI annotation. In our case, we have loads of manually placed labels in this form for parcel mapping and it would take huge amounts of time to recreate. Not being able to transfer labels with the same formatting will be a big deterrent from migrating to Mfd for many I suspect. Look forward to seeing how this progresses.


7,643 post(s)
#25-Nov-17 07:04

The difference between exporting to PDF and printing to PDF is who gets to write the PDF. With exporting, the PDF is written by the application that performs the export (for example, Manifold 8). With printing, the PDF is written by a specialized printer driver (what this thread is about) which intercepts the drawing commands sent from the application and composes a PDF that should draw similarly, the application thinks it is drawing on a sheet of paper. Exporting allows the application to have tighter control over how specifically the translation to PDF is done. Printing allows the application to print to everything else, not just to PDF.

In Future, we are starting with getting printing absolutely rock-solid and then we will likely add specialized means to export to PDF as well, to embed coordinate system data like you mention and to do other things that cannot be done via printing to PDF.

(Cross-posted with Dimitri.)

394 post(s)
#27-Nov-17 15:11

Exporting to PDF is the only practical way to go for me. Printing to PDF takes far too long, which puts Manifold in a poor light. I believe the problem with printing to PDF is the Google Earth image layer. I have not done that in so long, I can't remember if it is the image or other reasons.

Also, several employers ago, I had access to a version of Acrobat that would allow turning off layers and then saving those adjustments as the new default. That feature allowed my employer to carry one PDF on her flash drive and make presentations to both customers and investors without launching different versions of the maps. My current employer could use a layered PDF, but she prefers to use Google Earth as a viewer for layers.


4,596 post(s)
#27-Nov-17 18:02

Exporting to PDF is the only practical way to go for me. Printing to PDF takes far too long, which puts Manifold in a poor light.

I suppose by "Manifold" in the above you mean Release 8. Have you tried PDF printing in Future? If so, which PDF printers did you try?

PDF printing depends on which PDF printer you use. Some are very much faster than others. There is no reason why a fast, well implemented PDF printer could not be as fast, or even faster, than a reasonably well implemented export to PDF from a GIS vendor.

I don't think it is an either/or deal, nor do I have a personal preference other than being impressed by how it is easy to get great results, even at this early stage of layouts in Future, using print-to-PDF.

I'm just saying that printing to PDF has come a long way since Release 8, both in the very high quality of the many implementations out there, and also in the much better technology within Radian printing compared to 8, which in turn supports the better technology that now prevails from the print-to-PDF vendors.

394 post(s)
#27-Nov-17 19:54

I had not tried it, so I just did with build 163.10. Not sure what I'm doing wrong, but when I select Acrobat as my printer and use Page Setup to set the size to 45 inches by 36 inches, it returns to Letter. I set up a Layout and zoomed in on my map of the county to show the county courthouse (Google Earth image), my parcel layer, and the LiDAR layer with red dots covering the roofs of the buildings. The resulting print was created fast enough, but the result was less than satisfactory. First of all it is letter sized, and of course, secondly it is zoomed out about 200,000 miles from where I wanted it to be.

I'm going back to look at the video to see what I missed in the layouts.

Manifold Future Test Print to PDF.pdf
Screenshot of Manifold Future Layout.jpg


4,596 post(s)
#28-Nov-17 05:22

Hard to say without knowing all of the settings and the step by step workflow. The Layouts topic has a useful discussion in the Note titled "Frames Incorrectly Positioned" that seems to apply.

As noted in the topic, specifying Page Setup just sets up the layout. The way Windows interacts with printers it does nothing to change printer settings. You may have to change those during the File - Print sequence as discussed in the note. This is a side effect of the printing system in Windows.

It is also worth trying FreePDF or Microsoft Print to PDF to see what they do with the layout, instead of Acrobat. You'd think Adobe would be pretty good at creating PDFs, and it is, but not always.

394 post(s)
#28-Nov-17 21:59

It would seem this topic is answered, so I don't feel too bad troubleshooting Print to PDF.

In the first attempt at printing I was zooming the frame and not zooming inside the frame (double-clicking on the contents of the frame first). So I'm learning the new MF layout printing. I set up the Layout to be 45 inches wide and 24 tall. I adjusted the image inside the frame, selected Print and the Adobe PDF printer. Clicked the Preferences button and selected 45 inches wide and 24 tall. Left all the other elements at default. When I click the Print button I get an error notification that says, Tile size is too large. I tried again but this time leaving the printer at the default of Letter size. It took 8 minutes to print the file. It appears the printed file shows roughly the center of the Layout frame. At least something printed. Back in Manifold 8 I exported the full size layout, 48x24 inches, to PDF, and it took 4 minutes.

The reason for the oddball shape of the Layout is that this town is 1) built on a 45 degree angle from north, and 2) much longer in the sw-ne direction. I would like to rotate the Layout 45 degrees inside the MF frame, but I don't think that option is available yet.

Microsoft Print to PDF is not an option in Win 7. I found some people on the webs who were able to simply tick the hidden box to make it work, but my Win 7 version does not have the box to tick. I'll try FreePDF.


7,643 post(s)
#01-Dec-17 08:37

I set up the Layout to be 45 inches wide and 24 tall. I adjusted the image inside the frame, selected Print and the Adobe PDF printer. Clicked the Preferences button and selected 45 inches wide and 24 tall. Left all the other elements at default. When I click the Print button I get an error notification that says, Tile size is too large.

This is an issue on our side. We will fix it.

In the meantime, you can try decreasing printing resolution (the defaults for PDF tend to err on the high side).

Thanks for the note.

394 post(s)
#07-Dec-17 15:09

Thank you Adam. I was exiled from the Manifold websites for a few days by our new ISP. Got that straightened out, and I'm back getting my daily fix from y'all.

394 post(s)
#07-Dec-17 15:09

Oops! Double posted. Is there a delete post button I'm not seeing?


7,643 post(s)
#08-Dec-17 06:49

(There is no way to delete a post. If you accidentally create a duplicate post, just edit its text to something short like you did above.)

393 post(s)
#24-Nov-17 21:27

i use foxit but as you can see i don't use professionnal printer but i have a lot of driver printer .

In france the goverment for spend less money recommend to many oftheir employe / administration to use free software ( police , justice , mairie ....) . Here the pdf link of all recommanded software. Free don't mean there is not a pay version .... ( i love bluegriffon and the guy behind this software )

. The recommanded driver is PDFCreator ....I think the choice is for some reasons i don't try to know.. test study ......

[post edited by admins to remove references to adware]


393 post(s)
#24-Nov-17 21:45

i learn in the past XSLT transfromation to pdf using FOP



4,596 post(s)
#25-Nov-17 05:13

I've asked the admins to edit your post to remove the link to PDFCreator (and also links to doPDF in other posts). Links to third party sites within posts here are generally allowed but under no circumstances are links allowed to sites that provide software which may inject adware, hijack browser settings, etc.

Historically, many people have complained that PDFCreator has installed adware and, without getting permission from the user, has hijacked browser/search engine settings.

Read the Wikipedia article at , the section titled "Adware toolbar controversy" and ask yourself if you want to install software like that on your computer using Administrator permissions.

Please, if you recommend any PDF software in this thread, let people know if it installs, or may install, adware so they can incorporate that info into their decision to try it or to use it.

393 post(s)
#26-Nov-17 05:57

I was not aware of this a way the article say that this occur in 2013 and not today. the end users ll make their own review/"opinion" by test by themself with this past behaviour in mind !!

PDF is in relation with postscript RIP proof


393 post(s)
#26-Nov-17 06:26

the web has many good links if people has time here one of them

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.