Release Notes Virtual Print Engine v4.0

 

Change of the License Terms

 

PDF Export Module Included

The PDF Export Module is no longer licensed separately. The PDF Export Module Standard Edition is now included in VPE Standard Edition and Enhanced Edition, and the PDF Export Module Enterprise Edition is now included in VPE Professional Edition and higher. No extra fees!

 

Drastically Reduced Prices

We want to push VPE aggressively into the market, in order to move away from a niche product. For this reason we reduced the prices drastically. You can help making VPE better known to the public by telling your friends, collegues - and everyone who is involved into software development - about VPE and its superior quality in terms of performance, stability, well tought-out programming interface, multi-platform support, in-depth documentation and support.

 

Royalty-Free

The VPE SDK license now allows for unlimited royalty-free distribution. Before, the limit was 10.000 installations without paying royalties.
(dycodoc and the VPE Interactive Edition are still not royalty-free.)

 

SDK License per Machine

The VPE SDK (Software Development Kit) must now be licensed per machine it is installed on. Before, a license was required per developer.

 

Annual Subscription including free Service Releases, all Updates and Standard Support

The VPE SDK (Software Development Kit) is now licensed together with an annual subscription including free service releases, all updates and Standard Support (there is also Premium Support available). Due to this new subscription model and the drastically reduced price, updates will not be available without a valid subscription.

 

VPE SDK Site-License

A new site license for one physical (respectively postal) address is now available for the VPE SDK.

 

Server Gold Licenses

As before, server licenses are required per server on which VPE is executed. But the licensing scheme has been simplified and in addition a gold-license (unlimited servers at different physical addresses) is now available.

 

For details about the new licensing terms, please see the help files.

 


 

Enhancements

 

Multi-Platform Support

VPE is now available for Windows (32-bit), Mac OS X (32-bit, PPC and Intel architectures), Linux / Unix (32- and 64-bit), and Solaris (32- and 64-bit).

Whilst providing the same API across all platforms, so that PDF and native VPE document files can be generated in the usual way, VPE will provide the preview capability for the Windows platform only. On the other platforms the preview and printing of PDF files will be delegated to platform specific tools, like Acrobat Reader or Xpdf.

Therefore all methods and properties dealing with the preview and printing are only available on the Windows platform.

Support for Windows 64-Bit will be made available at a later point in time.

 

Supports Windows Vista

VPE v4.x officially supports Windows Vista.

We detected a severe problem on Windows Vista with all VPE versions prior to v4.0:

It can happen that lines of text disappear randomly in the preview.
Printing or export to PDF is not affected.

We researched the problem and also discussed it with Microsoft. In our opinion this is a bug in Vista. We tested several things in our code and it seems that Vista does not update portions of the screen as it should. For example, when we draw a simple line together with the text, the problem does not occur. The problem does also not occur, if the grid drawing is turned on. The problem does also not occur when Vista is in "Classic Design", i.e. without Glass. VPE's screen output is highly optimized, so that only those objects are redrawn which need to be redrawn. This seems to cause problems.

All VPE versions prior to v4.0 are not specified to work on Vista, as written in the License Agreement. We strongly recommend to use VPE v4.0 or higher on Windows Vista.

After Microsoft could not provide any help to solve the problem, we researched a workaround which is implemented into VPE v4.0 and higher. This workaround solves the problem completely.

 

New Help Files

The VPE SDK (Software Development Kit) ships with help files in the HTML-Help format with a complete new and nicer layout.

 

Help Integration into Visual Studio

The help files are now integrated into Visual Studio, including context sensitive help (F1 key).

 

All Code in a Single DLL

There are no longer several different DLLs (for example one for barcodes, one for charts, etc.). All code is compiled into a single VPE DLL (except the JavaScript Engine for the Enterprise Edition and higher). This make the deployment process for you much easier.

 

New HTML Export Module (Professional Edition and higher)

VPE documents can now be exported to HTML.

 

New 2D-Barcodes (Professional Edition and higher)

Implemented four new two-dimensional barcode types:

 

