New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 772482 link

Starred by 12 users

Issue metadata

Status: Archived
Owner:
Last visit > 30 days ago
Closed: Nov 22
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

Text using custom fonts are not rendered in headless print-to-pdf

Reported by dan...@talentsonar.com, Oct 6 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce the problem:
1. Run headless Chrome's print-to-pdf feature like so: 
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --no-sandbox --headless --disable-gpu --print-to-pdf=output.pdf file:///report.html
2. Open the generated PDF
3. Notice that the first line using Open Sans "Making the Web Beautiful!" is not rendered but the second line using serif is.

What is the expected behavior?
The text "Making the Web Beautiful!" in the HTML document should be rendered with the specified font (Open Sans).

What went wrong?
The text "Making the Web Beautiful!" does not get rendered in the PDF.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 61.0.3163.100  Channel: stable
OS Version: OS X 10.11.6
Flash Version:
 
report.html
471 bytes View Download
I saw there is a component called "Internals>Headless" but I couldn't select that myself. That seems more appropriate, based on the other bugs I've seen.
Components: -Blink>Internals Internals>Headless
Owner: jzfeng@chromium.org
Labels: Proj-Headless

Comment 4 by hdodda@chromium.org, Oct 17 2017

Cc: hdodda@chromium.org
Labels: Needs-Triage-M61
@could someone from headless team , Please look into this.

Thanks!

Comment 5 by jbrys...@gmail.com, Oct 26 2017

This is an issue for me as well using the latest downloaded chromium

Chromium Build Revision: 511672 (https://download-chromium.appspot.com/)
Chromium Version: Chromium 64.0.3250.0 (--version)
MacOS: 10.12.6

Command: echo '<html></html><head><link href="https://fonts.googleapis.com/css?family=Roboto:100" rel="stylesheet"></head><body><h1 style="font-family:Roboto; font-weight:100;">hello world</h1></body></html>' > tmp.html; Chromium --headless --disable-gpu --print-to-pdf tmp.html; open output.pdf

However, this is only an issue if I don't have the font installed locally. After I install the font locally, it appears in the output.

Comment 6 by j...@clockwork.com, Nov 20 2017

Running Chromium headless from within a Docker container (on a Mac host) I see this as well.  All text which is supposed to use the Roboto family fails to render in the PDF.  My version info is as follows:

Chromium 62.0.3202.89 Built on Ubuntu , running on Ubuntu 16.04

I do have the Roboto fonts (all weights) installed on the host machine.  I don't know much about PDFs. Is it fair to assume if I have the font and the PDF called for the font, it would get rendered?

I tried the workaround of installing the fonts in the container via `apt-get install fonts-roboto`.  That got me a little closer as Chromium will render the text with regular font weight but none of the bold/light text.  I can prove that those weights are installed alongside the regular weight font via a `fc-list`. 

I tried a `fc-cache -fv` thinking maybe the font list was cached but that didn't help.  Does anybody have any ideas on how I might workaround this issue for the other font weights?

Comment 7 by j...@clockwork.com, Nov 21 2017

Following up on this, I was able to work around the issue using locally installed fonts AND by removing the following from my print CSS.

@import url(https://fonts.googleapis.com/css?family=Roboto:300,400,500,700);

My guess is that the @import statement interferes with the local font lookup and since the @import isn't working it blocks the usage of local fonts.
Project Member

Comment 8 by sheriffbot@chromium.org, Nov 22

Status: Archived (was: Unconfirmed)
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment