TTF hinting ignored

[500cm]

WeasyPrint seems to be ignoring hinted TTF fonts and resulting in blurry and unclear text. Even when fonts are properly hinted, the output is still not as sharp as expected. Additionally, I couldn't find any option to create proper sharp texts in the documentation or options list. It would be great if WeasyPrint could improve text rendering by properly handling hinted fonts or adding an option to create sharp text output.

Tested with WeasyPrint latest version.

[liZe]

Hi!

Hinting is done by the PDF renderer, not by WeasyPrint. WeasyPrint includes letters and fonts in the PDF, and the PDF renderer displays the text on the screen, possibly adjusting the position of the letters to the screen pixels, according to the position of the document on the screen, the zoom level and the screen resolution (and many other things such as the hinting preferences of the user). Hinting depends on these parameters that are not fixed when the PDF is generated, I’m not sure there’s something WeasyPrint can do here.

If you have two equivalent documents, one blurry generated by WeasyPrint and another one generated by another tool, don’t hesitate to share them! Maybe there’s a feature we don’t know.

[500cm]

Hinting is crucial for Windows users to enhance text readability, particularly at smaller font sizes. However, it is not relevant for users of other systems, such as Apple devices. Both TTF and OTF font files contain hinting instructions, and applications like Adobe Acrobat, web browsers, and other PDF renderers on Windows do not optimize fonts on their own, so you can't give up hinting built into fonts.

Most PDF producers that I have used before (PDF libs, Adobe software, etc) generate PDFs with hinting embedded in fonts and do not allow to do it otherwise, because it is a standard and important technology.

The issue arises when creating PDFs using WeasyPrint, as font optimization (enabled by default) disables hinting for fonts. If font optimization is disabled (e.g., optimize_size=("images")), the PDF is generated with hinting, but the file size increases significantly due to the lack of optimization and full font inclusion.

Disabling hinting altogether by default is not a viable solution. It's essential to either set hinting=true in the library or provide an option to use the variable. Below are the WeasyPrint generated PDFs comparing cases with and without font optimization.

To reproduce this problem, create a PDF file containing text with optimization turned on and off. You will see a clear difference on Windows systems with a 92 PPI monitor (not 4K).

[500cm]

Two files, with and without hinting

hinting on.pdf
hinting off.pdf

[liZe]

Thanks for sharing your documents and the screenshot.

Disabling hinting altogether by default is not a viable solution.

WeasyPrint is downloaded 10 million times a year, so it may be viable, at least for some people, even without hinting 😄. Funny that nobody ever complained before.

We’ve never met this problem, probably because Poppler (the library used by most PDF readers on Linux) ignores hinting information on purpose. Hopefully, pdf.js does follow hinting tables, so we’re able to test the difference, even on Linux.

(There’s actually another bug in WeasyPrint that’s been fixed in 8a800a0, while solving #1855. This bug sets wrong widths for characters when fonts are not optimized, so you won’t get the exact same rendering with the fixed master branch than what you got with v58.1 + non-optimized fonts.)

Here’s what I get with the fix:

• hinting disabled: test.pdf
• hinting enabled: test-hint-fix.pdf
• no font optimization: test-none.pdf

I find the result better with hinting, at least with pdf.js, but a bit different than with full font. Feedback is welcome!

If you want to test various options, you can tweak options here:

WeasyPrint/weasyprint/pdf/stream.py

Lines 107 to 111 in d9c8af8

	options = subset.Options(
	retain_gids=True, passthrough_tables=True,
	ignore_missing_glyphs=True, hinting=hinting,
	desubroutinize=True)
	options.drop_tables += ['GSUB', 'GPOS', 'SVG']

[500cm]

Funny that nobody ever complained before

This is the most surprising part

Thank you, I'll check it

[liZe]

As the feature was not asked before, we’ve finally disabled the option by default. It’s still available for users who want to keep the hinting information.

With all these new size optimization options, I’m not convinced by the -O option anymore, mainly because it’s complicated to disable one default option. Maybe we should change this.

[500cm]

Strategically this is not correct. Hinting should not be disabled by the library. It should remain under the control of the font itself. Those who don't need hinting can convert the font to a format without hinting or do automatic hinting, which is common practice.

[500cm]

By the way, disabling font optimization causes a number of bugs with fonts. They are converted to UTF characters, which are not readable in PDF file (it turns out: 􀍏􀍘.􀍡􀍛) and after some characters are added unnecessary space. Apparently, a separate task should be created for this.

[liZe]

Strategically this is not correct. Hinting should not be disabled by the library. It should remain under the control of the font itself.

I have to disagree on that point.

I understand that hinting is important for you, and I agree that it may be important for others. But the fact that this issue was opened just 4 days ago is a proof that most users don’t care and will prefer a smaller PDF than correct hinting. That’s sad (I spend so much time adding hinting information in the fonts I create 😢), but that’s a fact. By the way, many PDF readers do a decent job at automatically hinting fonts, and some even voluntarily discard hinting information in embedded fonts.

The feature is now available for the people who care.

Those who don't need hinting can convert the font to a format without hinting or do automatic hinting, which is common practice.

I think that users don’t want to learn how to convert fonts. Many don’t even want to optimize and resize their images themselves! Having these features in WeasyPrint is important in my opinion, they help users to let the tool take care of the topics they don’t want to spend time on. Pre-processing (HTML, CSS, images, fonts…) is always possible, but we have to take care of common options when possible.

They are converted to UTF characters, which are not readable in PDF file (it turns out: 􀍏􀍘.􀍡􀍛)

I can’t easily reproduce this problem. Could you please send an HTML sample and the corresponding PDF in another issue?

after some characters are added unnecessary space

Maybe that’s fixed by 8a800a0. If it’s not, you can open another issue 😄.

[liZe]

(The issue is now closed because the PR is merged, but feel free to add comments!)