One thing I learned while working on document conversion is that extracting text is only half the job.

You can successfully read every character from an EPUB, generate a PDF, and still produce a document that looks completely broken.

I ran into this problem with Urdu EPUB files.

The conversion technically completed. The PDF opened. The pages were there. But instead of readable Urdu text, some readers displayed empty boxes.

The problem wasn't the extracted text. It was the font.

Why fonts matter in a PDF

A PDF isn't simply a text file with page breaks.

It stores content positioned on a page. Text has coordinates, font information, sizes, spacing, and other properties that determine how it appears.

When a PDF uses a font that isn't embedded, the reader may need to substitute another font.

That can cause problems even with ordinary Latin text. Different fonts have different character widths, glyph shapes, and spacing metrics.

With Urdu, the problem becomes more noticeable.

Urdu uses a connected script. Characters change shape depending on their position in a word, and the correct glyph shaping and positioning are essential for readable output.

A font substitution can turn a document that should contain readable Urdu into something that looks like a collection of missing characters.

The Urdu EPUB problem

My EPUB-to-PDF converter could extract the Urdu content, but the generated PDF didn't have the right font available.

I needed a font that actually supported the script.

I chose Noto Nastaliq Urdu and changed the conversion process to embed the font in the generated PDF.

That was the important part. Having the font somewhere in the project wasn't enough. The generated document needed to carry the font information so a PDF reader could render the text correctly without depending on the reader's installed fonts.

After making that change, Urdu text could render properly instead of appearing as empty boxes.

Why embedding matters beyond the main text

The same issue can affect features that seem unrelated to font rendering.

Consider page numbers.

If a tool adds page numbers using a font that isn't available or embedded correctly, the generated output can have unexpected spacing or missing characters.

Watermarks have similar requirements. A watermark might look fine in one environment but render differently when opened on another machine.

This is why I don't treat font handling as a cosmetic detail.

It is part of producing a valid document.

What I take away from this

A successful conversion should be judged by the output, not just by whether the conversion function returned without an error.

For document tools, I now pay more attention to:

Whether the generated PDF embeds the fonts it needs.

Whether the font supports the document's character set.

Whether text positioning survives the conversion.

Whether page numbers and watermarks use reliable font handling.

Whether the result looks correct in a separate PDF reader.

A file that opens but displays empty boxes isn't a successful conversion.

This is especially important for documents containing scripts that aren't well supported by default system fonts.

I want my conversion tools to produce documents that people can actually read, not just files that pass a basic validity check.

The EPUB-to-PDF converter and the rest of my browser-based file tools are available here: https://pocketpdf.site