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

Issue metadata

Status: Fixed
User never visited
Closed: Nov 2012
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression

Sign in to add a comment

Issue 128506: Random Chinese/Japanese characters are missing in documents printed via the system print dialog on Windows XP SP3

Reported by, May 17 2012

Issue description

Chrome Version       : 19.0.1084.46 & 21.0.1138.0
OS Version: 5.1 (Windows XP)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
  Firefox 4.0.1: OK
     IE 7/8:  OK/OK/

What steps will reproduce the problem?
1. open URL with traditional Chinese content.
2. Go to Print screen.
3. In the print dialog window, select "Print using system dialog ..."
4. select printer
5. print

What is the expected result?
ChromePrintDialog_PTT.pdf -> via chrome print dialog

What happens instead?
SystemPrintDialog_PTT.pdf -> via system print dialog

Please provide any additional information below. Attach a screenshot if possible.
In the document via system print dialog, many words were missed.

UserAgentString: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5
79.1 KB Download
375 KB Download

Comment 1 by, May 21 2012

Labels: -Area-Undefined Area-WebKit Feature-Printing
Is anyone on the webkit side of things willing/able to take a look at this?

Comment 2 by, May 29 2012

Does anyone have suggestions on who would be good to take a look at this?

Comment 3 by, Jun 14 2012

Labels: hotlist-Japan
vitalybuyka@ can you chime in?

abodenha@ If I recall correctly you were able to reproduce the issue. Are we sure that this is not a webkit regression?

(adding hotlist-Japan since I am seeing JP users also affected by the issue)

Comment 4 by, Jun 14 2012


Comment 5 by, Jun 19 2012

Status: Assigned

Comment 6 by, Jun 28 2012

Labels: -Pri-2 Pri-1 Hotlist-Enterprise Mstone-21
Summary: Random Chinese/Japanese characters are missing in documents printed via the system print dialog.
Vitalybuka@: thanks for jumping in. Any progress? Let me know if you are stuck.

I am adding Hotlist-Enterprise and bumping up the priority since I am getting customer enquiries about the issue via our Enterprise team.
(+ updated the summary)

Comment 7 by, Jun 28 2012

As I mentioned in comment 1, I'd really like to find an owner for this who has a bit more webkit experience.  Vitaly has quite a few other things on his plate.

Comment 8 by, Jun 28 2012

tkent@: any idea for a webkit expert we could ask to jump in here?

Comment 9 by, Jun 29 2012

I'm not familiar with printing.  I wonder if this is related to other bugs that some Chinese/Korean characters are broken in non-printing and if it might be related to Skia text drawing introduced in Chrome 19.

Comment 10 by, Jun 29 2012

Ben, potentially there is something involving Skia here. Can you diagnose what's going on? Thanks.

Comment 11 by, Jun 29 2012

I believe vandebo knows more about the PDF and printing paths involved. This could be due to the EMF printing backend (is that still used?). It could also be due to the user's PDF printer; does the same thing happen when printing directly to a printer (or a different PDF printer) instead of printing to this specific PDF printer?

It would be very unlikely for this to be related to the non-printing issues with some Chinese/Korean fonts, as those issues are universally caused by embedded bitmaps.

Comment 12 by, Jun 29 2012

Labels: Action-FeedbackNeeded
PoWen84, do you get the same bad result when printing to the XPS virtual printer or does it only work incorrectly when using Acrobat Distiller?

I tried to reproduce the problem and couldn't.  Printing (using the system dialog) to the XPS virtual printer, to a printer, or to Acrobat Distiller (as the reporter did) all yield good results.  The bad PDF is generated with Distiller version 7.0.5 whereas the current version is 10, I don't know if version 7 supports chinese.

Arthur ran into a bug a bit ago where some CJK pages rendered incorrectly depending on the order of language support

Comment 13 by, Jul 11 2012

Labels: -Mstone-21 MovedFrom-21 Mstone-22
Moving all non essential bugs to the next Milestone

Comment 14 by, Jul 23 2012

I don't think this bug has anything to do with Acrobat Distiller / "print to PDF".

Here are the detailed reports I have so far from user with the issue when printing (to paper) from the system dialog:

Printer: RICOH imagio MP 7500 RPCS
Driver version: RPCS Printer Driver Version7.69
Chrome version: 19.0.1084.56 m
Windows XP Professional Version 2002 Service Pack 3
OS language: Japanese

Brother HL-5350DN
Driver version: 1.07
Chrome 19.0.1084.56
Windows XP Home SP3 Japanese

Report #3:
Brother DCP-J715N
Version 5.00
Chrome 19.0.1084.56
Windows XP Professional Ver 2002 SP3

