Change 393036 had a related patch set uploaded (by Mobrovac; owner: Mobrovac):
[mediawiki/services/electron-render@master] Set Charter as the default font family

https://gerrit.wikimedia.org/r/393036

Change 393036 merged by Mobrovac:
[mediawiki/services/electron-render@master] Set Charter as the default font family

https://gerrit.wikimedia.org/r/393036

@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.

@Nirzar, @mobrovac - tested quickly and still seeing some kerning issues, especially with references:

@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 - Let's go ahead with the deployment if it looks okay to @Nirzar. We can look further into the other issues from our side.

@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:

• gotten directly on the electron production host:
  dog.pdf1 MBDownload

• gotten by curl-ing from my computer:
  dog-ext.pdf1 MBDownload

• gotten y curl-ing BetaCluster form my computer:
  dog-beta.pdf405 KBDownload

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...

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:

• Electron/Chromium completely ignores the setting; or
• there is an issue where system fonts cannot be (properly) loaded

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