PROGRAMMING GUIDE
HOOPS Publish is the 3D PDF export library from Tech Soft 3D. Publish enables the developer to export a HOOPS Visualize scene to a 3D PDF file. An introduction to Publish can be found here.
All Publish classes are members of the Publish container class.
A separate license is required to use HOOPS Publish. The interface described on this page is the way to connect Visualize with HOOPS Publish. Publish is only supported on Windows only (C++ and C#).
Steps for integrating HOOPS Visualize with HOOPS Publish are delineated below:
HOOPS Publish is distributed from the Tech Soft 3D Developer Zone - the first step is to download and install it. You do not have to generate a separate key to use the Publish component. The key will be embedded with your Visualize license key.
Publish uses the environment path to find the location of the supporting libraries. Add the location of the libraries to the path (note the different locations for 32 and 64-bit DLLs), for example, C:\Program Files\HOOPS_Publish\bin\win64.
The Visualize-Publish interface library must be included as a dependency. C++ users will need to link to hps_sprk_publish.lib or hps_sprk_publish.so. C# users need to reference the hps_cs_sprk_publish_vc11 assembly.
Your source files that use the Visualize-Publish interface must include sprk_publish.h.
At this point, Publish is ready to use in your application.
When initializing the World object in your application, you must also set the Publish resource directory. This directory is part of the Publish installation.
To export a Visualize model using HOOPS Publish, the view hierarchy must already be in place with the model residing in the Model segment. Once that prerequisite is met, only a few calls are required:
The Publish API is completely synchronous, so the export is complete once the call to Export returns.
IMPORTANT: The filename parameter to Publish::File::Export must include a fully-qualified path, or the export will fail.
To make a more complex PDF document, more work is required. In the following example, a document with two views is created, but the logic could be extended to accommodate other enhancements. Performing this complex export means interacting directly with the Publish API, including creating and configuring the Publish document object hierarchy.
To set up each of the views, we'll use a regular Visualize CameraKit. The views are contained in an Publish::ArtworkKit object.
You'll need to set the SprocketPath (which contains the view hierarchy, see snippet 9.5.3.c) as the source of the Publish::AnnotationKit. When configuring the Publish::PageKit object, it is possible to specify what portion of the page that HOOPS Publish will appropriate for the 3D model. This is done by passing an IntRectangle, specified in points. Annotations are always specified using a rectangle. The origin is the bottom left corner of the page.
Annotation kits can also be compressed by setting the compression options before export, as shown in the code snippet below. The compression algorithm is a lossy algorithm.
IMPORTANT: The filename parameter to Publish::File::Export must include a fully-qualified path, or the export will fail.
A PDF template is a special type of PDF file that might contain text fields, graphics, and blank areas that you can fill in with your data in order to compose a complete file. In Visualize, templates are manipulated using the Publish::PageKit object.
A few sample templates are included with the HOOPS Publish package. This particular example is using BOM_A4Table_L.pdf. Whenever you are working with templates, you need to know beforehand the internal names of the fields that you want to fill in with data (there is no way to programmatically enumerate the field names). The template file in this example was generated using the source file found at <PUBLISH INSTALL DIR>\samples\publish\publishsource\BillOfMaterial\BillOfMaterial.cpp, and the field names can be found inside that file.
To export with a template, you would follow the steps in the previous snippets, but add the following template export code to your calls to Publish::PageKit. This code example will put the Visualize model into the "My3DWindow" field:
You may have noticed the "_1" suffix on the field names. The suffix indicates the page number of the PDF that you're exporting to. So, to export to page 2, you would use a suffix of "_2". In this way, you have control over the data that gets inserted at the page level. This example only has one page, but the field suffix is required nonetheless.
Publish allows you to add links in the PDF document on the exported pages. In the context of a PDF document, links are regions of the page which, when clicked, will invoke JavaScript embedded in the document. It's important to note that the link itself is just a rectangular region on the page, which may have an associated color, border, and highlight mode. It does not contain text or images. If you want a text string or an image to appear at the link location, that needs to be inserted separately using the appropriate API functions.
Buttons can be added anywhere on the page. Size is specified with a rectangle - all other options are set in the Publish::ButtonKit.
Button logic is handled with Javascript that you add to the PDF document's Publish::PageKit.
In HOOPS Publish, tables added to PDF documents are defined in HTML and styled with CSS. A Publish::TableKit is required when inserting tables.
Tables can be filled with data hard-coded in the HTML, or you can fill the fields programmatically:
Additionally, buttons can be added to tables in the following way:
A slide table is an HTML table that can be scrolled using buttons. Slide tables are defined in HTML, just like normal tables. HOOPS Publish expects a "previous" button, and a "next" button to control the scrolling. You do not need to write logic for the slide table buttons - it is written automatically by HOOPS Publish.
So far, we have talked about building and exporting PDF files, but HOOPS Publish also allows you to open, inspect, modify, and write a PDF that already exists. To create an in-memory copy of a PDF, use the following code:
The code in snippet 9.5.5.a loads the file specified by filename and returns a Publish::DocumentKey. The Publish::DocumentKey can then be used to query and modify the structure of the PDF. Most of the functions correspond with the functions on Publish::DocumentKit, however, the Unset and Show functions are not available due to limitations in the Publish API.
If you need to make changes to a particular page, rather than make a document-wide setting, use the Publish::PageControl:
After you are finished making changes to the file, simply re-export the document the same way you would export a newly created file. The only difference is that you would use the Publish::DocumentKey instead of a SprocketPath or Publish::AnnotationKit.
Associated memory in HOOPS Publish is freed when the last Publish::DocumentKey reference goes out of scope, or the developer calls Delete on it.
Not all data in a Visualize scene is exportable via Publish. For those entities that are supported, Publish has its own internal representation; others are not supported at all. The table below lists entites that are exportable. If an attribute or entity is not mentioned in this list, you can assume it will not be exported.
Visualize entity | Notes |
---|---|
Color | Color is exportable in general, however, vertex and edge color interpolation is not exportable. |
Curves and lines | All non-facetted geometry is converted to polylines for export. Line patterns are not exported. |
Edges | The implicit edges of a tessellated piece of geometry are exported. However, viewing them requires setting a particular rendering mode in the resulting PDF, and there is no granular control for the visibility of different types of edges like in Visualize. For example, you can set any of the rendering modes with Wireframe in the name, such as Publish::Rendering::Mode::[SolidWireframe, TransparentWireframe, Wireframe]. Edge patterns are not exportable. |
Facetted geometry | All facetted geometry, including NURBS surfaces, is converted to a shell for export. Note that if face visibility is off, the geometry will still be exported but will not be visible by default (the user can toggle this using the tree control from within PDF Reader). Per-face visibility and color are supported for shells. Face patterns are not exportable. |
PMI data | PMI data is exportable if the original model was imported with PMI data |
Text | All text is exported as UTF-8 and comes through as markup in the PDF. Font name, size, alignment, bold, italic, overline, strikethrough, underline, transforms, and line spacing are exportable. Some information is lost in the translation from Visualize to PRC. For instance, the text insertion point for PRC is always the lower left, so any alignments are translated into moving the insertion point. PRC doesn't have multiline text strings, so these must be split into multiple lines (though still in a single markup), and things like line spacing are implicitly defined by the position information for multiple text strings in a markup. Additionally, screen-facing text will always be a fixed size. |
Textures | Only diffuse and environment textures are supported. |
Vertices | Vertices are visible if you set Publish::Rendering::Mode::Vertices or Publish::Rendering::Mode::ShadedVertices However, there is no rendering mode which allows vertices to be visible with faces and lines. |
IMPORTANT NOTE: PRC data is exportable only if it was originally loaded with Exchange. If you use Publish to export a model that was loaded from Exchange, just the PRC data imported from Exchange will get written to the PDF (no scene graph changes will get exported). However, if you export a model that did not come from Exchange, the PRC data will be constructed from the scene graph and put into the PDF.
During the import process, Publish will trigger events when it detects a problem or has information to give you. For example, if Publish couldn't find a referenced subcomponent in an assembly, or if there was some sort of import failure, a warning or error could be triggered. It the responsibility of your application to catch these events and respond appropriately.
The Visualize-Publish interface will capture all events and wrap them into one of three types: InformationEvent, ErrorEvent, or WarningEvent. Each of these types derive from Event, thus, handling them is identical to handling any other type of Visualize event (event handling is discussed here).
WarningEvent contains both a code and a message, while InformationEvent has only a message.
When you attempt to add any object to a Publish page, Visualize pulls the data out of the kit and passes it to HOOPS Publish. Thus, if you pass an empty or invalid object, Visualize will pass the equivalent structure to Publish. If Publish returns an error, Visualize will throw an IOException, which includes a string describing the problem as well as the error code generated by Publish.