This is still happening on Chrome 20 (confirmed on 20.0.1132.43).

Comment 15 by, Jul 23 2012

One additional report:

Printer: DocuPrint 2060
Driver Fuji Xerox ART EX Version 2.6.3
OS: Windows XP Professional (Build 2600) SP 3 (Japanese)

As far as the reports seem to indicate, it could be something specific to Windows XP SP3.

Comment 16 by, Jul 23 2012

I was able to repro.
I will send more details directly by email.

Comment 17 by Deleted ...@, Jul 27 2012

OS: Debian GNU/Linux 6.0 64bit
Chrome version is 18.0.1025.142

It can't print Korean context from web pages that have light Korean fonts most of time.

Comment 18 by, Jul 27 2012

penguinisdreaming: Please file a separate bug for your Linux issue. Also, your Chrome is 2 versions out of date.

Comment 19 by, Aug 3 2012

I can consistently reproduce a bug that may be the same as this, using WinXP SP3 as also reported by others. Also happens in Safari.

In my case, the bug is only visible in missing tildes for the Spanish language (Á, Ñ, etc) when using @font-face.

I was able to work around this bug by removing anti-alias in the CSS:
@media print { * { -webkit-font-smoothing: none;} }

Comment 20 by, Aug 6 2012

Update: I can also reproduce this in Chrome + Win7.
Seems to be fixed by one or more of:
- -webkit-font-smoothing: none;
- text-rendering: optimizeSpeed;  
- adding proper MIME types: AddType application/x-font-woff woff

The bug is really random, happens in some page reloads but not all. 
So I wasn't able to pinpoint which of the fixes above is the 'real' fix.

None of these fixes work in older versions of Chrome (tried Windows Vista with Chrome 5), which prints the default Arial instead of the custom font, but with the missing characters!

So: I ended up removing custom fonts, and using the default sans-serif for @media print.

I guess this mess explains why Firefox doesn't support printing @font-face at all!

Comment 21 by, Aug 10 2012

Labels: -Mstone-22 Mstone-23

Comment 22 by, Aug 13 2012

I wasn't able to repro with Kenji's repro steps.

Since the issue occurs in the native print flow, none of the Skia PDF code is used and there's nothing print specific about the use of Skia at that point either.  As Ben points out, that flow uses the EMF backend for Skia, which is all but abandoned.

razzari's comments suggest that there's probably something going on in WebKit.  Punting back to tkent

Comment 23 by, Aug 14 2012

Labels: -Action-FeedbackNeeded Internals-Skia ReleaseBlock-Stable
Summary: Random Chinese/Japanese characters are missing in documents printed via the system print dialog on Windows XP SP3
I reproduced the issue on Windows XP SP3 Professional Japanese edition running on VMware.

Bisect result:

You are probably looking for a change made after 115298 (known good), but no later than 115314 (first known bad).

In this WebKit rage, we have "enable USE_SKIA_TEXT by default, replacing GDI for all text drawing," and no other font-related changes.

Comment 24 by, Aug 14 2012

Labels: -Type-Bug Type-Regression

Comment 25 by, Aug 14 2012

The EMF backend as written is a dead-end: it presumes that all of the drawing ops that come out of webkit/skia can be expressed using GDI, and that is just not the case (some transparency effects, xfermodes, clips).

Since the skia-pdf printing is correct, I suggest we consider either finding a way to always be able to use that, or use pictures to capture the page(s) and then write our own low-level EMF output (basically high-res raster).

Related, is it required that we use EMF with the system dialog? If the pdf-plugin is present, can it not be used in this case?

Comment 26 by, Aug 14 2012

Using the pdf-plugin has its own set of issues.  The pdf-plugin basically always rasterizes the output so if you want to print to a virtual printer, you've lost the text information.  That could be fixed, but the bug has been open for a long time without any movement.

Is it feasible to fix this issue?  Since the EMF backend is GDI based, it seems like anything that worked before the transition to USE_SKIA_TEXT should be technically possible still.  i.e. is it a font problem, are we dropping some information?

Comment 27 by, Aug 15 2012

Labels: -ReleaseBlock-Stable
ok is this a RBS for 23? i don't think so. it's been there for 9months ;) if u have a fix, when u have a fix, we;ll take it

Comment 28 by, Aug 22 2012

Reed@: I am not sure if your reply ("it presumes that all of the drawing ops that come out of webkit/skia can be expressed using GDI, and that is just not the case") means that vandebo@'s question ("Since the EMF backend is GDI based, it seems like anything that worked before the transition to USE_SKIA_TEXT should be technically possible still.  i.e. is it a font problem, are we dropping some information?") is moot but could you confirm/infirm?