New Office2003 and Whidbey themes for the GUI (Graphical User Interface)

The theme for the GUI can be switched during runtime between Office2003, Whidbey and the old Office2000 styles (on platforms different from WinXP the Office2003 and the Whidbey themes appear nearly identical, the difference becomes visible on WinXP, because Office2003 uses the color theme of XP, whilst Whidbey uses a constant color theme).

 

New GUI Functionality (Graphical User Interface)

New Open and Save Buttons in preview, which can be made separately visible by new design-time properties (tbOpen, tbSave).

The Toolbar button "1:1" has been exchanged with "Show full page", which now makes a page always fit into the preview window accordingly to its size, and the button "Show Full Page" has been exchanged with "Fit to Window Width", which makes a page always fit with its width into the preview window. Accordingly the VKEY_ constants have been renamed.
So, if either of both modes is activated and you resize the preview, the document scale will change accordingly.
The "Fit to Window Width" mode is activated by default. In order to gain the old preview behaviour, set the property ScalePercent = 100 immediately after calling OpenDoc().
In addition the "Zoom In" button now allows to center the view around the point where the preview was clicked, as well as to drag a rectangle which shall be zoomed into the center of the preview.

The maximum zoom level has been changed from 400% to 3200%.

New property ScaleMode allows to specify: (1) Fit whole page to preview, (2) Fit page width to preview, (3) Activate Zoom-Tool, (4) Free scaling
New method ZoomPreview, allows to zoom a specified rectangle of the current page into the preview
New method SetPreviewPosition allows to scroll the preview into the given position
New methods ZoomIn, ZoomOut

New events:
VPE_BEFORE_OPEN_FILE, handles return code 1 as cancel operation so you can display your own dialog and open a file for example from a database via a memory stream.
VPE_AFTER_OPEN_FILE
VPE_BEFORE_SAVE_FILE, handles return code 1 as cancel operation so you can display your own dialog and save a file for example to a database via a memory stream.
VPE_AFTER_SAVE_FILE
New methods: OpenFileDialog, SaveFileDialog
New properties: OpenFileName, SaveFileName
New Error Code: VERR_CANCELLED, if the Open or Save dialogs have been cancelled by the user

The event VPE_BEFORE_MAIL now handles return code 1 as cancel operation, so the mail dialog is not shown. This allows you to use your own mailing code.

 

Off-Screen Double-Buffering for the Preview

VPE now paints into a bitmap buffer and then copies the whole bitmap into the screen.
This provides flicker-free moving from one page to another.

 

Smoother Scrolling (Graphical User Interface)

The scrolling code has been reworked and the scrolling is much finer and smoother now.

 

User-Defined Localization for the GUI (Graphical User Interface)

The whole GUI can now be localized with user defined strings into any language you wish.
New constant VGUI_LANGUAGE_USER_DEFINED as value for the Property GUILanguage (.NET: UserDefined).
New method SetResourceString()

 

Advanced Layout Features (Professional Edition or higher)

ClearPage() deletes all objects of the current page.
RemovePage() deletes the current page.
InsertPage() inserts a page between two existing pages.

All three methods do also work for stream-based VPE documents, i.e. documents which have been opened using SwapFileName (DLL: VpeOpenDocFile).

 

Rounded Rectangles

New Property CornerRadius, which allows to draw boxes, text and RTF with rounded corners.

 

Compression for VPE Documents

VPE documents can be written compressed, this is the default now (see property „Compression“). The new compression makes VPE documents about 60 - 80% smaller.

 

Optimal Image Embedding

Images which have the flag PIC_IN_FILE set, are now embedded with their original (compressed) raw data within VPE documents - i.e. a JPG image is embedded as JPG, a TIF as TIF, etc. - and regardless of the number of times an image is used within the document, it is only embedded once.
In previous versions of VPE, files were embedded in uncompressed form, and they had been embedded as many times as an image was used.
Moreover, if the property Compression is activated, and if the embedded image is not a TIF, GIF, JPG or PNG, it will be compressed automatically using the flate (ZLIB) compression.
ATTENTION: When you read one or more VPE document files into the current document using ReadDoc(), and those files have embedded images, you may NOT delete or modify the source document files, while the current document is open! This is, because VPE loads the embedded images directly out of the source document files each time they are not found in the image cache.

 

