safari 10.1 - bad fonts and italics #8231

paolocaminiti · 2017-04-03T17:16:35Z

Link to PDF file (or attach file here):
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3847663/pdf/fnins-07-00231.pdf

Configuration:

Web browser and its version:
Safari 10.1 (12603.1.30.0.34)
Operating system and its version:
OSX 10.12.4 (16E195)
PDF.js version:
latest demo from github
Is an extension:
no

Steps to reproduce the problem:

open pdf
check font family and style of start of document
the bug is not present on previous versions of Safari

What is the expected behavior? (add screenshot)
Font should load and it's italic style display.

What went wrong? (add screenshot)
Font looks like a fall-back font, anyway no italic variant rendered.

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

paolocaminiti · 2017-04-05T15:22:18Z

This issue appeared on and only applies to Safari 10.1, which if I don't go wrong was released end of March 2017.

rianmcguire · 2017-04-06T07:02:45Z

I've just spent a couple of hours trying to understand this - we've been experiencing the same issue with a different PDF.

Safari 10 introduced support for the font loading API, so there have been some changes to the browser in this area.

FontLoader#addNativeFontFace gets called, the font is added, the loaded promise from the FontFace resolves successfully, but the font just doesn't render when drawn on the canvas. This happens reliably. Weirdly it doesn't seem to affect all fonts in the document.

I've also noticed that, sometimes, when the document re-renders it will magically start working. This happens so infrequently that it makes me doubt my sanity. It seems to be more likely to happen if you leave the window for a minute, and then trigger a render by zooming.

Forcing FontLoader.isFontLoadingAPISupported to false doesn't help either - the prepareFontLoadEvent hack also thinks the font is loaded.

evadne · 2017-04-11T01:52:37Z

Looks like a known issue.
https://github.com/bramstein/fontfaceobserver/pull/86/files
https://bugs.webkit.org/show_bug.cgi?id=165037
https://bugs.webkit.org/show_bug.cgi?id=164902

Unfortunately not easily fixed by swapping nativeFontFace.loaded with nativeFontFace.load() in FontLoader.prototype.bind

Thought: if you put a known symbol in the generated font, you could repeatedly draw that to a canvas and measure the pixels to see if the font has been loaded 😬

Tilmn · 2017-05-31T08:32:28Z

I experience the same problem in Chrome, when PDF.js is used embedded in Seafile.com

The dropped fonts happen very randomly. If the document was loaded before, it does not happen at all. It seems to happen more with more complex PDFs.

Hope that does help a bit. I hope we can sort this out, it‘s a real problem for us.

yurydelendik · 2017-05-31T12:51:44Z

Hope that does help a bit. I hope we can sort this out, it‘s a real problem for us.

@Tilmn I don't think it's related to the Safari problem discussed here and it can be moved to the separate issue (but you need to provide all requested details). Also we are not familiar with Seafile.com and screenshot does not show interface of PDF.js. Please contact vendors of web site for support -- you need to provide enough details for us to reproduce the issue.

wanmigs · 2017-06-05T00:42:37Z

i solved the problem by converting the pdf to lower version. i've tested the pdf with version 1.7 and the issues occur but when i converted the pdf to version 1.4 with ghostscript the pdf renders well.

MSchip · 2017-07-06T17:42:39Z

If anybody has any other temporary solutions please share. This has become a rather large issue for us.

franky-continu · 2017-07-11T00:02:44Z

@wanmigs sorry to ping you, would you mind dropping a few lines on how did you do the version change with ghostscript?

I wonder if this would do the trick as well?

https://www.techwalla.com/articles/how-to-convert-pdf-files-to-an-older-format

wanmigs · 2017-07-11T03:25:13Z

@franky-continu make sure to have ghostscipt installed on your server.

$new_pdf = 'path/new.pdf'; // path where to output the new pdf
$src_pdf = 'path/src/pdf';
shell_exec( "gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dQUIET -dBATCH -sOutputFile={$new_pdf} {$src_pdf}");

Hope that does help a bit.

rijk · 2017-08-31T10:41:06Z

It appears they have fixed this issue at Box. Any chance this fix can be pulled into this repo as well?

Snuffleupagus · 2017-08-31T10:53:05Z

It appears they have fixed this issue at Box. Any chance this fix can be pulled into this repo as well?

I'm not sure if box/box-content-preview#332 is entirely relevant here, since that's a downstream consumer of the PDF.js library. (And what they did is simply to apply a work-around, not a proper fix, one that could very well end up breaking more things than it solves.)