Would it be possible/faster to revert back from use_skia_text only for that particular code path? Not sure if that make any sense at all, I am grasping at straws...

Comment 29 by, Sep 11 2012

Any updates? orz

Comment 30 by, Sep 21 2012

Sorry for the long silence. Our internal printing knowledge is still working to get up to speed. I am looking at this now, but my first task is going to be just understanding how the old code works. I will update this again as soon as I have found something.

Comment 31 by, Sep 21 2012


Comment 32 by, Sep 21 2012

1) It does not reproduce on Win 7. I tried some some compatibility does, and it does not have. It seems I must have XP SP3 

2) I got an XP machine, but the web page uses Big5 charset which is not installed by default on windows XP. The machine I have provisioned does is not giving me access to the installation CD which I must have to istall it. I am working to get a machine properly set up (Big5 fonts, debugger, chrome, ...)

Comment 33 by, Sep 21 2012 Big5 is not needed. Any non-ASCII Unicode chars will fail. You should be able to repro in Win 7 too. See my earlier notes on this thread. Thanks!

Comment 34 by, Sep 21 2012

I am not able to reproduce the issue, I have tried 4 machines now (XP SP3, Win 7) 

But I used chrome version 21, maybe it was fixed. Can you try again with version 21 please?

I will need exact machine configuration details, or remote access to a machine that does repro, so I can debug the issue.

The spanish issue might be or not the same. Can you send me the issue url for repro?


Comment 35 by, Sep 21 2012

I was able to reproduce this issue in the following versions of Chrome:

Win 2k3 > Chrome 21.0.1180.75
Win XP SP3 > Chrome 15.0.874.10
Win 7 > Chrome 9.0.597.84
Win Vista > Chrome 5.0.307.1
Win 7 > Chrome 2.0.172

I don't have a testcase at hand, unfortunately. 
I can create one for you if needed.

Comment 36 by, Sep 26 2012

Labels: -Mstone-23 Mstone-24
Thanks for looking into this.
Please, let me know if you are stuck.

Comment 37 by, Sep 26 2012

I have tried Windows 7, Vista and Xp, with a few Chrome versions, and I can't reproduce the issue on our machines.
I also built Chrome manually at version 9.0.597.94 (Chrome 9.0.597.84 has a build break) and latest on Windows 7.

I am not able to reproduce the issue. If anyone has a machine I could remote debug, that would be great.

There must be something installed/configured on those machines differently than what I have. I need first to be able to reproduce the issue somewhere to be able to investigate, fix, and test the fix.

Comment 38 by, Sep 27 2012

edisonn@: Thanks. I just sent you an email with repro steps and a sample XPS file. Let me know if that helps.

Comment 39 by, Sep 30 2012

The interesting code to debug seems to be in chromium\src\printing\

Emf::SafePlayback calls EnumEnhMetaFile which will enumerate all the records of the HDC by calling Emf::SafePlaybackProc, which does further processing in Emf::Record::SafePlayback

There are a couple of surface areas here which needs to be investigated.

Comment 40 by, Sep 30 2012

I created a test html file, with 2 characters only, one printable and one non-printable, and tested XP SP3 JA vs Win7 En

On Win7 En EnumEnhMetaFile throws 2 extra callbacks when we end up calling Play:
- An EMR_HEADER - I think this one should be fine, probably it is because os change
- An EMR_EXTTEXTOUTW - I think this is the one for the missing character.

- diff similar on Emf::Record::SafePlayback
- enumerate the content of the HDC on both OSes, to see what is different
- diff XP SP3 En (not repro) vs XP SP3 Ja (repro)

Comment 41 by, Oct 11 2012

debugging file:

<?xml version="1.0" encoding="Big5"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN"
<html xmlns=""
      xml:lang="zh-TW" lang="zh-TW">
<meta http-equiv="Content-Type" content="text/html; charset=big5" />


Comment 42 by, Oct 11 2012

debugging (1) XP SP3 Simplified Chinese (not repro) vs (2) XP SP3 Japanese (repro)

