Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 1385069 [details] The eps file Description of problem: I recently upgraded to Fedora 27 and the upgrade was completed without any issues. I just noticed that when I try to view postscript files with gv, I get the following warnings: Warning: Missing charsets in String to FontSet conversion Warning: Cannot convert string "-efont-biwidth-medium-r-normal--16-*-*-*-*-*-iso10646-1,-gnu-unifont-medium-r-normal--16-*-*-*-*-*-iso10646-1,-adobe-helvetica-medium-r-normal--14-*-*-*-*-*-*-*,-jis-fixed-medium-r-*--16-*-*-*-*-*-jisx0208.1983-0,-*-*-medium-r-*--16-*-*-*-*-*-*-*,*" to type FontSet Warning: Missing charsets in String to FontSet conversion Warning: Unable to load any usable fontset Warning: Missing charsets in String to FontSet conversion Warning: Unable to load any usable fontset I did not have this problem in the previous version of Fedora. Ghostview appears but the Greek letters/symbols are not displayed. How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: I am attaching the eps file that I am trying to view using gv. The Expected results: Additional info:
test
The same here at Fedora 27. In my case gv only gives this message: Warning: Missing charsets in String to FontSet conversion I can also add that if I include the EPS figure in LaTeX, which creates PS that is then converted to PDF. The Greek and other special symbols as \times are also missing when thees documents are viewed with both Acrobatoreader, foxit or GV. In any case, however, Greek and other special symbols are correctly displayed in the text.
I finally found out that the version 20170801-4 of urw-base35-fonts causes the issue. Doing below solve my problem: sudo dnf downgrade urw-base35-fonts I am now in version 20170801-2
As far as I can tell, this has nothing to do with gv. Plain old 'gs' also fails to display some Greek characters, as do Okular and Evince. I can also confirm that downgrading urw-base35-fonts (and the other packages which get downgraded along with it) will fix the issue. Moving this over to urw-base35-fonts.
Created attachment 1395636 [details] Another eps file showing the problem Just to have another example, here's a small eps file which also shows the problem. The y axis should be labeled with an omicron, just to the left of the "-1". In the raw postscript, that symbol is inserted by the code around line 1581. This file was generated some time ago and has been displayed fine until recently. I will try to step through the various changes that happened between 20170801-2 and 20170801-4, but I suspect that dkaspar can find the issue far quicker than I can.
the downgrading worked for me
So I did go back through the various commits and found that the issue is caused by commit 5b9fc75 - specfile: ship the *.OTF format files as well. And from that, I started deleting otf font files. I found that deleting just the single file /usr/share/fonts/urw-base35/StandardSymbolsPS.otf fixed the specific issue of missing Greek characters for me. Unfortunately I know very little about the internals of fonts, so I can't say much more. However, when displaying that document with StandardSymbolsPS.otf in place, gs will log: Can't find (or can't open) font file /usr/share/ghostscript/9.22/Resource/Font/StandardSymbolsPS. Can't find (or can't open) font file StandardSymbolsPS. Loading StandardSymbolsPS font from /usr/share/fonts/urw-base35/StandardSymbolsPS.otf... 4365584 3020018 10208528 8757295 3 done. And when I delete that otf file, gs logs: Can't find (or can't open) font file /usr/share/ghostscript/9.22/Resource/Font/StandardSymbolsPS. Can't find (or can't open) font file StandardSymbolsPS. Loading StandardSymbolsPS font from /usr/share/fonts/urw-base35/StandardSymbolsPS.t1... 4426184 3078451 10131288 8665936 3 done. and it does display the missing characters. Running fc-query on the two font files shows that the t1 file has far more entries under "charset": charset: 0000: 00000000 ffffdb6b a8000000 38000000 00000000 00231001 00800000 00800000 0001: 00000000 00000000 00000000 00000000 00040000 00000000 00000000 00000000 0003: 00000000 00000000 00000000 00000000 fffe0000 fffe03fb 006603ff 00000000 0020: 00000000 000c0044 00000010 00000000 00000000 00001000 00000000 00000000 0021: 11020000 00200040 00000000 00000000 001f0000 00200000 001f0000 00000000 0022: 64a68bed 10100f81 00000120 00000033 00a000dc 00000020 00000020 00000000 0023: 00000000 00000603 00000000 00000000 00000000 00000000 00000000 00000000 0025: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 00000000 0026: 00000000 00000000 00000000 00000069 00000000 00000000 00000000 00000000 00f6: 00000000 00000000 00000000 00000000 00000000 00000000 0e000000 00000000 00f8: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffffffe0 versus this for the otf font: 0000: 00000000 ffffffff ffffffff 7fffffff 00000001 ffffffff ffffffff 7ffeffff But I have no idea if that actually means that the otf file is missing symbols. I'm pretty much at the end of my comprehension of fonts. Anyway, I'm going to do a local build without the otf files and push that out to my desktops.
And with that added info, it appears that this is really just a duplicate of bug 1534206. *** This bug has been marked as a duplicate of bug 1534206 ***
Hello guys, upstream has been already informed this more than a month ago. The last I've heard from them they were moving to a new building... I've pinged them again today. Anyway, if you're facing this issue, a workaround for now is to delete the *.otf version of Standard Symbols PS: > sudo rm -f /usr/share/fonts/urw-base35/StandardSymbolsPS.otf The Ghostscript itself was updated in Rawhide (F28) to do a lookup for *.t1 versions first, but I can't backport these changes into F27. It could break a lot of things. So for now we have to wait for upstream to respond. Best regards, -- Dee'Kej --