VPE v4.x Document Files are Platform-Independent

VPE document files are now platform independent. They can be transparently read and written on Little Endian as well as on Big Endian machines and on 32-bit platforms as well as on 64-bit platforms. Also the embedded file names of referenced pictures are translated to the specific platform (i.e. correct slash and backslash handling). However, since Windows is case insensitive for file names, special care must be taken that you provide the file names for documents and pictures in the correct case sensitive way on all platforms!

 

Reading / Converting old v3.x Documents

VPE v4.0 can read old v3.x document files by default, but it can not write to them, i.e. it can not add new objects or pages to existing v3.x document files.

Converting old v3.x document files to the new v4.0 format:
Open the document file with SwapFileName (DLL: use VpeOpenDocFile())
Call WriteDoc(<new file name>)
The file <new file name>, is in v4.0 format
After conversion, the document can not be read by VPE v3.x, an error is returned.

 

New Memory Streams (Professional Edition and higher)

You can now read VPE documents, Pictures and RTF from memory-streams, and also write all exportable document types to memory-streams (currently VPE, PDF, HTML), as well as export images to memory-streams. Therefore you can read / write such documents and images from / to databases as BLOBS. Moreover server based applications can create documents like PDF or HTML very fast in memory (without disk I/O overhead), and stream them for example via HTTP to web browsers.

 

Reading / Writing Document Page Ranges (Professional Edition and higher)

VPE Document files can now be read and written in a specified page range, e.g. from page 5 to page 8, instead of all pages.

 

Stream-Based VPE Documents can be modified On-Disk (Professional Edition and higher)

Stream-based VPE documents (i.e. opened with SwapFileName set / DLL: VpeOpenDocFile() is used) can now be modified ON-DISK, i.e. you can clear, add, insert and remove pages or objects (removal of objects only offered by the Enterprise Edition and above). In previous versions of VPE, after a document page was written to disk, it could not be modified.
Stream based documents can become fragmented, if you are adding a lot of new objects to a page which has already been written to disk. Especially if you are adding objects in multiple steps, i.e. you add some objects, seek to another page, seek back and add again objects and so on, or open and close the document file repeatedly while adding each time new objects. This will result in decreased performance when reading pages of document files.

Defragmenting document files:
Open the document file with SwapFileName (DLL: use VpeOpenDocFile())
Call WriteDoc(<new file name>)
The file <new file name> is defragmented, whilst requiring nearly no memory for the operation.

 

Delays When Calling OpenDoc() Removed

VPE does no more query the default printer when calling OpenDoc(). Network printers which had been offline caused huge delays each time calling OpenDoc(), because the printer was queried by VPE. Now a printer is queried when any of the printer or printing related methods is called.

 

RTF (Professional Edition and higher)

Properties Superscript and Subscript implemented
Property StrikeOut (keyword: "strike") implemented

 

One-Dimensional Barcodes (Enhanced Edition and higher)

The barcodes of type Code 128 / EAN 128 now allow to insert FNC1 - FNC4 control codes, and the character set (A, B or C) can now be forced to be switched to a specific character set (this overrides the automatic charset switching).

 

New Supported Image Types (Enhanced Edition and higher)

For TIFF images also JPEG compression (v7) is now supported (not the old 6.0 specification).

In addition to TIF, GIF, BMP, PCX, JPG, PNG, EMF, WMF now the following new image file formats can be imported:

Notes:

 

Importing Multi-Page Images (Enhanced Edition and higher)

Pages can now be extracted not only from Multipage-TIFF files, but also from Multipage-GIF and Multipage-ICO files.

 

Exporting  Multi-Page Images (Enhanced Edition and higher)

Writing Multipage-TIFF and Multipage-GIF is also supported.

 

