Email.Method options 5 and 6 re-implement the original Method options 0 and 1 (previously known as Type 1 and 2), i.e. launch the standard email client for sending interactively or non-interactively, respectively. The new implementation uses the latest Windows 7/8 MAPI API routines under direct A-Shell control rather than the MAPI interface built in to the PDFX driver.
Email.Method 5 and 6 both use the PC's default email client (Outlook, Thunderbird, etc.). Method 5 launches the email client and allows for user interaction, whereas Type 6 attempts to send the message without any user intervention. However, most email clients now have security restrictions for this kind of sending, and the user may have to deal with security-related popup dialogs.
With methods 5 and 6, processing errors cause the Debug Message window to be displayed with the error message. Descriptions for MAPI error numbers are listed in the following topic and also at this Microsoft site.
Comments
| • | If Email.Method 5 (run email client) and the other email variables are provided via the GDI directives (Email.To, etc.), the email client will pop up and be available for user input or override, but values provided will be inserted into the email message. |
| • | If you specify Email.Method 6 but do not provide an Email.To address, the PDF file will be generated per normal but nothing else will happen—i.e., no email message is created or sent. |
| • | As mentioned elsewhere, using the PC's email client (rather than the recommended method 4, SMTP mail) is fraught with peril; all the variables of different types of email systems and user preferences come into play, making the process very difficult to reliably control. There are many variables (different email clients, logon security frameworks, versions of Windows, etc.) that make these methods difficult and cause the develoeprs of PDFX to unrecommend them. |
UTF8 Support
Methods 5 and 6 support the //SETOPTION,UTF8 flag. In other words, you can specify non-ASCII characters in UTF8 format in the Email.Content field. Note that:
• Characters that cannot be expressed as single byte Latin1 characters (e.g. Asian, Greek, Cyrillic, etc.) will appear as garbage unless the local MAPI subsystem and the email client support UNICODE. This may require further Windows or other subsystem updates/configuration.
• Embedded entity references are not supported in the Content field for any of the Email.Method options.
• UTF8 in the Email.Content field is only supported in Method 5 and 6 (not 4).
