search

Renato138 / pdfium

Automatically exported from code.google.com/p/pdfium
0 stars 0 forks source link

Chrome PDF Viewer: incorrect rendering of "narrow" text #7

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Original issue reported at 
https://code.google.com/p/chromium/issues/detail?id=321681

Original issue reported on code.google.com by hshi@chromium.org on 28 May 2014 at 6:00

Attachments:

GoogleCodeExporter commented 9 years ago 
Issue chromium:321681 has been merged into this issue.

Original comment by hshi@chromium.org on 28 May 2014 at 6:02

GoogleCodeExporter commented 9 years ago

Original comment by jam@chromium.org on 28 May 2014 at 6:03

GoogleCodeExporter commented 9 years ago 
This seems to be fixed in the latest pdfium

Original comment by bo...@foxitsoftware.com on 28 May 2014 at 11:28

GoogleCodeExporter commented 9 years ago 
re:#3 do you have a pdfium commit hash# for the fix? My build is at 
7dc5172decb2e2fa8885561ff473902f6e16c707 but the problem is still there.

Original comment by hshi@chromium.org on 28 May 2014 at 11:44

GoogleCodeExporter commented 9 years ago 
No I'm afraid it is still not fixed. I just tried to fetch origin/master 
(currently at 961a34a731955322370373dd977bc99009965a86) but the issue still 
persists.

Original comment by hshi@chromium.org on 28 May 2014 at 11:52

GoogleCodeExporter commented 9 years ago 
re:#4 it is 961a34a731955322370373dd977bc99009965a86, tested on windows and mac

Original comment by bo...@foxitsoftware.com on 28 May 2014 at 11:56

GoogleCodeExporter commented 9 years ago 
From offline discussion: the standalone pdfium_test binary built for Chrome OS 
daisy is indeed rendered correctly (attaching output in PPM format). However, 
the libpdf.so built at the same revision does not work when run as a built-in 
PDF viewer plugin on Chrome browser on Chrome OS and Linux.

Original comment by hshi@chromium.org on 29 May 2014 at 7:28

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by jun_f...@foxitsoftware.com on 2 Jun 2014 at 11:05

GoogleCodeExporter commented 9 years ago 
The root cause of this issue is that the font information is designed in 
pdfium_engine.cc and passed into PDF SDK by calling FPDF_SetSystemFontInfo in 
plugin&Linux mode. PDF SDK will use this information and its font mapping 
method to find a font to render text. For standalone mode, PDF SDK has its font 
information and mapping implementation which is different with the provided one 
in plugin mode. So we can find that two fonts are used when PDF SDK works in 
two modes.

Original comment by jun_f...@foxitsoftware.com on 6 Jun 2014 at 12:00

GoogleCodeExporter commented 9 years ago 
How is the font rendering on Windows?

For Linux, it likely comes down to font matching on the Chrome side, since the 
PDF viewer is sandboxed and can only ask for fonts and accept what the browser 
replies with. I'll take a look shortly.

Original comment by thestig@chromium.org on 9 Jun 2014 at 11:00

GoogleCodeExporter commented 9 years ago 
Here's an interesting comparison. On Linux, Okular uses DejaVuSans-Bold.ttf for 
Custom-Metrics-1 and uses DejaVuSans.ttf for Custom-Metrics-2. The PDF renders 
fairly close to the "correct" rendering. With the PDF plugin on Linux, if I do 
the same font substitutions, the rendering comes out wrong. Can you tell me why 
that is?

Currently, both Custom-Metrics-1 and Custom-Metrics-2 maps to DejaVuSans.ttf, 
but https://codereview.chromium.org/326823002 will take the weight into account 
and map Custom-Metrics-1 to DejaVuSans-Bold.ttf.

Original comment by thestig@chromium.org on 10 Jun 2014 at 12:48

