We’re developing a WYSIWYG editor in our web application to create newspaper ads. The editor is based on HTML and supports justified text (text-align: justify) for body-text-style ads. The content is rendered in the browser for preview and later passed to PrinceXML for generating high-quality print-ready PDFs (compliant with standards like ISO Newspaper and including embedded fonts).
Issue:
We’re consistently facing discrepancies between how text is rendered in the browser (Chrome, Firefox, Safari) and in the resulting PDF generated by PrinceXML:
• Line breaks and text wrapping differ between the HTML preview and the PrinceXML PDF.
• This often results in extra or missing lines in the PDF.
• Since we calculate the height of the ad externally and pass it to PrinceXML, the mismatch can cause:
• Text overflow (content spills out of the defined box), or
• Unwanted whitespace at the bottom if the PDF has fewer lines.
We are aware that there are already slight differences between browsers themselves (Chrome vs. Firefox vs. Safari), but this is tolerable. The real problem is that the final PDF (which gets printed in the newspaper) does not match the preview the user sees in the editor.
• The PDF output must meet professional print requirements:
• CMYK color space or ISO Newspaper profile
• Embedded fonts
• Full typographic control
• A screenshot or basic browser-based PDF rendering (e.g., via Puppeteer) is not sufficient for print quality.
What We Need:
We are looking for:
• Solutions or best practices to make the browser preview match the PrinceXML output as closely as possible.
• OR: architectural changes to the preview process (e.g., rendering PDF previews using PrinceXML instead of browser rendering).
• Alternatives to PrinceXML that offer high-quality typesetting and full CSS3 + print feature support (PDF/X, ICC profiles, font embedding, etc.).
Issue:
We’re consistently facing discrepancies between how text is rendered in the browser (Chrome, Firefox, Safari) and in the resulting PDF generated by PrinceXML:
• Line breaks and text wrapping differ between the HTML preview and the PrinceXML PDF.
• This often results in extra or missing lines in the PDF.
• Since we calculate the height of the ad externally and pass it to PrinceXML, the mismatch can cause:
• Text overflow (content spills out of the defined box), or
• Unwanted whitespace at the bottom if the PDF has fewer lines.
We are aware that there are already slight differences between browsers themselves (Chrome vs. Firefox vs. Safari), but this is tolerable. The real problem is that the final PDF (which gets printed in the newspaper) does not match the preview the user sees in the editor.
• The PDF output must meet professional print requirements:
• CMYK color space or ISO Newspaper profile
• Embedded fonts
• Full typographic control
• A screenshot or basic browser-based PDF rendering (e.g., via Puppeteer) is not sufficient for print quality.
What We Need:
We are looking for:
• Solutions or best practices to make the browser preview match the PrinceXML output as closely as possible.
• OR: architectural changes to the preview process (e.g., rendering PDF previews using PrinceXML instead of browser rendering).
• Alternatives to PrinceXML that offer high-quality typesetting and full CSS3 + print feature support (PDF/X, ICC profiles, font embedding, etc.).