Printing to PDF results in no selectable text for some fonts
Reported by
dan...@nuix.com,
Apr 13 2018
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: 1. Install the provided font 2. Open the provided HTML file 3. File>Print... 4. Click "Open PDF in Preview" 5. Select the text, "Hi there, apparently I'm a bad font." 6. Try to copy the text to the clipboard and paste into a text editor What is the expected behavior? The text should be stored in the PDF, so copying the selection should put the text on the clipboard. What went wrong? No text ends up in the PDF other than the headers and footers. (Attached a sample result) Also, you can see visually from how it's being selected - it's like it's being rendered as graphics without marking the original text. Did this work before? N/A Chrome version: 65.0.3325.181 Channel: stable OS Version: OS X 10.13.4 Flash Version: If you do the same series of steps using Safari instead, you can select the text in the PDF and it copies out correctly.
,
Apr 13 2018
The text is not selectable in Chrome PDF Viewer, Preview or Evince, so the issue is with the PDF generation, rather than display. Likely still applicable in other platforms, as it can be reproduced with viewers that are not OSX's Preview.
,
Apr 16 2018
,
Apr 16 2018
The attached PDF was not produced bu Skia: /Producer (Mac OS X 10.13.4 Quartz PDFContext). Let's see what Skia produces... It embeds that font as a type-3 font. And it's selectable. https://github.com/HalCanary/howto-save-as-pdf
,
May 10 2018
What the bug reporter is probably doing is: (a) Printing with the system dialog, or choosing "Open PDF in Preview" from Chrome Print Preview. This produces unselectable fonts. What Hal described is: (b) Using Chrome Print Preview with the "Save As PDF" destination. This produces selectable fonts. With Safari, (c) printing with the system dialog works correctly and produces selectable fonts. One interesting thing is, one can take the output of (c), open it in Preview.app, and (d) print it to PDF again. This produces selectable fonts. If instead, one takes the output of (b), open it in Preview.app, and (e) print it to PDF again. This produces unselectable fonts. Just like (a). This may be a bug in Quartz. Safari somehow knows how to avoid it, whereas Chromium does not. Hal, WDYT?
,
May 10 2018
I don't understand what happens to the PDF when it leaves SkPDF.
,
May 12 2018
Sure, but we can treat Quartz as a black box, and see how it reacts to the Safari output vs SkPDF output. |
||||
►
Sign in to add a comment |
||||
Comment 1 by krajshree@chromium.org
, Apr 13 2018Labels: Triaged-ET M-67 Target-67 FoundIn-67 Needs-Triage-M65
Status: Untriaged (was: Unconfirmed)