Inconsistent offset of characters in the printed pdf
Reported by
expro...@gmail.com,
Sep 12
|
||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Example URL:
Steps to reproduce the problem:
Open the following page in Chrome 68.0.3440.106 and print it to A4 pdf.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Illustration</title>
<style>
body {
display: flex;
justify-content: center;
font-family: "DejaVu Sans";
font-size: 16pt;
}
</style>
</head>
<body>
<p>
<span style="display: inline-block; transform: scaleY(0.999)">⎜</span><br>
<span style="display: inline-block; transform: scaleY(1.000)">⎜</span><br>
<span style="display: inline-block; transform: scaleY(1.001)">⎜</span><br>
<span style="display: inline-block; transform: scaleY(2)">⎜</span><br>
<span style="display: inline-block; transform: scaleY(3)">⎜</span><br>
<span style="display: inline-block; transform: scaleY(4)">⎜</span><br>
</p>
</body>
</html>
What is the expected behavior?
All the "⎜"s should be vertically aligned.
What went wrong?
The second "⎜" which is not scaled (or scaled by 1.000) has a little offset.
Here is the text section of the decoded pdf (note the ".15625")
>>>
q
3.1263134 0 0 3.1231871 1222.38855 90.702171 cm
/G0 gs
BT
/F0 21.33 Tf
1 0 0 -1 0 20 Tm
<0DB4> Tj
ET
Q
q
3.1263134 0 0 3.1263134 1222.38855 168.82092 cm
/G0 gs
BT
/F0 21.33 Tf
1 0 0 -1 .15625 20 Tm
<0DB4> Tj
ET
Q
q
3.1263134 0 0 3.1294398 1222.38855 246.9397 cm
/G0 gs
BT
/F0 21.33 Tf
1 0 0 -1 0 20 Tm
<0DB4> Tj
ET
Q
q
3.1263134 0 0 6.2526269 1222.38855 286.05768 cm
/G0 gs
BT
/F0 21.33 Tf
1 0 0 -1 0 20 Tm
<0DB4> Tj
ET
Q
q
3.1263134 0 0 9.3789406 1222.38855 325.1366 cm
/G0 gs
BT
/F0 21.33 Tf
1 0 0 -1 0 20 Tm
<0DB4> Tj
ET
Q
q
3.1263134 0 0 12.5052538 1222.38855 364.21552 cm
/G0 gs
BT
/F0 21.33 Tf
1 0 0 -1 0 20 Tm
<0DB4> Tj
ET
Q
<<<
while the pdf saved by firefox 62.0 has no such offset:
>>>
BT
16 0 0 15.984 293 750.005501 Tm
/f-0-0 1 Tf
<0001>Tj
ET
Q q
54 787 487 -711 re W n
290 749 14 -25 re W n
0 0 0 rg /a0 gs
BT
16 0 0 16 293 731 Tm
/f-0-0 1 Tf
<0001>Tj
ET
Q q
54 787 487 -711 re W n
290 730.012 14 -26.027 re W n
0 0 0 rg /a0 gs
BT
16 0 0 16.016001 293 711.994498 Tm
/f-0-0 1 Tf
<0001>Tj
ET
Q q
54 787 487 -711 re W n
290 723.5 14 -50 re W n
0 0 0 rg /a0 gs
BT
16 0 0 32 293 687.5 Tm
/f-0-0 1 Tf
<0001>Tj
ET
Q q
54 787 487 -711 re W n
290 717 14 -75 re W n
0 0 0 rg /a0 gs
BT
16 0 0 48 293 663 Tm
/f-0-0 1 Tf
<0001>Tj
ET
Q q
54 787 487 -711 re W n
290 710.5 14 -100 re W n
0 0 0 rg /a0 gs
BT
16 0 0 64 293 638.5 Tm
/f-0-0 1 Tf
<0001>Tj
ET
<<<
While that offset in the page and in the printed pdf is hardly recognizable when viewed in chrome, it is obvious in other pdf viewers (see Illustrated-in-Atril.png).
Does it occur on multiple sites: N/A
Is it a problem with a plugin? No
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 68.0.3440.106 Channel: n/a
OS Version: XUbuntu 18.04
Flash Version:
,
Sep 12
Is it correct to assume it displays properly on screen, and this only happens when printed to PDF?
,
Sep 12
I think I can see the offset on my screen, if I zoom in all the way.
,
Sep 12
Yes, I think I can see if on the screen as regular HTML. I guess this is a layout issue then?
,
Sep 13
Transforms are paint time effects and doesn't affect layout at all.
,
Sep 14
,
Sep 14
The identity transform is special cased, I presume, as no transform at all. Then the other transforms get drawn slightly differently though on a screen it's mostly obfuscated by sub-pixel text rendering. The printing code might be different because it would turn of sub-pixel text. This is not a printing bug, it's probably a layer positioning bug.
,
Sep 14
,
Today
(14 hours ago)
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by dtapu...@chromium.org
, Sep 12