The HOOPS Publish HIO component (HIO Publish) supports exporting the HOOPS/3DGS scene-graph to the 3D PDF format. It utilizes the HOOPS Publish API to achieve this. Before using this component, developers should become familiar with HOOPS Publish, as well as the general HIO architecture and capabilities covered in section 4.0 of the HOOPS/MVO Programming Guide.
The HIO Publish component is delivered in the form of a .hio file, which gets dynamically loaded by HOOPS Visualize at runtime. To ensure your application can access the HIO Publish component, perform the following:
During start-up, when HOOPS/MVO finds the HIO Publish component and HOOPS Publish .dlls, it will perform the following steps:
Once the HIO Publish component is successfully loaded, your application will be able to export the HOOPS/3DGS scene-graph to 3D PDF files.
The hio_publish module supports the following export cases, with each approach detailed down below:
Basic export involves:
You could additionally specify the handle to an existing PRC model, which is what makes up the 3D part of 3D-PDF. Specifying the PRC handle tells the HIO Publish module to directly utilize the existing PRC data and embed it in a 3D-PDF document, rather than traversing the HOOPS scene-graph information. This may be desireable if you are using HOOPS Exchange to bring in native CAD files (After a CAD file is imported witih HOOPS Exchange, you have access to a PRC handle). This approach is achieved by setting the HOutputHandlerOptions::m_pPRCAsmModelFile attribute to the PRC model handle, prior to calling FileOutputByKey:
HOOPS Publish provides the ability to create a PDF based on an existing PDF 'template' that contains named fields which can be modified/populated via HPDFLayoutManager methods. HOOPS Publish includes a handful of templates, and they can be viewed/edited using Acrobat Professional. You can also create your own template.
Exporting a file based on a template involves:
This requires first exporting the scene-graph to a PRC model, which has already been covered above. It involves getting the HIOUtilityPublish handler, and calling HIOUtilityPublish::BuildPRCModel to obtain a pointer to the PRC model information.
You would now access HOOPS Publish APIs to create a custom PDF document, and then embed the PRC model inside.
Certain types of models may contain large amounts of implicit primitives, which can in turn result in large amounts of tesselation information during export. This can cause large 3D-PDF (and PRC) files, an increase in memory usage, and excessive export-time. If you have a scene with a large amount of HOOPS/3DGS cylinders and/or spheres, the following steps can greatly improve export performance and reduce file size:
The HOutputHandlerOptions::m_ePrcBrepCompression setting can reduce 3D-PDF file size when exporting PRC BRep data. (Typically this is data that came from a CAD file imported via HOOPS Exchange.) This setting will have no effect if there is only HOOPS/3DGS tessellation data being exported to 3D-PDF or PRC.
In general, most HOOPS/3DGS scene graph information is exported to 3D-PDF, with the following exceptions:
Text encodings supported:
Other encodings are not supported (e.g., "jec", "euc", "16").
Text font settings supported:
Text font settings not supported:
Regarding font names, any built in fonts (like "stroked") will become the default font when the PDF is loaded. Additionally, any font requests put in the PDF will display as some default font if the PDF is loaded on a system that doesn't have the requested font.
Regarding font sizes, transformable text in a PDF will always be scalable (so, sizes like points, pixels, sru, or wru will not have the same behavior as in Visualize). Additionally, screen-facing text will always be a fixed size (thus, sizes like sru or wru will not have the same behavior as in Visualize).
Text paths are supported, but text will always appear as if "rotation = follow path" is set.
Text alignments (HC_Set_Text_Alignment) are supported.
Text regions (HC_Set_Text_Region), text spacing (HC_Set_Text_Spacing) and per-character attributes (HC_MSet_Character_Attributes) are not supported.
Text will always come through as markup in the PDF (since that is the only option in PRC). Additionally, 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.