void PrintViewManager::OnDidPrintPage(
    const PrintHostMsg_DidPrintPage_Params& params) {

params.metafile_data_handle has a size of params.data_size which in (1) has 1616 bytes vs (2) which has 1532 bytes.

The metafile_data_handle is already different at this stage, looking into the creation of the metafile

Comment 43 by, Oct 11 2012

Issue 151864 has been merged into this issue.

Comment 44 by, Oct 17 2012

I did lots of experiments, but I could not find a fix.

Everything works fine if I run with --no-sandbox. As a workaround I tried to call ensurePrecacheFont before each character, but I still get the same issue.

The weird thing is that the font seem to be present partially,  and some characters print and some never print.

My suspicion is that ensurePrecacheFont does nothing for the printing thread, and we print characters that so happen to be in the cache anyway.

I am talking offline with a few sandbox experts to get help and insight into how sandboxing works and affects printing.

Comment 45 by, Oct 17 2012

relevant functions to debug:

Comment 46 by, Oct 25 2012

I have shared this bug with kinaba@ who fixed something that was somehow related to "ensureFontLoaded"/"ensurePrecacheFont".

He might be able to provide guidance.

edisonn: what's the latest status on this? Did you learn anything new?
Thanks again for tackling such a beast of a bug.

Comment 47 by, Oct 25 2012

Process Monitor indeed reports that a chrome process gets a permission denied to read a font file. I am trying to convince Process monitor to show me the call stack, instead of call offsets ...

Comment 48 by, Oct 25 2012

So DENIED ACCESS call stack is indeed in the sandboxed process, during ExtTextOut(), after we just called ensureFontLoaded.

It seems that caching process caches jvgasys.fon
Sanboxed Printing process tries to use micross.ttf
while we should have had both processes using mingliu.ttc, which is what was specified in all requests

Comment 49 by, Oct 25 2012

Arthur: Does this sound familiar to you?

Comment 50 by, Oct 26 2012

The rendering thread is caching vgasys.fon and it works fine with it. So at least this would work fine.

The thread caching jvgasys.fon is actually Display Printing Dialog Job.

The ensureFontLoaded does absolutely nothing, when the message comes from the printing thread - even if I put a breakpoint and  it seems FontCache::PreCacheFont() is called indeed.

issues I am looking into now:
1) why does the printing thread ends up requesting micross.ttf?
2) why does the FontCache::PreCacheFont() does no caching when the message comes from the printing job?

I think the issue might be related to multiple conversions between LOGFONT and HFONT (various function pass a HFONT, but pass to other functions a new LOGFONT, which is used to create a new HFONT)

Comment 51 by, Oct 26 2012

That is all more strange as we do specify in LOGFONT.lfOutPrecision OUT_TT_ONLY_PRECIS, which should equate with more exact font substitution.
In the  OUT_TT_ONLY_PRECIS forces the font mapper to choose a TrueType font, even if it must substitute a TrueType font of another name.

I will try a hack Ben suggested, to create a unique new font, do get around DGI magic

Comment 52 by, Oct 26 2012

So the code that is supposed to make sure the font is loaded FontCache::Precache() does not load fonts for printing thread, because for some reason GetTextMetrics(hdc, &tm) does not precache the font for a HDC of a EnhMetaFile

I have found a way to force loading the font: 
hdc = CreateEnhMetaFile(NULL, NULL, NULL, NULL);
ExtTextOut(hdc, 24, 24, 16, 0, reinterpret_cast<const wchar_t*>(foo), foo_length, NULL);

where foo are the characters about top be printed.

And this works.

Now I will investigate some more elegant ways to bring the font in memory and produce a fix asap.

Comment 53 by, Oct 26 2012

This is already a very elegant hack and I like it :)

Comment 54 by, Oct 26 2012

VectorPlatformDeviceEmf::drawText calls ExtTextOut which reports false if the character is not printed.

We this in mind we could force the font load on the first failure.

Comment 55 by, Oct 29 2012

Status: Started
Assigned  the issue to me. Working on a fix

Comment 56 by, Oct 29 2012

The cause of the bug is that ensureFontLoaded just does not work for the printing thread because GetTextMetrics(font) is not guaranteed to load the font for an HDC build from CreateEnhMetaFile. The only way I found to force font loading is to create a dummy HDC with CreateEnhMetaFile and then print the offending character.

In the sandboxed thread ExtTextOut returns false if we did not printed a character. (thanks Ben for pointing this out!)

My suggested (minimum) fix is to:

1) add a second way of precaching, special for printing, which would maintain a dummy HDC from CreateEnhMetaFile (reset from time to time) which would actually do an ExtTextOut with a specific character:
2) update sanboxed printing thread from just ExtTextOut(..., ch) to:
if (!ExtTextOut(..., ch)) {
  precacheForPrinting(..., ch);
  if (!ExtTextOut(..., ch)) {
    not_printed++; // TODO: - maintain a set<ch> too?

On top of this I would like to:
A) send back to chromium project the URL/not_printed, if not_printed>0 (of course, the user has to agree)
B) if (not_printed > 0), report warning to user (how?).