There's currently no solution to this on the PDF.js side. However, the fact that this appears to be limited to a particular version of just one browser strongly suggests that it's a font handling bug in Safari (rather than in PDF.js).

rijk · 2017-08-31T11:22:16Z

All right, sorry I'm not familiar with the innards of either library. Was just hopeful. If there is no other fix than waiting for a Safari update, is there at least a workaround other than converting the files? I don't want to be dramatic but we are actually losing customers over this (as our customer base is agencies, who are predominantly on Safari).

ajnyga · 2017-08-31T11:29:33Z

Open Journal Systems uses PDF.js library so I have been following this thread. Regarding the statement that this is a Safari bug, I actually know that Apple disagrees.

One journal editor has been in contact with Apple regarding the issue and they think that the issue is with PDF.js. So waiting for a fix in the Safari end could last forever.

danlester · 2017-08-31T11:55:14Z

I'm not 100% sure if we're talking about the same "Safari bugs" but I've seen a great improvement in Safari's rendering under the Safari Technology Preview, so hoping those fixes get rolled out to general Safari soon:

https://developer.apple.com/safari/technology-preview/

rijk · 2017-08-31T13:02:22Z

I think it definitely should be fixable. Just now, I uploaded this file to Dropbox, and previewed it. The first time, everything went perfect, so I assumed they were using a different engine. Then I refreshed, and saw the exact issues I reported today. Now, every time I open the file, there is a flash of it looking perfect while it loads (this might be an image preview but I don't think so, as I was definitely able to interact with it the first time — even select the text), and then when it finishes loading all the text suddenly shifts. You should be able to reproduce it in Safari with this link.

Edit: here is a screen recording demonstrating the issue: https://www.youtube.com/watch?v=WqIkpjHMSVo

So this establishes Safari is capable of displaying it properly. There must be something that's triggered in the library, that makes Safari go bad. If we find out what it is, I bet we can fix it!

PS: @danlester I can confirm the Safari Technology Preview does not have this problem! 👍 Unfortunately this does not help us now..

yurydelendik · 2017-08-31T13:25:04Z

There must be something that's triggered in the library, that makes Safari go bad. If we find out what it is, I bet we can fix it!

I can help a bit: modern Safari (as any other modern browsers) use Font Loading API (see https://drafts.csswg.org/css-font-loading/). PDF.js waits on Promise coming from browser to know when fonts are loaded (see code around fontLoadPromises variable).

@rijk can you override my analysis and confirm that PDF.js at fault here and PDF.js is doing something different for Safari or not using the API properly?

rijk · 2017-08-31T13:32:27Z

@yurydelendik, not sure what you mean with "can you override my analysis", but maybe my screen recording helps?

I cannot tell you if the bug is in Safari or PDF.js. But the combination seems to break it; triggering the font loading just completely breaks the rendered page. And that's exactly what the Box fix seems to consist of as well: disabling the font loading API for Safari.

yurydelendik · 2017-08-31T13:41:31Z

And that's exactly what the Box fix seems to consist of as well: disabling the font loading API for Safari.

We can introduce a workaround to disable font loading for some browsers. Using disableFontFace looks too extentsive. I would just suggest to check if it's a Safari at https://github.com/mozilla/pdf.js/blob/master/src/display/font_loader.js#L301 to just disable native font loading or add a flag similar to disableFontFace or disableRange (we blacklist Safari there as well, see https://github.com/mozilla/pdf.js/blob/master/src/shared/compatibility.js#L626).

P.S. we can see https://bugs.webkit.org/show_bug.cgi?id=172210 also present in Chrome

rijk · 2017-08-31T13:48:26Z

Actually, PDFJS.disableFontFace = true seems to work! I don't know what the downsides are (performance I guess?), but at least this gives us a short-term workaround.

yurydelendik · 2017-08-31T13:52:58Z

Actually, PDFJS.disableFontFace = true seems to work! I don't know what the downsides are (performance I guess?), but at least we have a short-term workaround with this.

PDFJS.disableFontFace = true enables low quality internal font rendering engine -- no subpixel-AA and increased memory-CPU usage. It's a last resort option when font-faces are disabled by browser. We have intermediate fallback to load font without Font Loading API for legacy browser -- it shall be used here.

rijk · 2017-09-21T09:02:29Z

Note that this issue appears to be resolved in Safari 11.

timvandermeij · 2018-06-23T13:32:16Z

Closing since this issue is fixed upstream.

timvandermeij added the font-conversion label Apr 3, 2017

timvandermeij added the safari-specific label Apr 5, 2017

evadne mentioned this issue Apr 11, 2017

Ligatures rendering as emojis in iOS Safari #8267

Closed

Snuffleupagus added the upstream label Apr 11, 2017

Snuffleupagus mentioned this issue Apr 25, 2017

Random spaces and font issue in Safari #8329

Closed

danlester mentioned this issue May 4, 2017

Safari font rendering errors #8376

Closed

ajnyga mentioned this issue May 31, 2017

[OJS] pdfJsViewer rendering problems with Safari 10.1. pkp/pkp-lib#2557

Closed

Snuffleupagus mentioned this issue Jun 1, 2017

Image and font issues in Safari (only some versions) #8471

Closed

tonyjin mentioned this issue Jul 25, 2017

PDF Fonts do not render properly in Safari #8700

Closed

Snuffleupagus marked this as a duplicate of #8700 Jul 26, 2017

Snuffleupagus mentioned this issue Aug 31, 2017

Glyph spacing is incorrect in Safari #8852

Closed

timvandermeij closed this as completed Jun 23, 2018

timvandermeij removed upstream font-conversion safari-specific labels Jun 23, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

safari 10.1 - bad fonts and italics #8231

safari 10.1 - bad fonts and italics #8231

paolocaminiti commented Apr 3, 2017

paolocaminiti commented Apr 5, 2017 •

edited

Loading

rianmcguire commented Apr 6, 2017

evadne commented Apr 11, 2017 •

edited

Loading

Tilmn commented May 31, 2017

yurydelendik commented May 31, 2017

wanmigs commented Jun 5, 2017 •

edited

Loading

MSchip commented Jul 6, 2017

franky-continu commented Jul 11, 2017

wanmigs commented Jul 11, 2017

rijk commented Aug 31, 2017 •

edited

Loading

Snuffleupagus commented Aug 31, 2017 •

edited

Loading

rijk commented Aug 31, 2017

ajnyga commented Aug 31, 2017

danlester commented Aug 31, 2017

rijk commented Aug 31, 2017 •

edited

Loading

yurydelendik commented Aug 31, 2017

rijk commented Aug 31, 2017 •

edited

Loading

yurydelendik commented Aug 31, 2017 •

edited

Loading

rijk commented Aug 31, 2017 •

edited

Loading

yurydelendik commented Aug 31, 2017 •

edited

Loading

rijk commented Sep 21, 2017

timvandermeij commented Jun 23, 2018

safari 10.1 - bad fonts and italics #8231

safari 10.1 - bad fonts and italics #8231

Comments

paolocaminiti commented Apr 3, 2017

paolocaminiti commented Apr 5, 2017 • edited Loading

rianmcguire commented Apr 6, 2017

evadne commented Apr 11, 2017 • edited Loading

Tilmn commented May 31, 2017

yurydelendik commented May 31, 2017

wanmigs commented Jun 5, 2017 • edited Loading

MSchip commented Jul 6, 2017

franky-continu commented Jul 11, 2017

wanmigs commented Jul 11, 2017

rijk commented Aug 31, 2017 • edited Loading

Snuffleupagus commented Aug 31, 2017 • edited Loading

rijk commented Aug 31, 2017

ajnyga commented Aug 31, 2017

danlester commented Aug 31, 2017

rijk commented Aug 31, 2017 • edited Loading

yurydelendik commented Aug 31, 2017

rijk commented Aug 31, 2017 • edited Loading

yurydelendik commented Aug 31, 2017 • edited Loading

rijk commented Aug 31, 2017 • edited Loading

yurydelendik commented Aug 31, 2017 • edited Loading

rijk commented Sep 21, 2017

timvandermeij commented Jun 23, 2018

paolocaminiti commented Apr 5, 2017 •

edited

Loading

evadne commented Apr 11, 2017 •

edited

Loading

wanmigs commented Jun 5, 2017 •

edited

Loading

rijk commented Aug 31, 2017 •

edited

Loading

Snuffleupagus commented Aug 31, 2017 •

edited

Loading

rijk commented Aug 31, 2017 •

edited

Loading

rijk commented Aug 31, 2017 •

edited

Loading

yurydelendik commented Aug 31, 2017 •

edited

Loading

rijk commented Aug 31, 2017 •

edited

Loading

yurydelendik commented Aug 31, 2017 •

edited

Loading