New Dithering Algorithm for Picture Export (Professional Edition and higher)

Dithering to 256-colors is now done by color-reduction using the NeuQuant neural-net quantization algorithm, which delivers very good quality. In addition the faster Xiaolin Wu color-reduction algorithm can be selected.

 

Scale2Gray and Scale2GrayFloat (Professional Edition and higher)

Scale2Gray and Scale2GrayFloat now have a much higher quality, but they are significantly slower. This is, because these routines are written in pure C++ (before, they had been written in Assembler). The advantage is that the code can be ported to different platforms now.

 

Gradients Enhanced

For gradients a third middle color can be defined, so three-dimensional gradients can be created.

 

Base 14 Fonts Embedded in VPE DLL

The base 14 AFM files are now compiled into the vpe.dlls, therefore they are no longer shipped with the installation and they are no longer required. Beside the advantage that they do not need to be shipped and installed when deploying VPE, the VPEFont.lst file is no longer created at runtime on Windows and Mac platforms (which was a catalog file with information about the AFM files).

 

Default Charset on Mac OS X

The default charset on Macintosh is VCHARSET_MAC_ROMAN. If you have created text with non-ASCII characters (for example umlauts) on the Windows platform and wish to use them on the Mac, then set Charset = VCHARSET_DEFAULT.

 

Other Enhancements

 


 

Compatibility Issues

 

Introduction

We made a lot of changes and improvements to the inner code, as well as cleanups for the API. This guarantees platform independence as well as a stable code base and a consistent API that will last at least for the next ten years.

Major changes: we changed the internal coordinate system (which now has a precision of 0.0001 mm), the external coordinate system of the API and the text rendering engine.

But don't panic. We spent huge efforts to allow to port your old source code to the new engine with only two lines of code.
If you want to use your old source code, you have to insert the following code after calling OpenDoc():

VPE.UnitTransformation = VUNIT_FACTOR_MM10
VPE.EngineRenderMode = VENGINE_RENDER_MODE_VER3

That's it.

But when using the Ver3-Renderer, your source code and the created documents are not platform independent. The Ver3-Renderer is using the Windows API to render text. The new Ver4-Renderer is using our own platform independent code, so text is rendered on all platforms (Windows, Mac OS X, Linux, Unix, Solaris, etc.) identically. For new applications, we strongly recommend to use the new rendering engine to gain platform independent source code and documents. The Unit-Transformation is up to your preferences, but basically it will be easier to use centimeters or inches instead of 1/10th of millimeters.

For details about differences between the Ver3- and Ver4-Renderer, please see below.

 

Important:

 

Coordinates

The new internal coordinate system now has a precision of 1/10.000 mm. The VPE API provides a new universal coordinate unit transformation mechanism! You now supply double values (typed as VpeCoord) to the VPE API and select whether the supplied values are in centimeter units, inch or in the old classical 0.1mm way.

Example in centimeters: VPE.Print(1.5, 1.5, “hello world!“)

Therefore all methods / properties which received a 0.1mm coordinate have been changed to the data type double.

With: VPE.UnitTransformation = VUNIT_FACTOR_MM10 you can switch back to the old unit transformation, so that your old source code is fully compatible to VPE v4.0.
With: VPE.UnitTransformation = VUNIT_FACTOR_CM you switch to the centimeters unit transformation, this is the default after calling OpenDoc()
With: VPE.UnitTransformation = VUNIT_FACTOR_INCH you switch over to the inch unit transformation

NOTE: if you are using embedded flags to set the pen size, e.g. "[PS 3]", you must take into account the current settings of the UnitTransformation. I.e. if VPE.UnitTransformation = VUNIT_FACTOR_CM, then "[PS 3]" means 3cm. To make it 0.03cm, you must specify "[PS 0.03]".

 

New values for the V-Flags (VFREE, VLEFT, etc.)

Due to the new internal coordinate system, the values of the V-Flags needed to be changed. If you have always used the V-Flags in your source code, then you need nothing to do, but recompile your program. If you have used constant values like -1 instead of VFREE, then you need to change your source code. If you change it, you should start using the V-Flags.

 

