I can't reproduce this issue on macOS 10.13. Maybe someone with 10.12 can take a lok?

Unable to reproduce the issue on chrome reported version# 68.0.3440.84 using Mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and opened Google Docs
2) Applied Italic style to some text in the sheet and given print
3) Able to see font in italic style in printed document

@Reporter: Please find the attached screenshot for your reference.

Thanks!

Deleted: 874103.jpg 66.9 KB

	874103.jpg 66.9 KB View Download

#3: Thanks!

Since we don't have a lot of information here, I've asked the Docs folks to have affected users try:

1) Narrowing down whether this appears in the Chrome print preview vs. only once printed, and whether Chrome-created PDFs have the issue or not.
2) File Chrome feedback reports using "docs-874103" as a lookup.
3) If any folks are comfortable sharing an example doc, I've provided an alias they can use to get it to me for further testing.

I'll follow up when I hear back / have more to share.

Thanks!

1) This appears in the Chrome print preview and the printed document. Not quite sure what the second half of your question here is.

3) It seems to be OS version specific (I can repro on Mac OS 10_11_6), but an empty document with italic (Arial) text reproduces the bug. Ran a bisect:

You are probably looking for a change made after 546107 (known good), but no later than 546111 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/e6b2db639fd3cd5ab721db87b085f449b4ae1995..4312f1eb857cf62d1ab1786e997916e3e7c36329

#5: Thanks for that info, and for running a bisect!

Re: The second part of my first step. That troubleshooting step was just about ruling out any sort of post-Chrome printer-related issues by seeing if the Chrome "save as PDF" option showed the same behavior.

As per comment# 5 change-log, providing the good and bad build range 

Bisect info:
=====================
Good Build: 67.0.3381.0
Bad Build: 67.0.3382.0

You are probably looking for a change made after 546107 (known good), but no later than 546111 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/e6b2db639fd3cd5ab721db87b085f449b4ae1995..4312f1eb857cf62d1ab1786e997916e3e7c36329
Change-Id: I808c8ed04509e5d6a6074d35b4d569f22c6c3e77
Reviewed-on: https://chromium-review.googlesource.com/981176

@Wei Li: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!

The bisected CL should not the culprit since it was a change for tests only.

I am still trying to reproduce the bug. Apparently it doesn't reproduce on the latest 10.13.

Sorry, the tool output that URL and it doesn't seem to have included the full range of changes. (Someone should update that tool)

Went here instead:
https://test-results.appspot.com/revision_range?start=546107&end=546111
and
https://chromium.googlesource.com/chromium/src/+/e6b2db639fd3cd5ab721db87b085f449b4ae1995 looks more suspicious

ok, I am able to reproduce the problem on Mac 10.11. But it doesn't happen on Mac 10.12 or 10.13.

I think somehow we lost the font-style during skia serialization/deserailization. Ben, could you pls check on this? thanks.

Re #9, the indicated CL (https://skia-review.googlesource.com/c/skia/+/116463 (Switch DDL rendering to be a Via in DM (take 2)) just changes Skia's internal testing tools and shouldn't be changing anything in Chrome.

If the bisect in #9 is correct, then it's pretty obvious it's a result of 4312f1eb857cf62d1ab1786e997916e3e7c36329 "Add UsePdfCompositorServiceForTest for fieldtrial testing" which adds "UsePdfCompositorServiceForPrint" to desktop platforms. I believe this is what enabled the oopif printing.

If everything so far can be believed, then this is just a bug in 10.11 where we don't get the right font when making the request. This might possibly be fixable by re-working the SkTypeface serialization and deserialization (which needs to be done anyway).

The recent changes on improving typeface serialization in Skia land seems fixing this problem. I tried with Chrome Canary 71.0.3556.0 with MacOS 10.11, italics text was rendered correctly.

Pls confirm, thanks

#13: Thanks! I've bumped the Docs bug (b/112524952) and asked them to have the affected folks give Canary a spin and to report back. I'll follow up here when they do.

Hey all,

One of the Googlers that can reproduce this gave Canary (M71) a spin and still sees the behavior. Their comment is here: http://b/112524952#comment9

Thanks!

I can repro this on two different computers running macOS 10.12.6 and the following versions of Chrome:
- 70.03538.77 (current release)
- 71.0.3578.44 (current beta)
- 72.0.3605.0 (current canary

I tried it on two other computers that were recently upgraded to macOS 10.14.1 and there it seems to be working fine.  All accessing the same google doc, using the same google account.

To put this bug in perspective: every Chrome user in my daughter's English class just got points taken off their essay grade because the parts that were supposed to be italicized were not. The school is not yet ready to upgrade to macOS 10.14 so the only advice I could give them is to either switch from Chrome to Safari, or abandon Google Docs altogether and use Word.  But I also do not know if upgrading these computers to macOS 10.14 will fix this, since according to the previous entries, the problem was supposed to go away with macOS 12 (#10) and Chrome 71 (#13). Neither of which is true for the two macOS 12 laptops I can repro this on (both provisioned by the same school, so maybe there is something special about their setup). My daughter does not remember observing this problem during the previous academic year, so it seems likely that something did regress over the summer.

Please let me know what diagnostics I can run on the affected laptops.

Marking this bug for M71 and M72. Even though this has been open for a while, we should aim to get this investigated and fixed sooner. 

This has some complications due to dependencies and MacOS platform bug.

For the sake of the children as well as other customers, let's find a way to solve it.

A bit update: the root cause was found, the code change is still under review. https://skia-review.googlesource.com/c/skia/+/172200