Delphi support and PDF font extraction

Q: I have a some questions about your PDFNet SDK product.

1) Is their a Delphi version of the SDK? Either a Delphi wrapper, or
an ActiveX implementation?
2) Is it possible using the SDK to extract embedded fonts from a PDF?
3) If 2 is possible can the extracted fonts then be installed into
Windows and used like any other font? For the record, I am only
interested in rendering the content of the document that contained the
font.
-----
A: At the moment there is no direct support for Delphi. Currently
PDFNet SDK is available in several editions:

- As a .NET component for C#, VB.Net etc.
- As a Java component (Win, Mac, Linux).
- As a C/C++ SDK (Win, Mac, Linux).
- As Windows Mobile C/C++ SDK.

Regarding the integration issues with Delphi, probably the simplest
approach would be to use C/C++ to implement a custom ActiveX control
that you can directly access from Delphi. Instead of implementing
wrappers for all PDFNet methods you would only expose the minimum
functionality (e.g. a single function call to perform a given
function).
Since PDFNet is available as a plain "C" DLL, you could also create
Delphi wrappers (e.g. using Dr.Bob's Delphi Clinic: Using C DLLs with Delphi (and HeadConv v4.20))
however this is probably more work than necessary.

2) Is it possible using the SDK to extract embedded fonts from a PDF?

You can use PDFNet to extract embedded fonts. There is a utility
function in Font class called font.GetEmbeddedFont() [
http://www.pdftron.com/net/html/classpdftron_1_1PDF_1_1Font.html ]

The font can be extracted and saved on file system (e.g. in System
fonts folder). Please keep in mind that PDF supports some font formats
which are not supported by Windows (such as Type1, CID, CFF, Type3,
etc). Also some fonts may be subsetted and unusable in many Windows
applications.

PDFNet also includes a method (pdftron.PDF.Font.GetGlyphPath()) to
extract glyph outlines from any font (embedded or not). Using this
method you should be able to obtain vector outlines for each glyph.
The outlines can subsequently be used to render PDF text, without
relying on Windows GDI font engine.

Q: Thank you for your reply.

Your comment about extracting and rendering fonts was spot on.

Essentially what I need to do is extract all the pdf page elements
such that each page can be interpreted and rendered in the native
format
supported by a particular printer at 600x600dpi. In my search for
alternatives I created a Delphi import unit for your PDF2ImageSDK and
did some rough timings. It's way better than ghostscript but it is
still not going to be fast enough by an order of magnitude for our
needs. Your documentation suggests that PDF2ImageSDK was developed
with PDFNet SDK so it would appear that the SDK contains the necessary
functionality to extract the required page elements and thus allow me
to skip much of the intermediate rasterization. For example I could
pre-flight and extract, and render all necessary font glyphs and
images once in the required sizes,etc.

Given that there isn't an already existing ActiveX implementation of
the PDFNet SDK, I would be much more inclined to create a Delphi
import unit for your plain "C" dll. From there I could develop a
wrapper that would simplify usage if necessary, perhaps modeled
directly upon your existing
C++/C#/Java api's. For me at least this is probably the fastest
path
to determining whether the SDK will meet our needs. To that end where
can I obtain the C header file(s)? Is there C sample code?
----
A: PDFNet SDK "C" headers are located under PDFNet/Headers/C (http://
www.pdftron.com/downloads.html#PDFNETCPPSDK). A C++ wrapper is located
under 'PDFNet/Headers'. There are no concrete samples of how to use
the C API although you can create a C version of any C++ sample by
replacing the C++ methods with their implementation (located under
'Headers\Impl'). Most of the C++/C#/JAVA methods have direct C
equivalents (roughly it is 1-1 mapping). Have you considered
implementing the conversion solution in C++ and then exposing a single
'C' function for integration with Delphi. It seems that this approach
would significantly simplify the integration with Delphi.