Issue metadata
Sign in to add a comment
|
Low quality PDF text rendering on Headless Chrome
Reported by
ja...@inkdigital.com.au,
Jun 14 2018
|
|||||||||||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134 Steps to reproduce the problem: Open Chrome with --headless, --print-to-pdf on any webpage. An example demonstrating this behaviour in sample.html is attached. What is the expected behavior? Text should have even spacing such as in the PDF's and screenshots provided under the Chrome browser on Windows and WKHTMLtoPDF. What went wrong? Letters have too much or too little spacing in between them, as demonstrated in the supplied PDF and screenshot from Headless Chrome. Did this work before? No Chrome version: 69.0.3452.0 Channel: dev OS Version: 3.10.0-862 Flash Version: N/A I am using CentOS 7.4, but this also occurs on 7.5. Chrome is running using Puppeteer 1.5.0 and Browsershot 3.22.1. I have not been able to find a workaround despite experimenting with Puppeteer and Browsershot's options. Additionally, I attempted to add a configuration file specifying better rendering conditions in /etc/fonts/conf.d with no success.
,
Jun 14 2018
,
Jun 21 2018
Reproduced on a fresh install of Ubuntu 18.04 (Linux kernel 4.15.0-1010) and the same version of Chrome. Output attached.
,
Jun 21 2018
My tests labeled as "Headless Chrome" above, as mentioned in the original post, are running through Browsershot, a PHP frontend for the Puppeteer API. So I could be certain neither of these were interfering, I repeated the scenario on the new Ubuntu VM exclusively using Chrome's executable in headless mode using the following command: sudo ./chrome --headless --print-to-pdf --no-sandbox https://example.com/sample.html I needed to modify the test case slightly to avoid the text disappearing. This meant calling the Source Sans Pro Google font CSS locally instead of remotely. Once again, I was able to reproduce the bug. As a control, I duplicated the same text without using an external font. Peculiarly, the default font renders with no issues at all. Please see the below files.
,
Jul 18
This issue seems similar to Issue 774970, hence merging into it and marking it as Duplicate. Note: Feel free to UN-dupe it if not the case. Thanks!
,
Jul 18
Hi there Phanindra, I think there's been a misunderstanding. Issue 774970 concerns images disappearing when they run off the bottom of a PDF page. This issue describes how text spacing is inconsistent in any location on PDF's. Furthermore, I do not have bug editing privileges, so I am not able to undo this mistake. Can you please rectify this mix-up as soon as possible?
,
Jul 18
Additional tests I've attempted using CSS properties of text-rendering and font-smoothing do not fix the problem. However, I confirmed that Headless Chrome on Windows does not encounter this issue. I've attached the output PDF. The command I used follows. chrome --headless --print-to-pdf https://example.com/sample.html I should note that there is a typo in calling the Source Sans Pro CSS in the previous attachments. The uploaded filename is fonts.css when it should be font-ssp instead.
,
Jul 20
un-duping as requested. |
||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Jun 14 2018