New platform independent text rendering engine

New platform independent rendering engine, which works identical on Windows as well as on Mac OS X, Linux, Solaris and all other platforms. Due to the new rendering engine, text strings are computed a bit wider and a bit less in height than in v3.x. So in very rare cases it can happen that word breaks occur on different positions than in v3.x, which means that text objects might require more width than before, but also less height. For this reason we implemented a property, so you can switch back to the original rendering engine. This can be achieved by setting EngineRenderMode = VENGINE_RENDER_MODE_VER3. This is useful to adapt your existing code to this new version of VPE. But the old rendering engine is only available on Windows. Therefore, for platform independence, it is strongly recommended to use the new rendering engine. It is also likely that the old rendering engine will be removed in a future version of VPE (in several years).

The new font manager of VPE supports the following character sets:

 


VPE can not use Bitmap Fonts

For all versions of VPE it was always recommended not to use bitmap fonts (like for example "MS Sans Serif"). And why should someone want to use them? They are displayed and printed ugly, since they can not be scaled smoothly. They could be used with prior version of VPE, but with limited precision and accuracy. With VPE v4.0 bitmap fonts can definitely not be used. They will be displayed on Windows platforms, but the internal rendering is based on the "Arial" font and will therefore be completely wrong, leading to a bad layout. Once again: VPE can not use bitmap fonts.

 


The Preview now opens by default in a "Fit to Window Width" mode

A "Fit to Window Width" mode for the preview is now by default activated. This means the scale is computed accordingly to the width of the preview, so the displayed page fills the preview from the left to the right. In order to gain the old preview behaviour, set the property ScalePercent = 100 immediately after calling OpenDoc(). See also the new property ScaleMode.

 

Win95/98/Me and NT no longer supported

It is possible that VPE works on those platforms, but we haven't tested it and they are no longer officially supported. VPE does not execute on Win95 due to missing symbols in kernel32.dll.

 

DXF support dropped

VPE can no longer import DXF files. If this is an issue for you, use the following workaround: Acquire a license of the Davinci image import library (www.herdsoft.com) and use it for importing DXF files as Enhanced Metafiles (EMF). Provide the EMF to VPE.

 

FLT support dropped

VPE can no longer use the Microsoft Office image import filters (did anyone ever use them? We doubt it.)

 

The flags parameter for the Picture()-method has been eliminated

Each flag is now implemented as property. Some flags have been removed, because they were way too complicated and no one did ever use them.
The new properties (for VPE documents as well as for VPE objects) are:
bool PictureCache (was: PIC_KEEPIMAGE, default is true)
bool PictureScale2Gray (was: PIC_SCALE2GRAY)
bool PictureScale2GrayFloat (was: PIC_SCALE2GRAY_FLOAT)
bool PictureX2YResolution (was: PIC_X2YRESOLUTION)
bool PictureBestFit (was: PIC_BESTFIT)
bool PictureEmbedInDoc (was: PIC_IN_FILE)
bool PictureDrawExact (was: PIC_EXACT)

 

New VpeHandle data type (DLL only)

VpeHandle data type introduced for 64-bit compatibility. Use for all handles now this new type: Document, Polygon, Polyline, Bookmark, Table, Field, DataSource, Object, Control, Streams
On 32-bit platforms VpeHandle is a 32-bit integer value, on 64-bit platforms it is a 64-bit integer value.

Example: VpeHandle hDoc = OpenDoc(...)

 

New Ordinals (DLL only)

The ordinals of the VPE DLL’s have changed. If you are using the DLL and if you are importing the functions of the DLL by ordinals, you must reorganize the ordinals. If you are using C/C++ and have been linking against our import library or DEF file, we have done the work for you. Just link to the new import library / def file.
If you are importing the DLL functions by name, you only need to delete the functions we have removed from the DLL as listed above.

 

Other Minor Compatibility Issues (mainly cosmetic changes)

 


 

Fonts and Font Handling

