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.