I agree that doing B) might be annoying and might worry most users, but feels to me the right thing to do. 
Doing A) could give us quick feedback. We coud also prepare a standard mail, which the user can edit and send to a special email address. I don't know what is the best practice used in Chrome, feel free to suggest alternatives.

If you think I should not do A) and/or B), please speak out.


Comment 57 by, Oct 29 2012

For 1), I'd probably just create/destroy the dummy DC as needed - the case should be pretty rare, and creating a DC is cheap, and the code should end up more readable and easier to maintain that way.

For A) and B), I'd just VLOG() it. Those who need or want to know can turn on logging (or can be directed to when they find their way here).

Comment 58 by, Oct 30 2012

Labels: ReleaseBlock-Beta
I second scottbyer regarding A) and B): VLOG().
Would it make sense to have UMA to get a sense of how big this remaining hole is?

Comment 59 by, Oct 31 2012


Comment 61 by, Nov 2 2012

Labels: -ReleaseBlock-Beta ReleaseBlock-Stable
This is a long tail bug which shouldn't block initial beta. The fix seems to be huge which needs more time for baking in canary. So I would like to move this to stable instead of beta.

Comment 62 by, Nov 16 2012

Just noting here that vandebo@ thinks this may also fix  issue 132239 

Comment 63 by, Nov 16 2012

No the fix it won't help.
The fix for this bug address the missing characters which are not cached. This issue is more like, where simply the wrong font is used.

Comment 64 by, Nov 21 2012

Project Member
The following revision refers to this bug:

r168943 | | 2012-11-21T01:14:56.535215Z

Changed paths:

This is a fix for - 	Random Chinese/Japanese characters are missing in documents printed via the system print dialog on Windows XP SP3

The cause of the bug is that ensureFontLoaded just does not work for the printing thread because GetTextMetrics(font) is not guaranteed to load the TrueType font for an HDC build from CreateEnhMetaFile. The only way I found to force font loading is to create a dummy HDC with CreateEnhMetaFile and then print the offending character(s).

This change contains:
 - wirings for foo_CacheFontCharacters similar with foo_CacheFont, but with dispatch this message in RenderMessageFilter and defined in view_messages.h
 - SkFontHost::EnsureTypefaceCharactersAccessible similar with SkFontHost::EnsureTypefaceAccessible
 - Small refactoring of ExtTextOut call which would
    - Call ExtTextOut
    - If failed, calls SkFontHost::EnsureTypefaceCharactersAccessible
    - call ExtTextOutAgain and return success/failure
    - the calller will default to a skia paintPath (lower quality, but correct) if above fails

Notice: No tests for now, lets's make sure the design is right, then I will add tests too.

Contributed by

Review URL:

Comment 65 by, Nov 21 2012

This change is now part of 25.0.1331.0 canary build. Could someone please verify it?

Comment 66 by, Nov 21 2012

Seems fixed! For my usecase at least (tilde characters in Spanish language).

Comment 67 by, Nov 22 2012

I confirmed printing in Windows XP Japanese had no problems with 25.0.1331.0 canary.

Comment 68 by, Nov 22 2012

Adding my voice here: confirmed that the issue is fixed (Windows XP Japanese, nikkei homepage side by side comparison).

Also confirmed by a user on our help forum.

Thanks a gazillion times edisonn@!

Comment 69 by, Nov 22 2012

Status: Verified
(for the record)

Comment 70 by, Nov 22 2012

Status: Started
And reverting to started to not miss the merge to 24 just before it hits stable.

Comment 71 by, Nov 22 2012

Labels: Merge-Requested

Comment 72 by, Nov 26 2012

Labels: QA-Verified
printed using chrome://print and system dialog, haven't noticed any differences between the two outputs. 

Verified on today's canary: 25.0.1335.0

Comment 73 by, Nov 26 2012

Labels: -Merge-Requested Merge-Approved

Comment 74 by, Nov 27 2012

Project Member
Labels: -Merge-Approved merge-merged-1312
The following revision refers to this bug:

r169567 | | 2012-11-27T03:36:19.671721Z

Changed paths:

Merge 168943 - Fix for 128506: Random Chinese/Japanese characters are missing in documents printed via the syst...

BUG= 128506 
Original Review URL:
Review URL:

Comment 75 by, Nov 27 2012

Status: Fixed

Comment 76 by, Mar 9 2013

Project Member
Labels: -Type-Regression -Area-WebKit -Feature-Printing -Mstone-24 -Internals-Skia Cr-Content Type-Bug-Regression Cr-Internals-Skia M-24 Cr-Internals-Printing

Comment 77 by, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 78 by, Jul 1 2015


Sign in to add a comment