- I'm guessing this is a Windows-only problem
- Setting milestone to M52. Not sure if there's enough time for M51.

+caryclark FYI.

The overview, as I see it:

1) Skia generates a PDF from HTML, or the starting source is a PDF
In either case, the PDF contains text and fonts.
2) When printing, Chrome on Windows feeds the PDF into PDFium running in an utility process, and asks PDFium to render the PDF to EMF
3) The EMF that comes out no longer has text + fonts, and instead has many bezier curves instead.

PDFium internally uses Anti Grain Geometry to do some of the renderings. Cary is looking at replacing AGG with Skia. Maybe that will magically fix the problem?

If Skia is not the magic bullet, we need to figure out why PDFium is losing the font information. From bug 409472, which is likely related, it used to work.

In M36 and earlier, for HTML source at least, Chrome talked directly to Skia and text came out as text. In M37 and later, we get the status quo. I believe that's what bug 409472 is about.

Looking at the code, one problem is AGG does not know how to render text as text, so PDFium never bothered to attempt to draw text, and draws paths instead - the non-Mac version of CFX_AggDeviceDriver::DrawDeviceText() does nothing and just returns false. There is some more Windows-only rendering code, but that does not do anything either text-wise unless it outputs PostScript.

We could implement DrawDeviceText() for Windows somewhere, but AGG is an evolutionary dead end, and possibly so is the Windows-only code I'm looking at. Assuming that's the case, any code written will be tossed away in the near future anyway. It's probably a better use of engineering effort to just switch to Skia.

... and looking at Skia bugs, I see Skia decided to:

- Not bother with EMF: https://bugs.chromium.org/p/skia/issues/detail?id=2772
- Go with XPS instead, but that needs some work? https://bugs.chromium.org/p/skia/issues/detail?id=3495

We can test PDF → Pdfium → Skia → SkXPS → XPS with:

1) Build pdfium_test using pdf_use_skia==1

2) Convert the PDF to SKP with `pdfium_test --skp`

3) Convert the SKP to XPS with `dm --config xps --src skp --skps FILE.skp -w DIR` (Windows only).

Then we can check to see if the XPS is "better" than the EMF.

If this is the direction we want, we can alter pdfium_test to produce XPS documents on Windows.

Skia bringup is preliminary. Following the steps in #7 is premature.

That said, it's appropriate for Skia to figure out how to output to EMF (bug referenced in #6 updated)

Why was this marked as iOS? 

Please ignore c#13.  HP confirmed that the problem only shows up on Windows.

[from HP]
I just tested the same print process described below (for Chromebook) on a MacOC 10.10 device.  The result was the same as what we saw on Chromebook – the PDF file that is sent to the printer did contain fonts.
 
So, as you speculated, this seems to be isolated to Chrome on Windows.  To summaryize:
 
·         Chromebook: print file (PDF) contains fonts

·         MacOS: print file (PDF) contains fonts

·         Chrome on Windows: print file does not contain fonts – all font outlines are vectorized.

Moving this nonessential bug to the next milestone.

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

@thestig : Do we have an ETA on this bug ? Seems odd that the bug is at P1 but has no comments for over a month.

royans: I've been updating bug 409472. There is progress, but I have some font kerning issues to work through, and I need to check and make sure it handles vertical text. (CJK vertical text, not text rotated 90 degrees.)

Please try out Chrome 54.0.2839.0 or newer (should be available via Chrome Canary in a day or two) and see how well printing works. There has been several printing and layout changes, so comparisons to earlier Chrome versions is not exactly apples to apples. I have made the --disable-gdi-text-printing command line switch available (for now) to allow disabling this fix. Thus allowing comparisons between the same version of Chrome with and without this fix. Please report improvements or breakages with the new code.

The only known issue I encountered is printing to the XPS Document Writer virtual printer may fail. It only happens to me on one computer and I'm not sure why.

Today Google Chrome Canary updated to 54.0.2839.3, so please try out the fix if you'd like.

And it's been pointed out this is different from bug 409472 - the source is a PDF and not HTML. Unfortunately I have not been able to load the fonts embedded in PDFs into GDI. Until we get over this hurdle, I cannot actually make any progress on this.

thestig@ is this tied to  crbug.com/658606  ? Will fix have been reverted with that? If so I guess we should mark this as dependent on 658606?

 Issue 672916  has been merged into this issue.

guys any update when pdf print will be fixed in chrome. I will have to move a lot of users from chrome to firefox to get this resolved.  

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/12/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.