ShellPrintProvider vs WordPrintProvider WordPrintProvider WordPrintProvider is a custom PrintProvider designed to work directly with Microsoft Word via the Office API. Since Word is being driven through an API this gives Solid Framework much more control over the process. Failures can be communicated as exceptions to your program rather than UI warnings to the end user. In addition, Word can be used to examine the original document and provide support for features that would not be possible by simple printing such as the original Document Properties. To illustrate this, use File Properties in Word to add properties to your Word test document like this:
The starting point for many developers using Solid Framework is the simple pdfcreator sample. This tiny program demonstrates the shortest path to creating PDF files from just about any document on a Windows system.
ShellPrintProvider
Using ShellPrintProvider, three or four statements are all that is needed to create a PDF file:
The ShellPrintProvider uses Windows Explorer to launch the application associated with the file type you are trying to convert. This only works if the application in question supports the shell “print” verb. In addition, print providers can use any of the supported Solid Documents PDF creation printer drivers. This example requires the Solid PDF Creator printer driver to be installed (but does not require a Solid PDF Creator license).
Advantages of ShellPrintProvider:
Disadvantages of ShellPrintProvider
Now make two simple changes to the original pdfcreator sample:
- replace the two instances of ShellPrintProvider with WordPrintProvider
- add printer.PreserveProperties = true;
When you run the sample application and then examine File Properties for the resulting PDF file in Acrobat Reader you should see that your Document Properties from the original Word document have been preserved. You should also notice a lot less UI “noise” from Microsoft Word during the creation process.