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 1 user
Status: Fixed
Last visit > 30 days ago
Closed: Jun 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression

Sign in to add a comment
PDF: clip path moved relative to stroke path
Reported by, May 21 2015 Back to list
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0

Steps to reproduce the problem:
Chrome's PDF rendering engine seems to have a problem with clipping. The problem might be more general than that: this is a simplified version of a problem found in the wild.

The PostScript file at 
was distilled with Adobe Distiller XI Pro 11.0.11 to make 

This renders perfectly using Mac Preview 8.0 (859.21), the screen snapshot being at 

But in Chrome Chrome version 42.0.2311.152 (64-bit) it looks wrong. 

Observe, for example, the letter 'e'. In Preview its border is of even thickness, but not in Chrome. This is typical of the examples seen 'in the wild'. 

Not knowing the innards of Chrome's PDF rendering engine, I can only guess at the cause. But perhaps the clipping path and the stroking path have been moved relative to each other. Perhaps one of them is not changed, and in the other the position of all control points is rounded to the nearest point or something. Perhaps.

This comment is at

What is the expected behavior?
Renders properly.

What went wrong?
Clipping path and the stroking path have been moved relative to each other.

Did this work before? No 

Chrome version: 43.0.2357.65 (64-bit)  Channel: n/a
OS Version: OS X 10.10.3
Flash Version: Shockwave Flash 17.0 r0
Files: one PostScript, one PDF, two PNGs. 
15.8 KB View Download
876 bytes Download
16.4 KB Download
13.3 KB View Download
For any not fluent in PostScript, below it is further condensed. Not quite code golf, but shorter than before.


/AvenirNextCondensed-DemiBold 128 selectfont

/PageWidth 617 def   /PageHeight 164 def
<< /PageSize [PageWidth PageHeight] >> setpagedevice

5 setlinewidth  0 setgray  1 setlinejoin  1 setlinecap

newpath  15 49 moveto  (jdawiseman) true  charpath  clip
newpath  15 49 moveto  (jdawiseman) false charpath  stroke


Comment 3 by, May 22 2015
Labels: -Pri-2 -Type-Bug -OS-Mac Pri-1 Type-Bug-Regression OS-All Cr-Internals-Plugins-PDF M-45
Status: Assigned
Able to reproduce this on Windows-7, Linux Ubuntu 14.04, Mac OS 10.10.3 on the latest stable(43.0.2357.65) and the latest canary(45.0.2408.0) as well.

This is regression issue broken in M-41, Change log:


tsepez@: Could you please take a look at this.
Comment 4 by, May 22 2015
The cause is revision: e4fc5ce Update freetype to 2.5.4.
Jun, could you file a bug upstream to get the freetype folks to look at this issue?  Thanks.

Status: Started
It reported that this issue only happened when freetype was upgraded to 2.5.4. I checked the history and found the reason was that Foxit did some changes in ttgload.c based on freetype Below is the details: 

/**We Disable HINT except tricky font, seem it looks better, #Testdoc:0000584_Open_CAC5U7WH.pdf,
0000879_Image_MSFNUnattendedPDF.pdf,0005480_sample-barcodes print.pdf.

    if ( IS_HINTED( loader->load_flags ) && (loader->face->face_flags&FT_FACE_FLAG_TRICKY))
      loader->zone.n_points += 4;

      error = TT_Hint_Glyph( loader, 0 );

return error; 

After freetype in chromium/pdfium was upgraded to 2.5.4, the patch above was lost. So this issue was triggered again.

However, I don't think that this fix works perfectly. I am asking guys from Freetype team about a final solution.
That was fast: thank you.

I just a bug reporter, with no understanding of the process. Please, what is a typical time from “Fixed” to being live in the latest version of Chrome?
@jdawiseman - typically 6-8 weeks to stable, give or take, as it hits beta and dev channels first.
Project Member Comment 14 by, Jun 17 2015
The following revision refers to this bug:

commit e44c8b2620991646c8e5fb06e5ab8f61a395b928
Author: thestig <>
Date: Wed Jun 17 21:34:13 2015

Roll PDFium to 2ca8fcb

2ca8fcb Separate agg-authored code from fx-authored code.
ea44bd0 Add constructor for CPDF_ColorSpace.
5fef754 Make CPDF_PageModuleDef and CPDF_RenderModuleDef pure virtual.
0ef0de5 Do some IWYU cleanups.
9869e67 Provide a constructor for CPDF_CountedObject.
38f5c33 Remove some dead code.
8bd0964 Fix -Winconsistent-missing-override warnings.
1972b16 Remove unneeded checks in
3218fff Corpus tests check for unexpected successes.
d9e1477 Remove trailing whitespaces in core.
f25db68 Remove unused reflow code.
cf2e4c3 Remove trailing whitespaces in fpdfsdk.
864773a Correct unexpected hinting fonts
eda2027 Cleanup: Get this rid of "this->" in fpdfsdk/
677b8ff Kill FXSYS_mem{cpy,cmp,set.move}{32,8}.
2b5e0d5 Cleanup: Remove uses of "this->" in core/
f726c92 Convert CPDF_FontFileMap to std::map.
7771364 Convert CPDF_IccProfileMap to use std::map.
BUG= 490814 

Review URL:

Cr-Commit-Position: refs/heads/master@{#334926}


It is now displaying beautifully as of Mac version 45.0.2454.85 (64-bit). Thank you.

FTR, it wasn’t working as of yesterday’s version, version 44.0.2403.157 (64-bit), so the fix happened between those two.

Sign in to add a comment