Ligatures rendering as emojis in iOS Safari

[JustinHoldstock]

Link to PDF file (or attach file here):
WalmartAcademy_Ligatures_Issue.pdf

Configuration:

• Web browser and its version: Safari 602.1
• Operating system and its version: iOS 10.3.1
• PDF.js version: 1.7.406
• Is an extension: No

Steps to reproduce the problem:

1. Open PDF in PDF.js 1.7.406 on IOS Safari

What is the expected behavior?

What went wrong? Note the trolley car emoji

[evadne]

You also seem to have been hit by the Safari 10 issue #8231 too, note font rendition for “Coaching for Success” looks a bit off.

That said, I suspect this can be worked around with PDFJS.disableFontFace = true which I tried by inducing a horrible hack…

diff --git a/web/app.js b/web/app.js
index e3380722..662509c6 100644
--- a/web/app.js
+++ b/web/app.js
@@ -1459,6 +1459,7 @@ function webViewerInitialized() {
     if ('disablefontface' in hashParams) {
       PDFJS.disableFontFace = (hashParams['disablefontface'] === 'true');
     }
+    PDFJS.disableFontFace = true;
     if ('disablehistory' in hashParams) {
       PDFJS.disableHistory = (hashParams['disablehistory'] === 'true');
     }
(END)

And then rendition works as intended albeit much slower.

[christoph-schlumpf]

Same issue here with iOS 10.3 and a cordova app with pdfjs (using UIWebView)

[John-C2]

We had the same issue for folks who were running the latest version of iOS. (10.3.1)
Try setting:
"disableFontFace": true in the list of defaultPreferences for web/viewer.js
That fixed it for us.

[christoph-schlumpf]

Hi, Thanks for the reply! This is exactly what I did and it fixed the issue. Best regards, Christoph

…

--- Christoph Schlumpf Hegifeldstrasse 68 8404 Winterthur

Am 13.04.2017 um 14:35 schrieb John F. ***@***.***>: We had the same issue for folks who were running the latest version of iOS. (10.3.1) Try setting: "disableFontFace": true in the list of defaultPreferences for web/viewer.js That fixed it for us. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[tgrosh]

When we apply this fix, flipping the disableFontFace to true, we immediately experience significant performance issues when downloading PDFs. Flipping the flag back to false restores the performance.

[yurydelendik]

flipping the disableFontFace to true, we immediately experience significant performance issues

yes, that's expected

[taenzerme]

Any other fix other than the disableFontFace solution? The performance is really bad. What is the primary thing causing this? Ligatures? Fonts?

[yurydelendik]

The performance is really bad. What is the primary thing causing this?

The letters/glyphs are painted using lines/polygons.

[taenzerme]

@yurydelendik Thanks for the reply, actually I meant what the problem with the original PDF is. Is there a way to convert it to solve the problem?

[brendandahl]

I didn't really get anywhere on this, but some notes on looking at this a bit:

I can reproduce on desktop safari (Version 10.1 (12603.1.30.0.34)), the 'fi' glyph isn't an emoji but it doesn't show up. The problem seems to be fixed with the technology preview (Release 29 (Safari 10.2, WebKit 12604.1.19.0.1)).

Initially, I thought it was an issue with font g_d0_f2, since I can see font g_d0_f1 successfully draws. I extracted font g_d0_f2 and loaded it in a vanilla html page (no pdf.js) and put charcode 57374 into a div and painted it on a canvas and the font seems to load correctly and I see the correct 'fi' glyph. Further, if I use the FontFace API and paint to canvas it also seems to work correctly.

Since the font worked in my vanilla tests, I thought it may just be the first font loaded works, but after disabling the load of g_d0_f1 and only loading g_d0_f2 it still was broken. I also tried delaying various promise resolutions and even immediately painting on font load (thinking the font was being GC'ed), but still no luck.

Either safari font loading is buggy or there seems to be something PDF.js is doing that causes it to fail, but I'm out of time to look at this anymore.

The issue seems to be rather strange and I'm not sure it's related to the bug linked to above with promise resolution, but at least it seems to be fixed in future versions.

[ghost]

Same problem here.

Using disable font face seem to be problematic (performance and incomplete rendering). By exemple, for my test document the two first page seems to be rendered blank but other pages seem to be ok (when I navigate with page navigator).

I will test some more but my first impression is that we will have to wait for Apple to fix this one.

[tonyjin]

Update here - I just removed the PDFJS.disableFontFace = true fix we originally had since that seems to have recently started causing issues. Removing that seems to work and we aren't seeing any garbled emoji fonts in iOS 10.3.2. We originally started seeing the problem in 10.3.1, so it's likely that Apple fixed the issue in 10.3.2.

[tonyjin]

@timvandermeij feel free to close this out - 10.3.2 no longer has this issue, thanks!

[ghost]

Hello. I dont have a 10.3.2 at work, I will test with my personnal tablet tonight and report.

[ghost]

Still see the issue on IOS 10.3.2 and latest 10.3.3. Our app is running lastest release 1.7.
I can check with latest later...

[t2thec]

I am experiencing the the same issues here too sadly.

iOS Safari 11 beta is all good. iOS Safari 10.3.3 causes issues.

Did anyone find a solution to this?

Cheers

[BeatriceThalo]

We had this iOS 10 Safari issue with Minion Pro font, but no issue (a single file tested) with Gotham font plus outlining the text before creating the PDF. The problem is we are using older iPad models that are not eligible to update to iOS 11.

New idea: We have a library viewer of about 145 pdfs (using Minion Pro) 500 KB - 1.8 MB each. As I am going through each one to make a list of ones with emoji to be re-fonted, I noticed something weird. Opening a fresh browserstack device (our physical one was unavailable), the first 6-8 pdfs I view show emoji, then the next 11-17 pdfs I open do not have emoji, and then the mobile safari website address bar says "error, reconnected", after which I need to open another fresh browserstack device because the pdf rendering spinner hangs indefinitely. Picking up on the library list where I left off, in the new session, that pattern repeated, but if I revisited a previously emoji-free pdf in that session's first 6-8, it now had emoji. Maybe there is some memory leak or very slowly fetched iOS parsing resource? Or reading the same pdf from the browser cache instead of a new http request for it.