A WordPress post and a Ventura publication solve different problems. WordPress stores semantic web content; Ventura expects structured text that can be attached to a publication style sheet. A reliable conversion therefore needs a mapping layer between the two.
Publishing Tools for Corel Ventura provides that layer. The aim is not to reproduce CSS in Ventura. It is to preserve the role of the content so Ventura can format that role properly.
1. Choose and order the source content
Select the WordPress posts or pages that belong in the export. For a book project, put them in publication order before you worry about final typography. Book Builder can also organize front matter, chapters, and other sections as one project.
2. Map WordPress structure to Ventura tags
The plugin’s default mapping is intentionally conventional:
| WordPress structure | Ventura tag |
|---|---|
| Title / Heading 1 | Main Heading |
| Heading 2 | Subheading |
| Heading 3–6 | Minor Heading |
| Paragraph | Body Text |
| Quotation | Block Quote |
| Bulleted list item | Bullet |
| Numbered list item | Numbered List |
| Caption | Caption |
| Table row | Table Text |
| Media reference | Media Reference |
You can change those names to match an existing Ventura style sheet. That is usually preferable to changing a mature Ventura publication just to accommodate an exporter.
3. Preserve meaningful inline formatting
Bold, italic, underline, superscript, subscript, and required line breaks can be represented in Ventura marked text. Verse is handled carefully so lineation is not collapsed into ordinary prose.
The converter is conservative about web-only styling. It does not invent undocumented Ventura codes for arbitrary CSS colors, highlights, font sizes, or other presentation details that do not have a verified equivalent.
4. Run preflight before export
Preflight is where the workflow earns its keep. Modern WordPress content can contain Unicode characters, embedded media, nested formatting, tables, and other structures that an older Ventura text environment may not reproduce exactly.
The plugin reports lossy conversions and unsupported characters rather than silently pretending everything survived.
5. Choose marked text or RTF
Ventura marked text is the most explicit path when you want Ventura paragraph tags and inline codes. It is also inspectable as plain text.
RTF can be useful for a readable proof or a workflow that benefits from richer interchange. The two outputs serve slightly different production needs.
6. Import into Ventura and apply the publication style sheet
Once the marked text is loaded, the Ventura tag definitions control font, size, leading, spacing, indents, numbering, keeps, rules, tabs, and page behavior. That is the point of the conversion: WordPress supplies structured content; Ventura supplies final long-document composition.
7. Let Ventura handle final pagination-dependent features
Table of contents, page numbers, cross-references, and the final index should be updated after the text has flowed through the actual publication. Book Builder can prepare index references upstream, but Ventura should generate the finished index because only Ventura knows the final page numbers.
8. Produce modern formats from the same book project
If the publication also needs EPUB, HTML, or Markdown, Modern Publishing can generate those outputs from the same WordPress book project. That lets WordPress remain the source repository even when Ventura is still the preferred print compositor.
A useful division of labor
The most stable workflow is not “make WordPress imitate Ventura” or “make Ventura understand the web.” It is:
- WordPress: source content, editorial workflow, archive, metadata;
- the plugin: structural conversion, ordering, preflight, tag mapping, index preparation;
- Ventura: style-sheet-driven composition, pagination, print-specific references, final index and output.
See the Ventura marked-text reference for the codes used by the exporter, or the plugin page for the complete feature set.
