Bug 1451795 - [freetype] shows empty windows after opening font file clR9x15.pcf
Summary: [freetype] shows empty windows after opening font file clR9x15.pcf
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: freetype
Version: 25
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Kašík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-17 14:28 UTC by Joachim Frieben
Modified: 2017-06-09 19:11 UTC (History)
6 users (show)

Fixed In Version: freetype-2.6.5-9.fc25 freetype-2.7.1-8.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-28 06:00:54 UTC


Attachments (Terms of Use)
Sample font file clR9x15.pcf (11.83 KB, application/x-font-pcf)
2017-05-17 14:28 UTC, Joachim Frieben
no flags Details
Alternate font file clR9x15.pcf displayed correctly (11.82 KB, application/x-font-pcf)
2017-05-17 14:30 UTC, Joachim Frieben
no flags Details


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 768886 None None None 2017-05-22 04:36:32 UTC

Description Joachim Frieben 2017-05-17 14:28:08 UTC
Created attachment 1279709 [details]
Sample font file clR9x15.pcf

Description of problem:
Using gnome-font-viewer-3.22.0-1.fc25 of current Fedora 25, various fonts are merely shown as a white window, e.g. clR9x15.pcf.

Version-Release number of selected component (if applicable):
gnome-font-viewer-3.22.0-1.fc25

How reproducible:
Always

Steps to Reproduce:
1. Install package xorg-x11-fonts-misc.
2. Open font file clR9x15.pcf in gnome-font-viewer.

Actual results:
gnome-font-viewer displays a white window.

Expected results:
gnome-font-viewer displays the chosen font set.

Additional info:
- After opening /usr/share/X11/fonts/misc in "Files", a fair number of fonts are merely represented by empty thumbnails.
- Issue also applies to TTF font file symbol.ttf.

Comment 1 Joachim Frieben 2017-05-17 14:30:15 UTC
Created attachment 1279712 [details]
Alternate font file clR9x15.pcf displayed correctly

Alternate font file clR9x15.pcf displayed correctly

Alternate version of clR9x15.pcf retrieved from https://github.com/rdebath/SLS-1.02/blob/master/usr/X386/lib/X11/fonts/misc/clR9x15.pcf displayed correctly.

Comment 2 Joachim Frieben 2017-05-17 14:34:38 UTC
For the Fedora font file clR9x15.pcf, command 'file clR9x15.pcf' returns
  "X11 Portable Compiled Font data".
For the alternate font file clR9x15.pcf command 'file clR9x15.pcf' returns
  "X11 Portable Compiled Font data, LSB first".

Comment 3 Joachim Frieben 2017-05-22 04:36:32 UTC
According to https://bugzilla.gnome.org/show_bug.cgi?id=768886#c3, this problem is not related to gnome-font-viewer but rather to freetype.
Moreover, font file clR9x15.pcf can be used without issue in X applications like xterm or xfontsel.

Comment 4 Joachim Frieben 2017-05-22 04:54:09 UTC
Issue also affects Fedora 26 including package freetype-2.7.1-6.fc26.

Comment 5 Marek Kašík 2017-05-22 15:41:03 UTC
The problem with the font is that the encoding there is not unicode encoding and hence its charmap stays undefined in FTFace.
Freetype recognizes just ISO10646 and ISO8859-1 here.
I'll look whether this is correct tomorrow.

Comment 6 Joachim Frieben 2017-05-23 06:28:12 UTC
Font properties returned by xlsfonts:
DIR  MIN  MAX EXIST DFLT PROP ASC DESC NAME
-->    0  127   all    0   21  12    3 -schumacher-clean-medium-r-normal--15-150-75-75-c-90-iso646.1991-irv

Comment 7 Marek Kašík 2017-05-24 11:45:13 UTC
Since the ISO646.1991-IRV charmap is ASCII, I've asked freetype's upstream to add it to the set of recognized Unicode charmaps. Werner added it today in this commit: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=082f2faf5007812bac6a1f783c7dcc6f49d761fe.

The other fonts with other charmaps needs to be handled on the glyph base in the application since freetype recognizes Unicode charmaps (FT_ENCODING_UNICODE) and others (FT_ENCODING_NONE) only in the PCF (and BDF) driver.

Comment 8 Fedora Update System 2017-05-24 11:47:52 UTC
freetype-2.6.5-9.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f35e321a3b

Comment 9 Fedora Update System 2017-05-24 11:47:58 UTC
freetype-2.7.1-8.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9956dd8d80

Comment 10 Fedora Update System 2017-05-25 19:21:12 UTC
freetype-2.7.1-8.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9956dd8d80

Comment 11 Fedora Update System 2017-05-26 06:02:51 UTC
freetype-2.6.5-9.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f35e321a3b

Comment 12 Joachim Frieben 2017-05-26 19:40:08 UTC
Further inspection has revealed that a fair number of X fonts has the same problem, for instance the DEC terminal font which is of encoding type "dec". Launching 'xfontsel' and browsing through the encoding list exhibits a number of encodings which are not yet considered either.
 However, there are even non-X fonts like /usr/share/fonts/sil-padauk/Padauk-Bold.ttf which are not displayed by gnome-font-viewer (the regular font variant displays just fine).

Comment 13 Fedora Update System 2017-05-28 06:00:54 UTC
freetype-2.6.5-9.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2017-06-09 19:11:06 UTC
freetype-2.7.1-8.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.