It is important that you have some basic knowledge about the font handling mechanisms provided by VPE. You can instruct VPE to print text using a specific font.

There are two possible types of fonts that can be used:
 

Base 14 Fonts

These 14 fonts are post script fonts for PDF Readers (like Acrobat Reader). The PDF specification says that standard PDF readers must support these fonts – and most of them do. That means, all good PDF readers have those 14 fonts built-in. You do not need to care, if the fonts are installed and there is no need to ship them with your documents or to embed them into your documents - which keeps the generated PDF documents as small as possible.

The Base 14 fonts are:
Helvetica (bold, italic, bold-italic) – Nearly identical to the Arial True-Type font
Times (bold, italic, bold-italic) – Nearly identical to the Times New Roman True-Type font
Courier (bold, italic, bold-italic) – Nearly identical to the Courier New True-Type font
Symbol – A symbol font, like the WingDings True-Type font
ZapfDingbats – Another symbol font

Advantages of using the Base 14 fonts:
No need to care, if the fonts are installed, no need to ship them with your documents or to embed them into your PDF documents.
Generated PDF documents are as small as possible.

Disadvantages of using the Base 14 fonts:
Some character sets are not supported by the Base 14 fonts. Supported character sets are: WinAnsi, WinEastEurope, WinTurkish, WinBaltic, IsoLatin1, IsoLatin2, IsoLatin5, IsoLatin7, IsoLatin9. MacRoman is nearly fully supported, but the following characters are missing:
unicode 221e (ansi code 176) INFINITY
unicode 220f (ansi code 184) GREEK CAPITAL LETTER PI
unicode 03c0 (ansi code 185) GREEK SMALL LETTER PI
unicode 222b (ansi code 186) INTEGRAL
unicode 03a9 (ansi code 189) GREEK CAPITAL LETTER OMEGA
unicode 2248 (ansi code 197) ALMOST EQUAL TO (asymptotic to)
unicode f8ff (ansi code 240) Apple Logo
When previewing or printing a VPE document (not a PDF document!) that uses the base 14 fonts (note: this applies currently only to the Windows version, for the other platforms there is no preview / direct printing capability): The metrics of the base 14 fonts are nearly identical to their True-Type pendants, but they are not 100% identical. When using an on-screen preview, or if printing directly via VPE, the font manager will chose the True-Type font counterparts of the post script fonts for the output device (this is called font-substitution), and documents render quite well, but you can not expect 100% perfectness. This means, in regular (99,99%) you will not be able to detect any visible flaws. Text might be rendered slightly a bit more dense than it would, if a True-Type font was used directly for rendering a document (without substitution).
The PDF/A standard, which defines documents for long-time archival, says that even the base 14 fonts (i.e. the postscript data) must be embedded into PDF documents in order to make them PDF/A compliant. Currently VPE is not capable of creating PDF/A documents, but a future version will. However, at the time of this writing we can not guarantee that VPE will be able to embedd the base 14 fonts into PDF documents, because of technical as well as for licensing issues.

 

True-Type / OpenType Fonts

VPE accesses, analyzes and evaluates directly the binary data of True-Type / OpenType fonts (in the following called TT fonts), including an internal cache for high performance rendering.
VPE can embed TT fonts into PDF documents. The Enterprise Edition of the PDF Module can also embed subsetted TT fonts, which means that VPE generates and embeds on-the-fly a newly generated TT font, which only contains the used characters. This reduces the size of the embedded fonts and therefore the overall size of generated PDF documents.

NOTE: Some TT fonts have set flags, so the font creator does not allow to embedd or subset a font. VPE respects the font licensing specifications and will deny to embed / subset such fonts.

Using TT fonts on Windows and Mac OS X platforms is very transparent and easy (for you as a user). Both platforms have a built-in font manager, which is used by VPE. For example, if you instruct VPE to use the Arial font for a portion of text, VPE will call the font managers of either Windows or Max OS X and ask them to provide the font. The font managers themselves care for the list of available fonts on the current machine and which font file at what location needs to be selected and loaded into memory.