GoogleCodeExporter commented 9 years ago 
How can I know Okular uses DejaVuSans-Bold.ttf for Custom-Metrics-1? I want to 
double check it. Currently, we find the glyph defined in the font data of 
DejaVuSans is too wide to show correctly. It causes two glyph to be overlapped. 
I pasted some debug information as below:

DejaVuSans
        glyph position     width      
glyph.m_OriginX1 = 208,        8
glyph.m_OriginX2 = 213,        6
glyph.m_OriginX3 = 218,        7
glyph.m_OriginX4 = 223,        10
glyph.m_OriginX5 = 230,        4

Arial
        glyph position     width  
glyph.m_OriginX1 = 208,        5
glyph.m_OriginX2 = 213,        5
glyph.m_OriginX3 = 218,        5
glyph.m_OriginX4 = 223,        7
glyph.m_OriginX5 = 230,        4

In order to avoid overlapping, the relationship between glyph position and 
glyph width should be:

The next position >= the current position + the current glyph's width

Original comment by jun_f...@foxitsoftware.com on 12 Jun 2014 at 5:51

GoogleCodeExporter commented 9 years ago 
For the examples in #12, we find Arial can be shown correctly. If the font is 
mapped to Dejavu Sans, there is glyph overlapping. From the result of font 
rendering, we can also find that each char's position in the font of Dejavu 
Sans is fixed and the same as the 'correct' but the size of chars are much 
bigger than 'correct' ones.

Original comment by jun_f...@foxitsoftware.com on 12 Jun 2014 at 6:04

GoogleCodeExporter commented 9 years ago 
Seems that this issue is still existing. I leave it to Lei to investigate from 
chrome side.

Original comment by jun_f...@foxitsoftware.com on 23 Jul 2014 at 10:09

GoogleCodeExporter commented 9 years ago 
I missed comment 12 - In Okular, open Policy.pdf and go to File -> Properties 
-> Fonts.

Original comment by thestig@chromium.org on 2 Aug 2014 at 2:02

GoogleCodeExporter commented 9 years ago 
I'm not sure what else I can do on the Chrome side. For Custom-Metrics-1 and 
Custom-Metrics-2, on my machine they return 
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf and 
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf, respectively. Just like in 
Okular. Should I be matching another font?

Original comment by thestig@chromium.org on 2 Aug 2014 at 3:50

GoogleCodeExporter commented 9 years ago 
I am currently using Chrome Version 38.0.2125.111 (64-bit) running on openSUSE 
Linux 13.1.

If anything, the font rendering problem seems to have worsened over the last 
several months, with pages rendering with fonts severely squeezed together 
becoming an ever more frequent problem.

Are there any plans to release a fix for Chrome Browser?  NB: If this has been 
fixed for Chrome Browser on other platforms (e.g., Windows or OS X), will the 
fix be migrated to Linux?

Thank you for any update.

Original comment by ChayaGra...@gmail.com on 30 Oct 2014 at 5:02

Attachments:

GoogleCodeExporter commented 9 years ago 
Many PDF documents just really look real crappy. This with Google Chrome 
version 41.0.2272.89 (64-bit) on Fedora 20. Attached screen shot e.g. shows the 
following document:

http://developer.download.nvidia.com/embedded/jetson/TK1/docs/602-7R375-0000-D00
.Schematics.Rev.4.02.pdf

Original comment by ziswi...@gmail.com on 18 Mar 2015 at 8:54

Attachments:

GoogleCodeExporter commented 9 years ago 
If it helps, this seems to be fairly common with LaTeX-generated PDFs using 
narrower than usual fonts. One example of such a document can be found under 
the following link and is attached as well
> 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.2342&rep=rep1&type=p
df

The affected files render correctly in libpoppler-based viewers (I tested 
version 0.26). I am running the Chrome stable channel on Debian sid, currently 
using Chrome Version 41.0.2272.101 (64-bit).

Original comment by l.huebsc...@gmail.com on 30 Mar 2015 at 11:35

Attachments: