typekit / webfontloader

Web Font Loader gives you added control when using linked fonts via @font-face.
Apache License 2.0
9.24k stars 648 forks source link

Leaves behind garbage text visible in Prince XML's PDF output #379

Open natevw opened 7 years ago

natevw commented 7 years ago

When TypeKit is used on a page to be rendered via Prince XML, some extra junk text is visible at the end (bottom of last page) of the rendered PDF document:

BESbswyBESbyBESbswyBESbyBESbswyBESbyBESbswyBESbyBESbswyBESbyBESbswyBES

I think this bit from the Prince XML logs is relevant:

Thu Sep 28 13:45:20 2017: Running scripts...
Thu Sep 28 13:45:20 2017: loading script: http://use.typekit.net/pzm7nei.js
Thu Sep 28 13:45:20 2017: warning: pending timeouts

Seemingly the loader doesn't have a chance to get rid of its test string before Prince stops firing timeout handlers for some reason?

natevw commented 7 years ago

Yes, it looks like the FontWatchRunner uses timeouts to re-trigger its check. I am still not sure what is happening on the Prince side: it apparently does [usually] call timeouts but with 0 delay.

Apparently the absolute position "hiding" trick of FontRuler does not prevent Prince from rendering it into the PDF.

I've worked around in our case by adding a rule in a Prince-specific stylesheet:

span[aria-hidden] {
  display: none;
}

Ideally from our end, the ruler spans which TypeKit uses would have a more unique class we could select.

Perhaps from the TypeKit end, visibility: hidden would be better? But if hidden would be sufficient, I'm not sure why it's not used in the first place. Regardless, blocking the display of these spans like this is probably messing with the font testing stuff but in the end doesn't seem to interfere with the fonts getting used to render the PDF….

natevw commented 7 years ago

Actually an even cleaner solution appears to be switching to the CSS include for TypeKit: https://blog.typekit.com/2017/08/30/css-font-loading/ 😃