On all other platforms (Linux, Unix, Solaris, etc.) VPE uses its own font manager for handling TT fonts. When deploying VPE on a certain machine, you must inform VPE's font manager where to find TT fonts. This is done by setting the environment variable VPE_FONTPATH. It may contain a list of paths separated by semicolons where VPE shall scan for available TT font files (with the suffix .ttf, e.g. arial.ttf). On each startup, i.e. when VPE is loaded into your application, it will search for a file named „font.catalog“. VPE's font manager stores information about available TT fonts in this file. If the file is not present, VPE will create it by scanning for TT font files in the search path(s) specified by VPE_FONTPATH. If VPE_FONTPATH is not set, VPE will not perform such a scan and therefore no font.catalog file will be generated. The resulting font.catalog file will be written to the directory location specified by a second environment variable: VPE_CATALOGPATH. If this variable is not set, VPE will use the first directory specified in VPE_FONTPATH as output directory. Make sure that in either case the output directory has write-permissions, so the catalog file can be written.
If you add TT font files later to the system, or if you move files to different locations, you must delete the font.catalog file in order to let VPE rebuild it with the most current information.

Advantage of True-Type / OpenType fonts
Much greater selection of available fonts than the base 14 fonts
PDF/A compliant font embedding supported
Windows version only: no font substitution takes place to substitute post script with TT fonts for the preview and printing

Disadvantage of True-Type / OpenType fonts
You can not assume that receivers of your PDF documents have the TT fonts installed on their systems, so you need to embedd all TT fonts into the generated PDF documents, which makes the PDF documents larger in size. In addition embedding / subsetting requires slightly more CPU time.
On Linux / Unix / Solaris the font management must be initialized by yourself, by setting the environment variables VPE_FONTPATH and VPE_CATALOGPATH properly. It might also be neccessary to ship and install required TT fonts with your application (take care of the licensing!).

 

Font Substitution

For PDF export VPE offers a method for font substitution. By using the method SetFontControl() you can instruct VPE to substitute a given font with another. This is especially helpful for developing Windows applications: You can use the Arial, Times New Roman and Courier New TT fonts for the preview and printing, and for PDF export you instruct VPE to use the Base 14 counterparts.

Whilst SetFontControl() is only active during the export to PDF, there is a second generic method to substitute fonts: SetFontSubstitution()
By using this method, VPE will substitute fonts immediately when creating a document. This is especially useful on Non-Windows platforms when importing RTF (Rich Text) documents. Often RTF documents are created on Windows platforms and use Windows specific True-Type fonts. With this method you can instruct VPE to substitute for example the True-Type font "Arial" with the Base 14 font "Helvetica", so Helvetica is used in place of Arial.

 

Making a Decision, Which Type of Font to Use

If you are developing for the Windows or Mac platforms only, and if you are sure that all receivers of created PDF documents (for example by e-mail) are using a Windows or Mac machine, and you are using only the basic three TT fonts which are installed by default on any Windows machine (i.e. Arial, Times New Roman, Courier New), then you can safely use TT fonts.
For Windows application development you can also use font substitution, in order to use TT fonts for the preview and printing and Base 14 fonts for PDF export.

If you are developing for the Windows or Mac platforms only, and if you are using other TT fonts, or if receivers of created PDF documents might be using other platforms than Windows or Mac machines, you can not assume that even the basic three Windows TT fonts are present on the receiver's machine. In this case you need to embedd the TT fonts into the PDF document (which increases its size), or you use the Base 14 fonts.

If you are doing cross-platform development, e.g. your application shall run on Windows, Mac OS X and Linux, you either better use the Base 14 fonts only, or you must make sure that the used TT fonts are present on each target machine (and platform) of your application, because for the creation of documents VPE requires to have access to the fonts. This might require that you license the fonts for distribution. In addition you should embedd the TT fonts into created PDF documents.

Adobe recommends to embedd TT fonts always into PDF documents.

The demo executables shipped with VPE are compiled for each supported platform, so they are using the Base 14 fonts only.