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

Issue 655828 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

pdf with japanese font not rendering correctly

Project Member Reported by bmcquade@chromium.org, Oct 13 2016

Issue description

This was shared w/ me by a coworker. I've attached the 'bad' example, which is rendered in chrome, and the 'good' example, which is rendered in mac preview.

The PDF itself contains some personal content so I unfortunately can't share the original PDF here.
 
good_pdf.png
107 KB View Download
bad_pdf.png
74.6 KB View Download
Cc: npm@chromium.org
Can the original PDF be shared via Drive to whoever takes this bug? Without a PDF, it may be very hard to fix the problem.

Is bad_pdf.png rendered on Mac as well?
Labels: Needs-Feedback

Comment 3 by doantam@google.com, Oct 19 2016

I've shared a page from the PDF directly with dsinclair@ (which doesn't seem to have any personal info)
Labels: -Needs-Feedback
Cc: -npm@chromium.org
Owner: npm@chromium.org
Status: Assigned (was: Untriaged)
Can the doc be shared with npm@ as they are the PDFium font expert.

Comment 6 by doantam@google.com, Oct 20 2016

Done!

Comment 7 by npm@chromium.org, Oct 26 2016

The PDF does not embed fonts. The problems are:
* Character spacing is off when we use substitute font (known problem)
* The PDF describes a font F1 and then describes another font F2 which is exactly the same, except adding ",Bold" to the name. Other PDF viewers seem to not care about the fact that Bold is on the name, but we just use bold based on the name alone. I'm not sure what's better in general. But in this particular case it does look worse when we bold, simply because it adds to the clutter.

Comment 8 by npm@chromium.org, Jun 21 2017

The overlapping issue has been fixed [1], but not the boldness issue. I think we should fix the boldness issue to match other PDF viewers.

[1] https://pdfium-review.googlesource.com/c/6630/

Comment 9 by npm@chromium.org, Jun 21 2017

Cc: npm@chromium.org
Owner: ----
Status: Available (was: Assigned)
Hmm actually never mind, I had a different file with the same name on my Mac. Looking at the original file, we are similar to Adobe. The ",Bold" seems to be a legitimate way to say that a TrueType font is bold, according to the spec. Preview just ignores it and happens to achieve a superior rendering in this case (due to the fact that the non-bold and bold fonts have the same widths, which is a mistake in the PDF).

We can still improve the bold Japanese characters: you need to zoom a lot to read some of them (the thin lines seem to merge into an unintelligible glyph). I'm not a good owner for that, though.
Project Member

Comment 10 by sheriffbot@chromium.org, Jun 22 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Owner: npm@chromium.org
Status: Assigned (was: Untriaged)
Nicolas, do you think we can just close this?

I don't think we have a way to tell if a font is unreadable in bold, so that the we know to ignore the style. We could ignore bold for all japanese/chinese characters, but that would break the rendering of the fonts that do work.

Comment 12 by npm@chromium.org, Jun 22 2018

Status: WontFix (was: Assigned)
Yea I'm not sure there's any way to fix this properly without breaking the spec and potentially regressing other documents.

Sign in to add a comment