Problem
PDFs created with Electron have kerning and type issues
Possible fix
We would like to switch to Charter as the choice of typeface for producing PDFs using Electron service.
Charter is part of texlive-fonts-recommended package
• Nirzar | |
Nov 22 2017, 10:27 PM |
F11093114: Screen Shot 2017-12-01 at 1.07.11 AM.png | |
Nov 30 2017, 7:38 PM |
F11091169: dog-ext.pdf | |
Nov 30 2017, 4:49 PM |
F11091168: dog-beta.pdf | |
Nov 30 2017, 4:49 PM |
F11091170: dog.pdf | |
Nov 30 2017, 4:49 PM |
F10953641: Dog.pdf | |
Nov 23 2017, 10:35 AM |
F10944818: image.png | |
Nov 22 2017, 10:27 PM |
F10944820: image.png | |
Nov 22 2017, 10:27 PM |
F10944822: image.png | |
Nov 22 2017, 10:27 PM |
PDFs created with Electron have kerning and type issues
We would like to switch to Charter as the choice of typeface for producing PDFs using Electron service.
Charter is part of texlive-fonts-recommended package
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Set Charter as the default font family | mediawiki/services/electron-render | master | +4 -0 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Invalid | None | T241376 [Tracking] Bugs related to desktop (Vector) print styles | |||
Declined | None | T166188 Architecture of new rendering backend for Extension:Collection | |||
Declined | None | T169828 Use Wikimedia Design Style Guide font choice of serif in print styles | |||
Declined | • mobrovac | T181200 Use "Charter" as preferred typeface on Electron |
Change 393036 had a related patch set uploaded (by Mobrovac; owner: Mobrovac):
[mediawiki/services/electron-render@master] Set Charter as the default font family
Change 393036 merged by Mobrovac:
[mediawiki/services/electron-render@master] Set Charter as the default font family
@Nirzar I have updated Electron to the latest version and added the configuration to have Charter as the default font family. I deployed all of the changes to BetaCluster, so please test there (PDFs can be obtained by issuing requests to https://en.wikipedia.beta.wmflabs.org/api/rest_v1/page/pdf/{title}). After that we can proceed to deploying the changes to production.
@mobrovac Thank you so much for such a prompt change!!
As @ovasileva mentions, the issue still exists but we would like to keep Charter as choice of typeface either ways.
As far as the kerning issue goes, which is very important to fix. I read bunch of bug reports around this. I'm not too technical so I might be completely wrong but after reading threads on github seems like there are other people having similar issues on linux systems.
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/45#issuecomment-108649125
The thread is about wkhtmltopdf but it seems underlying issue is with fontconfig on debian
The fix suggests using following fontconfig (defining font smoothing)
<?xml version='1.0'?> <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> <fontconfig> <match target="font"> <edit mode="assign" name="rgba"> <const>rgb</const> </edit> </match> <match target="font"> <edit mode="assign" name="hinting"> <bool>true</bool> </edit> </match> <match target="font"> <edit mode="assign" name="hintstyle"> <const>hintslight</const> </edit> </match> <match target="font"> <edit mode="assign" name="antialias"> <bool>true</bool> </edit> </match> <match target="font"> <edit mode="assign" name="lcdfilter"> <const>lcddefault</const> </edit> </match> </fontconfig>
There are other people saying setting quality to high or setting the DPI to 200 fixed the problem for them.
As I said, I'm not too technical so I might be completely wrong and this might be irrelevant but a lot of threads about kerning and linux pdf rendering threads point to this same thread on github
Indeed, the issue still exists, but from what I can tell, the situation has improved. If you are ok with that, we can deploy it early next week to production.
The font config file you posted is already in use by the system, but it doesn't seem to be helping. Unfortunately, we don't have the bandwidth to dive deeper into this problem. I would suggest @ovasileva to find resources in Audiences to pursue the problem further, as this is a product problem.
@mobrovac Thanks! the issue has reduced and the charter is actual choice of typeface we wanted. Let's deploy this change, I will resolve this card and follow up on T178665: [Spike, 8hrs] Grave kerning issues and spacing issues in PDFs generated by Chromium (and previous Electron) via "Download as PDF"
Just for reference: I calculated the DPI of PDFs generated by Electron and it's somewhere around 70. If we don't find any css or frontend fixes for kerning issues then we might want to up the DPI to 100-200 and see if that helps.
Mentioned in SAL (#wikimedia-operations) [2017-11-29T09:24:43Z] <mobrovac@tin> Started deploy [electron-render/deploy@94d27d7]: Update to electron v1.7.9 and start using the Charter font - T181200
Mentioned in SAL (#wikimedia-operations) [2017-11-29T09:28:46Z] <mobrovac@tin> Finished deploy [electron-render/deploy@94d27d7]: Update to electron v1.7.9 and start using the Charter font - T181200 (duration: 04m 03s)
Hey @mobrovac, I'm still not seeing this change on production :( i tried on obscure articles where we wouldn't have a cache but seeing the old fonts.. any idea on how much time it will take for the cache to flush?
Hm, I might be missing something, but all of these fonts look the same to me:
the dog-beta.pdf is the only one which uses Charter here. the other two uses liberation sans (old font)
easy way to recognise Charter would be the O, it's not elongated like the liberation, more roundish...
Reopening as this is clearly not completed as we thought. I took a look at this, and I cannot figure out what is going on and why is the output different in production. Both in production and BetaCluster the font is installed and used:
$ fc-match "Charter" DejaVuSans.ttf: "DejaVu Sans" "Book" $ fc-match "Bitstream Charter" c0648bt_.pfb: "Bitstream Charter" "Regular"
The fonts present in the PDFs are, however, quite different:
$ pdffonts dog-beta.pdf name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- Arial-BoldMT CID TrueType Identity-H yes no yes 22 0 ArialMT CID TrueType Identity-H yes no yes 27 0 Arial-BoldItalicMT CID TrueType Identity-H yes no yes 32 0 Georgia-Bold CID TrueType Identity-H yes no yes 37 0 Georgia CID TrueType Identity-H yes no yes 42 0 Georgia-Italic CID TrueType Identity-H yes no yes 47 0 WenQuanYiZenHei CID TrueType Identity-H yes no yes 56 0 Arial-ItalicMT CID TrueType Identity-H yes no yes 61 0 $ pdffonts dog-prod.pdf name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- LiberationSans-Bold CID TrueType Identity-H yes no yes 65 0 LiberationSans CID TrueType Identity-H yes no yes 70 0 LiberationSans-Italic CID TrueType Identity-H yes no yes 75 0 LiberationSans-BoldItalic CID TrueType Identity-H yes no yes 80 0 LiberationSerif-Bold CID TrueType Identity-H yes no yes 85 0 LiberationSerif CID TrueType Identity-H yes no yes 90 0 LiberationSerif-Italic CID TrueType Identity-H yes no yes 95 0 DejaVuSerif-Italic CID TrueType Identity-H yes no yes 101 0 WenQuanYiZenHei CID TrueType Identity-H yes no yes 118 0
Hmmm, actually, now I'm wondering why I'm not even seeing Charter in the BetaCluster PDF font list.
I tried to change the font in both Beta and production to various values (Bitstream Charter, DejaVu, DejaVu Sans, etc.) and noticed that the actual display font never changes; the list of fonts is equal to the list posted above. So either:
Is it possible that it's using the font's defined in the article css? I don't actually know how Electron decides which font to use but if it's loading stylesheets, I'd hope it would honour those and only use the Charter font when no font has been defined.
IF that is the case, we'd need to add Charter in the priority font-family stack for Vector. Maybe experimenting with MediaWiki:Vector.css first?
@mobrovac it worked when you had put it in beta cluster :( > https://phabricator.wikimedia.org/T181200#3783404
Declining since Proton is replacing Electron-PDFs as the default PDF rendering engine very soon.