Able to reproduce this issue on Windows 10, Ubuntu 14.04  with chrome version 55.0.2883.87 and Mac 10.12.2 on chrome stable version 55.0.2883.95 and also in current canary version #58.0.2989.0
Issue is broken in M45.

Bisect Info:
===========
Good build : 45.0.2453.0,  Revision Range -338191
Bad build  : 45.0.2454.0,  Revision Range -338390

After executing the bisect(old) script , i got the following CL's between good and bad build versions
===========================================
https://chromium.googlesource.com/chromium/src/+/87a6655be684f2c6476ab43ddeb24a6237774912

The suspecting Change Log is :
-----------
https://chromium.googlesource.com/chromium/blink/+/bd44f747096182914413243beb04832961564b68

From the above CL suspecting the below change
---------------------------
https://codereview.chromium.org/1224973002

mstensho@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

Sorry, I can't reproduce this. I don't know how to get hold of the exact version used, but I tried with https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F423790%2Fchrome-linux.zip?generation=1475811088672000&alt=media - which is 56.0.2884.0, which should be the branch point for the Chrome 55 release branch. Using Debian Stretch. Also tested with a random Chrome 54 build.

line-height:1.18 is close to 1.2, which is the default line height, as far as I know. If you reduce the line height, you easily end up with overlapping line boxes, and one could imagine a bug where we fool ourselves into thinking that one and the same line belongs both at the bottom of the previous page and at the top of the next page. I suppose such a bug could be either in Blink layout code or in the PDF generator.

The suspected CL sure looks relevant, in that it could trigger something like this effect. However, as long as I cannot reproduce it, there's little I can do. I seem to recall that this CL caused some other regressions that got fixed, but that would have been way before Chrome 55.

Maybe you could retest?

I've tried with the latest chromium version for windows 10 (61.0.3118.0 32 bit) available at this url: https://www.chromium.org/getting-involved/download-chromium and the issue is still there.
Also I've tried with the latest version of chrome available on windows 10 for the stable channel (58.0.3029.110 64bit) and there is still the problem.
I've also tried with Chromium Version 60.0.3100.0 on Ubuntu 14.04 64 bit and the problem is the same.
I think that the problem is still there.

Deleted: paragraph_line_height_1_chromium_Version 61.0.3118.0 (Build) (a 32 bit).pdf 88.6 KB

paragraph_line_height_1_chromium_Version 61.0.3118.0 (Build) (a 32 bit).pdf 88.6 KB Download

Deleted: paragraph_line_height_1_chrome_58.0.3029.110 64bit.pdf 88.6 KB

paragraph_line_height_1_chrome_58.0.3029.110 64bit.pdf 88.6 KB Download

Deleted: paragraph_line_height_1_Chromium Version 60.0.3100.0 on Ubuntu 14.04.pdf 42.3 KB

paragraph_line_height_1_Chromium Version 60.0.3100.0 on Ubuntu 14.04.pdf 42.3 KB Download

Thanks. I see it now. Still valid.

I don't know how to fix this, but my current guess is that it has to be done on the PDF generator side. I tested with two PDF viewers (evince and the built-in one in Chrome), and both show the bug.

@dsinclair - Last time we spoke (February) I think you were working on pdfium? Do you have any idea what could be done?

Basically, what seems to be happening here is that we have a line box that's slightly shorter than the text inside (height-wise). The line of text is at the exact top of some page, and because of this, we're somehow able to search for that piece of text and get TWO matches - one (invisibly) at the bottom at the previous page and one at the next page, where the text actually is.

Deleted: tc.html 300 bytes

tc.html 300 bytes View Download

PDF generation is done on the Skia side, halcanary@ would be the person to comment I believe.

Since this renders the same in Chromes PDF viewer and evince I'm guessing it isn't a PDFium issue.

I will try to reproduce with recent milestone.

This may be Blink drawing text outside of the page's clip.  Not sure yet.

Attached is a simplified test case: When I extract text from the printed PDF, I get "22" twice.

Blink must be drawing this value one each page.  It is invisible on the first page due to, I suspect, the clip.

Deleted: crbug_267526.html 659 bytes

crbug_267526.html 659 bytes View Download

Reproduced in Chrome/60.0.3112.7 on Linux.

Yes, Blink does paint text that overflows the page. The text is taller than the line box, and the line box is flush with the top of the page. Text will overflow both above and below the line box. But that ends up as two separate lines in the PDF somehow? I don't know much about the PDF format. The problem on the Blink side is of course that Blink doesn't support native/first-class fragmentation. The layout engine doesn't really output pages, but rather one long scroll that has to be sliced into pages during painting/printing.

In the next generation Blink layout engine, there'll be native support for fragmentation, so we'll no longer paint lines at page boundaries twice, like we risk doing today. Until then, there's really nothing we can do about this, unless it can be fixed on the PDF generation side.

