Open natevw opened 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….
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/ 😃
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:
I think this bit from the Prince XML logs is relevant:
Seemingly the loader doesn't have a chance to get rid of its test string before Prince stops firing timeout handlers for some reason?