font_info not updated in Document's write_pdf font descriptor loop

[aschmitz]

When embedding fonts, write_pdf uses a variable for font_type to determine whether to describe the font as FontFile3 (with OpenType subtype) or FontFile2, and which CIDFontType to give. It's used on several lines, but a representative sample is:

WeasyPrint/weasyprint/document.py

Line 1259 in fd2901c

(f'FontFile{"3" if font_type == "otf" else "2"}'):

However, this variable is only set in the loop before these fonts are output:

WeasyPrint/weasyprint/document.py

Line 1230 in fd2901c

font_type = 'otf' if content[:4] == b'OTTO' else 'ttf'

As a result, if both TTF and OTF fonts are included in a document, at least one of them will be output with the wrong type. Some PDF viewers (at a quick test: PDF.js, PDFium, and Poppler) seem to not mind this discrepancy, but macOS' Preview.app appears to substitute a slightly-deterministic built-in font.

I had first noticed this on a PDF file with a rendering issue in Preview.app. A minimized sample HTML document is as follows, and requires the Inter font and Ubuntu Mono font (the former installed from the GitHub release, the latter from the fonts-ubuntu Ubuntu package). There is a tab character before the final "a":

<style>
  html {
    font-family: Inter;
  }
  code {
    font-family: Ubuntu Mono;
    white-space: pre-wrap;
  }
</style>
<code>Example</code>
text
<code>	a</code>

That produces this PDF.

In PDFium, this renders as expected:

However, in Preview.app, it appears to use a built-in PDF font (Helvetica?):

A couple curiosities: using a different body font (such as Noto Sans) can make the problem disappear (which tracks with the same file type in both fonts fixing the problem), and removing the white-space: pre-wrap line (or the tab before the a) appears to make Preview.app render the code blocks in Courier Bold(?).

My current build process makes it a pain to actually modify WeasyPrint to test changes, but I'm hopeful that fixing this will resolve the issue, since it seems to be the root of the only nontrivial differences I can find between the PDF files when swapping fonts.

[liZe]

Thanks a lot for this perfect bug report ❤️.

[aschmitz]

Awesome, thanks! I can confirm that 5005459 fixes the issue with my larger test documents as well.