Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1059758

Summary: Cannot display attached PDF properly
Product: Red Hat Enterprise Linux 7 Reporter: Matěj Cepl <mcepl>
Component: popplerAssignee: Marek Kašík <mkasik>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: dapospis, fche, mcepl, vhumpa
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-05-15 11:33:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
filter returned fonts by type none

Description Matěj Cepl 2014-01-30 15:10:31 UTC
Created attachment 857530 [details]
test case

Description of problem:
When opening the attached PDF in Evince I got very corrupted image (see attached for both evince’s and Windows Sumatra PDF rendering).

Version-Release number of selected component (if applicable):
fontconfig-2.10.95-7.el7.x86_64
poppler-data-0.4.6-3.el7.noarch
ghostscript-9.07-16.el7.x86_64
poppler-0.22.5-4.el7.x86_64
evince-3.8.3-7.el7.x86_64
liberation-mono-fonts-1.07.2-14.el7.noarch
liberation-serif-fonts-1.07.2-14.el7.noarch
liberation-fonts-common-1.07.2-14.el7.noarch
liberation-sans-fonts-1.07.2-14.el7.noarch


How reproducible:
100% for the given set of PDFs (I have more of these)

Steps to Reproduce:
1.open the attached file in evince
2.
3.

Actual results:
corrupted rendering (see attached)

Expected results:
correct rendering (see attached)

Additional info:
When I run evince I get many error messages on stderr, repeating

    Syntax Error: Couldn't find a font for 'Arial'
    some font thing failed

Also when opening with ghostscript, I get same corrupted rendering and this on stderr/stdout:

    matej@wycliff: tmp$ gs la-plante.pdf
    GPL Ghostscript 9.07 (2013-02-14)
    Copyright (C) 2012 Artifex Software, Inc.  All rights reserved.
    This software comes with NO WARRANTY: see the file PUBLIC for details.
    Processing pages 1 through 1.
    Page 1
    Can't find (or can't open) font file /usr/share/ghostscript/9.07/Resource/Font/ArialMT.
    Can't find (or can't open) font file ArialMT.
    Can't find (or can't open) font file /usr/share/ghostscript/9.07/Resource/Font/ArialMT.
    Can't find (or can't open) font file ArialMT.
    Querying operating system for font files...
    Loading ArialMT font from /usr/share/fonts/msttcorefonts/arial.ttf... 3543464 2029673 8110044 6017515 3 done.
    Can't find CID font "Arial".
    Attempting to substitute CID font /Adobe-Identity for /Arial, see doc/Use.htm#CIDFontSubstitution.
    The substitute CID font "Adobe-Identity" is not provided either. attempting to use fallback CIDFont.See doc/Use.htm#CIDFontSubstitution.
    Loading a TT font from /usr/share/ghostscript/9.07/Resource/CIDFSubst/DroidSansFallback.ttf to emulate a CID font Adobe-Identity ... Done.
    Loading Arial-BoldMT font from /usr/share/fonts/msttcorefonts/arialbd.ttf... 7315352 5816372 8361732 6188585 3 done.
    Can't find CID font "Arial".
    Attempting to substitute CID font /Adobe-Identity for /Arial, see doc/Use.htm#CIDFontSubstitution.
    Can't find CID font "PalatinoLinotype".
    Attempting to substitute CID font /Adobe-Identity for /PalatinoLinotype, see doc/Use.htm#CIDFontSubstitution.
    >>showpage, press <return> to continue<<
    ^C
    matej@wycliff: tmp$ 

So, I guess there is some kind of misconfiguration in the font aliases
(note, that I have Liberation fonts installed). I guess the bug is in
fact somewhere deeper than in the evince component where I've filed this
bug report, but I am not sure where evince and ghostscript paths
connect. Please, reassign appropriately.

Comment 4 Marek Kašík 2014-02-03 16:57:02 UTC
Created attachment 858703 [details]
filter returned fonts by type

Hi,

there are 3 problems with the PDF.

The first one is that it requests non-embedded TrueType font Arial but fontconfig returns a Type1 font Nimbus Sans L. This can be fixed by filtering list returned by fontconfig for the requested font type but it will be rejected by upstream probably because Arial is alternative name for standard Type1 font Helvetica.

The second problem is that the PDF contain CIDToGIDMap entry for a non-embedded CIDFontType2 font (TrueType). This is forbidden in specification.

The third one is that the PDF contains "/Encoding /Identity-H" for the non-embedded font Arial. This causes mapping of the hexadecimal numbers of hexadecimally specified strings directly to glyphs in actual font. This would work only for fonts with the same glyph order as in the font with which was the PDF created.

The creator of the PDF could avoid these problems by embedding used fonts into the PDF.

The first problem can be considered a feature request but the other two are problems of the specific PDF.

So even if we implement the first feature (see attached patch) the rendering of the PDF will be corrupted.

Regards

Marek

Comment 6 RHEL Program Management 2014-03-22 06:07:35 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 11 Vitezslav Humpa 2015-05-13 09:54:38 UTC
GNOME 3.14 triage: still case with poppler-0.26.2-9.el7.x86_64, though as has been said, that is not really full issue of poppler. Matej, Marek, perhaps you should decide whether to go with RFE on the 1st problem or close this bug as wontfix.

Comment 12 Marek Kašík 2015-05-15 11:33:39 UTC
This is really a problem of the PDF. I'm closing this as WONTFIX since implementing of the proposed filtering could cause serious regression.