-
|
We use pandoc to create an HTML file from GFM, then weasyprint to convert it to a PDF. I've noticed an issue with remote style sheets on my local machine running pandoc 3.5 and in our build pipelines running pandoc 3.6. It did not happen with pandoc 2.9 in our build pipelines, which is the version available in Ubuntu's package repo. We reference a remote CSS file, ex. @font-face {
font-family: 'Inter';
font-style: normal;
font-weight: 400;
font-display: swap;
src: url('/web/fonts/inter/inter-v3-latin-regular.eot'); /* IE9 Compat Modes */
src: local(''),
url('/web/fonts/inter/inter-v3-latin-regular.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
url('/web/fonts/inter/inter-v3-latin-regular.woff2') format('woff2'), /* Super Modern Browsers */
url('/web/fonts/inter/inter-v3-latin-regular.woff') format('woff'), /* Modern Browsers */
url('/web/fonts/inter/inter-v3-latin-regular.ttf') format('truetype'), /* Safari, Android, iOS */
url('/web/fonts/inter/inter-v3-latin-regular.svg#Inter') format('svg'); /* Legacy iOS */
}This worked fine in pandoc 2.9, but no longer appears to work in 3.5+. I realize it may not be ideal to call a remote style sheet, but it's what we had set up and working at the time. Our PDFs are assembled from three components: a cover page, a disclaimer, and content. The cover page and content reference the remote style sheet, but the disclaimer doesn't. I pulled an old PDF generated prior to the update to 3.6 and examined the fonts: % pdffonts good-pdf.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
RLARXZ+Inter-Bold CID TrueType Identity-H yes yes yes 816 0
UHVPPQ+Inter-Bold-Oblique CID TrueType Identity-H yes yes yes 803 0
DOSKDN+DejaVu-Sans-Oblique CID TrueType Identity-H yes yes yes 768 0
KSMUOH+DejaVu-Sans-Bold CID TrueType Identity-H yes yes yes 739 0
OTNZNL+DejaVu-Sans CID TrueType Identity-H yes yes yes 589 0
BHHYGV+Inter-Bold CID TrueType Identity-H yes yes yes 1022 0
CLWDUD+Liberation-Mono-Italic CID TrueType Identity-H yes yes yes 799 0
DMHUUW+Liberation-Mono-Bold CID TrueType Identity-H yes yes yes 1011 0
IZNFDY+Inter-Oblique CID TrueType Identity-H yes yes yes 921 0
NCBZWM+Inter-Semi-Bold CID TrueType Identity-H yes yes yes 506 0
SCWULG+Liberation-Mono CID TrueType Identity-H yes yes yes 899 0
UJXWIA+DejaVu-Sans CID TrueType Identity-H yes yes yes 797 0
YNIYJA+Inter CID TrueType Identity-H yes yes yes 844 0Then I broke it down to see what fonts were applied to the three components: # cover
% pdffonts good-pdf_cover.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
AAAAAB+Inter-Bold CID TrueType Identity-H yes yes yes 10 0
AAAAAC+Inter-Bold CID TrueType Identity-H yes yes yes 12 0
# disclaimer
% pdffonts good-pdf_disclaimer.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
AAAAAB+DejaVuSans-Bold CID TrueType Identity-H yes yes yes 8 0
AAAAAC+DejaVuSans CID TrueType Identity-H yes yes yes 9 0
AAAAAD+DejaVuSans-Oblique CID TrueType Identity-H yes yes yes 12 0
# content
% pdffonts good-pdf_content.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
AAAAAB+Inter-SemiBold CID TrueType Identity-H yes yes yes 8 0
AAAAAC+Inter-Regular CID TrueType Identity-H yes yes yes 9 0
AAAAAD+DejaVuSans CID TrueType Identity-H yes yes yes 10 0
AAAAAE+Inter-Regular CID TrueType Identity-H yes yes yes 13 0
AAAAAF+LiberationMono CID TrueType Identity-H yes yes yes 118 0
AAAAAG+LiberationMono-Bold CID TrueType Identity-H yes yes yes 119 0
AAAAAH+LiberationMono-Italic CID TrueType Identity-H yes yes yes 178 0
AAAAAI+Inter-Bold CID TrueType Identity-H yes yes yes 296 0You can see Inter Bold used for the cover, DejaVu Sans for the disclaimer, and an assortment of Inter fonts and Liberation Mono for the content. This is fine. Now a PDF post pandoc 3.6: % pdffonts bad-pdf.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
RLARXZ+Inter-Bold CID TrueType Identity-H yes yes yes 43 0
UHVPPQ+Inter-Bold-Oblique CID TrueType Identity-H yes yes yes 102 0
DOSKDN+DejaVu-Sans-Oblique CID TrueType Identity-H yes yes yes 96 0
KSMUOH+DejaVu-Sans-Bold CID TrueType Identity-H yes yes yes 80 0
OTNZNL+DejaVu-Sans CID TrueType Identity-H yes yes yes 86 0
BHHYGV+Inter-Bold CID TrueType Identity-H yes yes yes 112 0
IZNFDY+Inter-Oblique CID TrueType Identity-H yes yes yes 77 0
KAXQJV+Inter CID TrueType Identity-H yes yes yes 92 0
ZBSBFJ+Liberation-Mono CID TrueType Identity-H yes yes yes 105 0Seems OK - but when broken down: # cover
% pdffonts bad-pdf_cover.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
AAAAAB+DejaVuMathTeXGyre-Regular CID TrueType Identity-H yes yes yes 10 0
AAAAAC+DejaVuMathTeXGyre-Regular CID TrueType Identity-H yes yes yes 12 0
# disclaimer
% pdffonts bad-pdf_disclaimer.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
AAAAAB+DejaVuSans-Bold CID TrueType Identity-H yes yes yes 8 0
AAAAAC+DejaVuSans CID TrueType Identity-H yes yes yes 9 0
AAAAAD+DejaVuSans-Oblique CID TrueType Identity-H yes yes yes 12 0
# content
% pdffonts bad-pdf_content.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
AAAAAB+DejaVuMathTeXGyre-Regular CID TrueType Identity-H yes yes yes 8 0
AAAAAC+DejaVuMathTeXGyre-Regular CID TrueType Identity-H yes yes yes 11 0
AAAAAD+DejaVuMathTeXGyre-Regular CID TrueType Identity-H yes yes yes 33 0
AAAAAE+LiberationMono CID TrueType Identity-H yes yes yes 54 0DejaVu Math TeX Gyre out of left field! And it only reveals itself after you break the PDF back down into its individual components. Removal of the remote style sheet stops this behavior. The PDF defaults to DejaVu Sans. # cover - still references remote style sheet
% pdffonts fixed-bad-pdf_cover.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
AAAAAB+DejaVuMathTeXGyre-Regular CID TrueType Identity-H yes yes yes 10 0
AAAAAC+DejaVuMathTeXGyre-Regular CID TrueType Identity-H yes yes yes 12 0
# disclaimer
% pdffonts fixed-bad-pdf_disclaimer.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
AAAAAB+DejaVuSans-Bold CID TrueType Identity-H yes yes yes 8 0
AAAAAC+DejaVuSans CID TrueType Identity-H yes yes yes 9 0
AAAAAD+DejaVuSans-Oblique CID TrueType Identity-H yes yes yes 12 0
# content - remote style sheet reference removed
% pdffonts fixed-bad-pdf_content.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
AAAAAB+DejaVuSans-Bold CID TrueType Identity-H yes yes yes 8 0
AAAAAC+DejaVuSans CID TrueType Identity-H yes yes yes 9 0
AAAAAD+DejaVuSans-Oblique CID TrueType Identity-H yes yes yes 12 0
AAAAAE+LiberationMono CID TrueType Identity-H yes yes yes 60 0This behavior seems really odd. Has anyone encountered this before? Can it be fixed or worked around? I've experimented with a few possible solutions like a local style sheet and font files, but was ultimately unsuccessful. I've considered installing the Inter font locally, which is still an option, but I'm more curious about the new behavior. Please let me know if I can provide any other information. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 5 replies
-
|
Is it a pandoc issue or a weasyprint issue? That would be the first thing to figure out. |
Beta Was this translation helpful? Give feedback.
-
|
I asked the same question, but weasyprint has not been updated or changed, only pandoc. The HTML from pandoc looks correct. I suppose I could take the raw HTML and see if I can reproduce the issue locally with just weasyprint. |
Beta Was this translation helpful? Give feedback.
-
|
Do a diff on the HTML produced by 2.9 and 3.6, and see if you can locate the relevant difference. |
Beta Was this translation helpful? Give feedback.
-
|
It seems to be tied to weasyprint. I was able to reproduce the problem w/out pandocs involved. The HTML itself shouldn't be an issue. The cover is a static HTML file that hasn't changed and that's only run thru weasyprint and it has the same problem as the content portion of the PDF. I'll double-check it all the same. Odd that this came up at the same time as the pandoc update. |
Beta Was this translation helpful? Give feedback.
-
|
No difference in behavior between the new and old HTML created by pandoc. For the record, here's the diff: diff old-test.html test.html
8d7
< <meta name="dcterms.date" content="2023-02-13" />
13,14c12,13
< span.underline{text-decoration: underline;}
< div.column{display: inline-block; vertical-align: top; width: 50%;}
---
> div.columns{display: flex; gap: min(4vw, 1.5em);}
> div.column{flex: auto; overflow-x: auto;}
16c15,26
< ul.task-list{list-style: none;}
---
> /* The extra [class] is a hack that increases specificity enough to
> override a similar rule in reveal.js */
> ul.task-list[class]{list-style: none;}
> ul.task-list li input[type="checkbox"] {
> font-size: inherit;
> width: 0.8em;
> margin: 0 0.8em 0.2em -1.6em;
> vertical-align: middle;
> }
> .display.math{display: block; text-align: center; margin: 0.5rem auto;}
> /* CSS for syntax highlighting */
> html { -webkit-text-size-adjust: 100%; }
19a30
> .sourceCode { overflow: visible; }
54c65
< code span.bu { } /* BuiltIn */
---
> code span.bu { color: #008000; } /* BuiltIn */
67c78
< code span.im { } /* Import */
---
> code span.im { color: #008000; font-weight: bold; } /* Import */I'm pretty confident this isn't a pandoc issue at this point ... I can reproduce the issue with HTML that pandoc didn't generate as well. Thanks for being a sounding board. |
Beta Was this translation helpful? Give feedback.
-
|
Looked at an older pipeline run and weasyprint was at 62.3. Current pipelines show 63.1. Appears to have been terrible timing and a coincidence that this issue appeared around the same time we moved to pandoc 3.6. |
Beta Was this translation helpful? Give feedback.
-
|
Found and fixed: Kozea/WeasyPrint#2335 |
Beta Was this translation helpful? Give feedback.
Is it a pandoc issue or a weasyprint issue? That would be the first thing to figure out.
If the HTML file produced by pandoc looks right, then I would say it's a weasyprint issue and should be reported there.