All of our conversion APIs transform normalized pages into a common intermediate format. In this internal environment, a page is made establishing a list of objects and resources needed to make up an All Points Addressable (APA) page. The objects from the APA page provide information so that the viewing and printing component can render the objects faithfully through virtually any graphical channel.
The internal page maintains all text and provides you with the ability to search for text or to apply template indexing through external methods. Because each conversion API creates internal pages, there is only one viewing and printing API. This API uses a standard GDI to create device context data.
Each API uses buffers to hold data during the conversion process. They do not store objects. The calling application performs and Input/Output (I/O) command on the APIs behalf. This design lets the applications program control the persistence of objects. The conversion component communicates with the calling application through program callbacks. The calling application then communicates with the conversion component through function calls. All of our APIs use the same calls and callbacks, thus simplifying integration and reducing development time.
Re-entrant Code
All of our conversion APIs are re-entrant, allowing you to transform and view pages on the fly, as well as cache converted resources for enhanced performance.
Communication between the transform components is greatly enhanced with re-entrant code. The conversion component can request an object, such as font, from the calling application. The calling application can then request that the conversion component encode the font prior to its returning from the callback. This lets the calling application cache the converted objects according to its rules. This feature allows you to complete on demand concurrent conversion of multiple pages and resources.