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.
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.)
The VPE SDK (Software Development Kit) must now be licensed per machine it is installed on. Before, a license was required per developer.
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.
A new site license for one physical (respectively postal) address is now available for the VPE SDK.
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.
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.
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.
The VPE SDK (Software Development Kit) ships with help files in the HTML-Help format with a complete new and nicer layout.
The help files are now integrated into Visual Studio, including context sensitive help (F1 key).
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.
VPE documents can now be exported to HTML.
Implemented four new two-dimensional barcode types:
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 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.
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.
The scrolling code has been reworked and the scrolling is much finer and smoother now.
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()
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).
New Property CornerRadius, which allows to draw boxes, text and RTF with rounded corners.
VPE documents can be written compressed, this is the default now (see property „Compression“). The new compression makes VPE documents about 60 - 80% smaller.
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 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!
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.
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.
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 (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.
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.
Properties Superscript and Subscript implemented
Property StrikeOut (keyword: "strike") implemented
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).
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:
- ICO (Windows Icon)
- JNG (JPEG Network Graphics)
- KOA (C64 Koala Graphics)
- IFF/LBM (Interchangeable File Format - Amiga/Deluxe Paint)
- MNG (Multiple-Image Network Graphics)
- PBM (Portable Bitmap, ASCII or RAW)
- PCD (Kodak PhotoCD, reads always the 768 x 512 pixel image)
- PGM (Portable Greymap, ASCII or RAW)
- PPM (Portable Pixelmap, ASCII or RAW)
- RAS (Sun Raster Image)
- TGA/TARGA (Truevision Targa)
- WAP/WBMP/WBM (Wireless Bitmap)
- PSD (Adobe Photoshop, only 24-bit RGB or 24-bit RGB RLE, no layers / masks)
- CUT (Dr. Halo)
- XBM (X11 Bitmap Format)
- XPM (X11 Pixmap Format)
- DDS (DirectX Surface)
- HDR (High Dynamic Range Image)
- G3 (Raw fax format CCITT G.3)
- SGI (SGI Image Format)
Notes:
Pages can now be extracted not only from Multipage-TIFF files, but also from Multipage-GIF and Multipage-ICO files.
Writing Multipage-TIFF and Multipage-GIF is also supported.
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 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.
For gradients a third middle color can be defined, so three-dimensional gradients can be created.
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).
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.
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:
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]".
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 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:
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.
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.
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.
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.
VPE can no longer use the Microsoft Office image import filters (did anyone ever use them? We doubt it.)
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)
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(...)
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.
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:
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.
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!).
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.
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.