adobe-fonts / source-sans

Sans serif font family for user interface environments
https://adobe-fonts.github.io/source-sans
SIL Open Font License 1.1
3.45k stars 231 forks source link

Apple PDFKit unable to render MS Word (Windows) documents #234

Closed snowbanker closed 2 years ago

snowbanker commented 2 years ago

Probably a mixture of issues with the above mentioned software (MS Word 365 v2111, Adobe Acrobat Pro 2020, PDFKit in iOS/iPadOS 15), but I thought I should mention it:

See sample DOCX file attached. Wikipedia-StarWars(Film).docx

This is a Word document using two non-standard typefaces (SS3 Light v3.028 and, for comparison, Soleto). Numbers set to proportional spacing. SS3 set to Stylistic Set 1 (roman capital i with serifs).

Converted to PDF using Acrobat for Word (as opposed to Word's built-in PDF engine). See attached PDF. Wikipedia-StarWars(Film).pdf

PDF file looks fine in Adobe Acrobat Reader, Windows 10/11 Preview (Explorer/Edge), and similar. However, if viewed on iPhone/iPad, the SS3 text doesn't work at all. It is rendered in another typeface entirely, and any OpenType variations like the 'i' and the proportional numbering are blank. For comparison, none of these issues appear with other typefaces, including Soleto or the typefaces included as part of Office 365. See attached screenshot. Wikipedia-StarWars(Film)-iPad

(On a related note to another typeface - I don't have a sample prepared and I guess it belongs on that github page - but Noto Sans SC doesn't render either, but Noto Sans CJK SC does.)

There are no similar problems with using Microsoft Word 365 on Mac; nor with using PowerPoint 365 on Windows with SS3 (font renders correctly; Opentype features are not available in PowerPoint). If we try and use the Word built-in PDF engine, text seems to be converted into bitmaps instead of text+embedded font subset.

Hope that is clear!

pauldhunt commented 2 years ago

Here are some screen grabs from my iPhone X (iOS 14.7.1) showing I cannot reproduce this issue: imageimage

frankrolf commented 2 years ago

Screenshots from iPhone 12 Pro, iOS 15.0.1: IMG_1575 IMG_1574

The font we’re seeing is the Apple MM replacement font, which implies the font is considered “missing” in the PDF. Acrobat on iOS shows the document like this: IMG_1576

There is something going on with the font embedding. Other than the version number used, can you indicate if you’re using the OTF or TTF variants (and perhaps try the opposite)? I don’t think Variable Fonts are supported in MS Word, so no need to investigate in that direction.

pauldhunt commented 2 years ago

I just updated to iOS 15 this evening and am now seeing the display as shown by Frank. Perhaps there’s some issue with the new OS.

snowbanker commented 2 years ago

Answering Frank's question: using SS3 Light (i.e. not variable) OTF files in Word for Windows and PowerPoint for Windows (particularly to retain OpenType features as detailed above). Oddly, there is no problem in a PowerPoint converted to PDF using the exact same method in the same version of Office. So it kinda feels like there's a minor element that iOS 15 looks for that doesn't make it through in a Word conversion with SS3, but does make it through with other fonts (Soleto in the example, but it works with others too).

frankrolf commented 2 years ago

No need to worry about the OpenType features – they will be contained in the TTF files also.

The OTF and TTF files are equivalent, except for the underlying outline geometry and hinting information.

snowbanker commented 2 years ago

Frank's comment prompted me to try it again, having deleted the OTF files and replaced them with TTF files in Windows. No problem with iOS 15 if done with these files instead. Renders fine even when not in Adobe Acrobat for iOS. The proportional figures work (see THX 1138) and the SS1 works (see Episode IV) as well. Wikipedia-StarWars(Film)-SS3-TTF.pdf.

So I guess this is 'solved' by using TTF files? It seems TTF is more robust in general. (Hoping TTFs are compiled for the non-variable Source Han Sans subsets one day).

frankrolf commented 2 years ago

Glad to hear it’s fixed! The “robustness” of a particular format depends a lot on the implementing application, that’s why both variants are provided.