Thoughts on precision and layout in XML-based PDF publishing

kunstx
kunstx Posts: 3
in Font Technology
I’ve spent the last few years researching XML-based publishing and PDF workflows, and I wanted to share a few observations for anyone working in digital documentation or structured publishing.

This started while I was writing academic papers. I could usually get acceptable PDFs, but having precise control exactly where it mattered most was always frustrating.

Most tools can produce PDFs, but once you compare layout precision, typography, usability, and long-term stability, the differences show quickly. Many workflows don’t provide satisfying results when you start measuring details closely.

I went through most of the usual XML-to-PDF stacks: DocBook with XSL-FO and HTML routes, DITA and DITA-OT pipelines, Apache FOP, Prince XML, Paged.js, Typefi-style systems, and a range of enterprise tools. I also spent time with TeX-based workflows. They are incredibly powerful and impressive, but in practice the complexity and friction often push people to admire them more than actually use them day to day.

Where things tend to break down is layout fidelity. Font rendering depends on ambiguous units or web-engine limits, styling has a steep learning curve, and many systems feel disconnected from traditional DTP practices.

After running into the same issues for years, I ended up building my own solution focused on predictable PDFs, stable pagination, and consistent typography. People coming from both the XML world and traditional tools like InDesign seem to feel comfortable with it, which was exactly the gap I was trying to explore.


Curious how others here handle layout precision and PDF stability. Do you go this deep when evaluating solutions, or is the goal usually to provide information and accept the trade-offs at the end?
Tagged:

Comments

  • John Hudson
    John Hudson Posts: 3,607
    Is your solution available? Or can you point to examples of its output?

    I’ve not personally used XML-to-PDF workflows, but I definitely have clients in the publishing world who do (as well as some who work with TeX typesetters).
  • kunstx
    kunstx Posts: 3
    edited February 3
    John Hudson said:
    Is your solution available? Or can you point to examples of its output?

    I’ve not personally used XML-to-PDF workflows, but I definitely have clients in the publishing world who do (as well as some who work with TeX typesetters).
    Hi John, it is available at:

    https://pubsuite.online

    The good news are that, you don't even have to use extensive xml if you don't have a reason for it. You can just use basic tags and add style classes. (not css classes, but the syntax is the same). When using extensive xml as well it is possible to add classes to dedicated tags to make them different style than the tag group.

    I hope that user documentation will be done soon, so you will have detail instructions as well.

    Currently we offer this version, and an automation pipeline for enterprise companies (or anyone who needs it). In the future we plan to extend Pub Suite with multiple environments, so one would be "you see what you type", (like in the case of Microsoft Word), but with the advanced precise rendering. It would be solving syntax burden on users that need simple documents and books. 

Categories