Attaching one more demo, that uses an oversize inline-block that's brutally sliced into two columns. When saving this as PDF, even stranger things start to happen. I'm guessing that the inline-block is offset and painted in its entirety (but clipped) once per column it occurs in.

Do you perform any paint culling on the PDF generation side, or is that something that needs to take place inside Blink painting? I mean, it seems completely unreasonable that e.g. the first line in the first column also be painted in the second one (since no part of that line is going to be visible in the second column). Seems to me that everything is painted in every column, but clipped, so that it's invisible (but still searchable).

I don't know what to do with the line that actually crosses the column boundary ("VEXT"). We obviously need to paint the line twice, don't we? But it still sounds weird for it to occur twice in the text representation of the PDF. Or?

Deleted: demo.html 1.0 KB

demo.html 1.0 KB View Download

I think that SkCanvas culls at the SkTextBlob level.

https://skia.googlesource.com/skia/+/refs/heads/master/src/core/SkCanvas.cpp#2541

I could do an additional culling step inside SkPDFDevice::internalDrawText.

I think I could cull by text run, by text cluster, or by glyph.  Which is most correct?

I'd say whatever corresponds to a "line box" in CSS. Is that a text run? Or could that span several lines?

In progress:  https://review.skia.org/19706

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/699b8732bf7b1ea3fbcce0b77a60f96fc4f8446c

commit 699b8732bf7b1ea3fbcce0b77a60f96fc4f8446c
Author: Hal Canary <halcanary@google.com>
Date: Wed Jun 14 21:51:36 2017

SkPDF: Glyph-by-glyph bounds-reject.

BUG= chromium:682644 
Change-Id: I9d20dd81886d4de4e74ba043349d456230c89cb1
Reviewed-on: https://skia-review.googlesource.com/19706
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>

[modify] https://crrev.com/699b8732bf7b1ea3fbcce0b77a60f96fc4f8446c/src/pdf/SkPDFDevice.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a4f86d783aa749f037bf39c04be0b5a60808c8f2

commit a4f86d783aa749f037bf39c04be0b5a60808c8f2
Author: skia-deps-roller@chromium.org <skia-deps-roller@chromium.org>
Date: Thu Jun 15 02:50:58 2017

Roll src/third_party/skia/ 1d06078fe..a0485d945 (12 commits)

https://skia.googlesource.com/skia.git/+log/1d06078fef78..a0485d945299

$ git log 1d06078fe..a0485d945 --date=short --no-merges --format='%ad %ae %s'
2017-06-14 bsalomon Revert "Converts remaining rect ops from GrLegacyMeshDrawOp to GrMeshDrawOp subclasses."
2017-06-13 halcanary SkPDF: Glyph-by-glyph bounds-reject.
2017-06-14 bsalomon Fix logic reversal in NonAAFillRectOp test factory
2017-06-14 robertphillips Prevent onFlushCB created opLists from being grouped with the normal ones (new)
2017-06-14 bsalomon Converts remaining rect ops from GrLegacyMeshDrawOp to GrMeshDrawOp subclasses.
2017-06-14 robertphillips Drop the ref on the GrOpList's target in makeClosed (take 2)
2017-06-14 csmartdalton Fix failing dm with GrPrimitiveType::kLinesAdjacency
2017-06-14 egdaniel Revert "Revert "Go back to using dual source blending for lcd src-over even with non-opaque color""
2017-06-14 egdaniel Update PixelXL bots to O developer preview 3
2017-06-14 robertphillips Revert "Drop the ref on the GrOpList's target in makeClosed"
2017-06-14 bsalomon Force AAType to MSAA if the render target has MSAA and the API doesn't support disabling it.
2017-06-14 robertphillips Drop the ref on the GrOpList's target in makeClosed

Created with:
  roll-dep src/third_party/skia
BUG= 682644 


Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, see:
http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls


CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
TBR=rmistry@chromium.org

Change-Id: I74bff9f70113343da2c2ee69d5788a452c1425f8
Reviewed-on: https://chromium-review.googlesource.com/536175
Reviewed-by: Skia Deps Roller <skia-deps-roller@chromium.org>
Commit-Queue: Skia Deps Roller <skia-deps-roller@chromium.org>
Cr-Commit-Position: refs/heads/master@{#479586}
[modify] https://crrev.com/a4f86d783aa749f037bf39c04be0b5a60808c8f2/DEPS

Great! Looks like you fixed it! My tc.html passes.

Seems to be fixed in the m61 canary.

We now skip glyphs that fall outside of the current clip.  This is conservative, since I look for overlap of the bounding rectangles of the clip and the glyph.

This also has the added benefit of making the resulting PDF possibly smaller.