The summary says it all. Without it, Xtf loading of the font in the xfig application fails (which is disastrous in a tool intended to draw scientific figures with greek text in them). Restoring the file from the github source and xfig magically works perfectly again. Please put it back. A simple directory listing of the /usre/share/fonts/urw-base35 directory shows that it is pretty much the only font with an .afm and .t1 descriptor but no binary font file. Reproducible: Always Steps to Reproduce: 1. Install xfig 2. Select T(ext) and the Symbol font 3. Type "abcde..." It should produce alpha beta chi delta... etc. on screen Actual Results: Produces nothing Expected Results: Produce correctly scaled, movable, rotatable text images of alpha, beta etc. Putting the otf file in the right place xfig works perfectly as expected.
By the way, this fix will need to be back-ported to at least F38, maybe F37 as well as forward to e.g. 40+. The conversion of xfig to use Xft is fairly recent, but the fonts worked as of F36 for sure. Don't know when the OTF file was dropped.
Hi, thank you for reporting the issue! Your report looks like a duplicate of #1963136 - I've tried to verified if the situation changed. .otf file in source tarball and in upstream are the same file, so there is no fix for the original issue. The .otf file was removed because of issue https://bugzilla.redhat.com/show_bug.cgi?id=1534206 - part of the issue is still present (the artificial example still gives zero if .otf file is installed), but evince shows correct symbols regardless whether the .otf is installed or not. Based on strace, it loads .t1 version of the font. I've run xfig on Fedora 40 and Fedora 39 - both load /usr/share/fonts/urw-base35/StandardSymbolsPS.t1 , but xfig on F40 shows the letters correctly, but xfig on F39 does not. Based on this fact (urw-base35-fonts didn't add the requested .otf file or changed at all, and xfig behaves differently in two versions) I switch this to xfig for further investigation - some package under xfig probably caused this, and IMO xfig maintainer has more knowledge to find it out which one. It would be great if other possibilities were explored (since F40 works fine) in case adding the file would break something again. I'll CC the original issue's reporter as well for future confirmation.
Created attachment 2020479 [details] RPMs with Standard symbols PS otf included
Matthias, would you mind verifying whether the attached rpms break something for you in the present? I've tried old reproducers from https://bugzilla.redhat.com/show_bug.cgi?id=1534206 and the artificial code still shows zeroes, but evince shows the correct greek symbols when I open greek.ps.
For what it is worth, I installed these fonts on my Fedora 39 system and tested both xfig and evince (I have LOTS of source and output files for xfig, eps, pdf with greek characters in them:-) and everything I tried worked. /usr/share/fonts/urw-fonts/StandardSymbolsPS.otf was present. As I noted above, while trying to debug xfig (with a lot of output statements inserted into the font handling code to try to figure out where things were going wrong) without the otf file, with it missing xfig takes a strange and apparently broken path that attempts to pad out characters and thereby avoids the Xft path all the other fonts (including ZapfDingbats, which apparently once had similar issues and has a similar hack-job fix in xfig) now take. With the OTF, it loads the font with the standard UTF8 handler it uses for all the rest. So I echo Zdenek -- it seems to work in F39. I'll try it in F38 in a minute (I have an F38 laptop I haven't upgraded, and even have one sitting idle with F36 on it awaiting upgrade to current, but I won't be able to get to it until the weekend).
For the possible future usage, the fix lies at https://src.fedoraproject.org/fork/zdohnal/rpms/urw-base35-fonts/c/ec2c7c5fcf153bfa6f0f5f2dfa47676c7d47bb58?branch=bz2268363 .
I installed the font rpms including the OTF file on my F38 system and built the 3.2.9-4 rpm by hand as I'm already familiar with at least some of how it handles fonts. I discovered that on that system, at least, the urw symbol font was being rejected in favor of: /etc/fonts/conf.d/58-google-noto-sans-symbols-vf.conf@ /etc/fonts/conf.d/58-google-noto-sans-symbols2.conf@ I moved these links out of /etc/fonts/conf.d (I don't know how to alter the font search path to prevent them from being chosen first, sorry, removing them entirely may have side effects) and 3.2.9-4 worked perfectly. So did the current F38 xfig rpm version out of the box. So did evince. Without doing this, xfig just printed noto sans letters -- not even symbols. Not sure what is going on there. In any event, I'll have to pass this on at this point as I have to do some other work for a few days and I have the stock xfig and stock evince RPM working stably on both my primary production systems, with the fix above on the F38 system only and the OTF file installed on both systems via the RPMs above. I don't even know how to begin to fix a font path or font conflict problem other than by turning off one of the two fonts by removing them from /etc/fonts/conf.d, and I don't know how to patch xfig to force it to use the urw symbol set when noto-sans symbols are available. One or the other of these fixes is probably pretty simple, though. One wonders how much of the problem has been from this sort of shadowing all along, but I don't have the time any more to permute things to figure it out, sorry;-)
I had a final free moment and figured out a bit about font ordering. Here's the remaining problem in e.g. F38. In F38, /etc/fonts/conf.d/58-google-noto-sans-symbols2.conf contains: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd"> <fontconfig> <match> <test name="family"> <string>fantasy</string> </test> <edit name="family" mode="prepend"> <string>Noto Sans Symbols2</string> </edit> </match> <alias> <family>Noto Sans Symbols2</family> <default> <family>fantasy</family> </default> </alias> </fontconfig> which matches only string "fantasy". In the F38 file, it contains: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd"> <fontconfig> <match> <test name="family"> <string>fantasy</string> </test> <edit name="family" mode="prepend"> <string>Noto Sans Symbols2</string> </edit> </match> <alias> <family>Noto Sans Symbols2</family> <default> <family>fantasy</family> </default> </alias> <match> <test name="family"> <string>Symbol</string> </test> <edit name="family" mode="prepend" binding="same"> <string>Noto Sans Symbols2</string> </edit> <edit name="fonthashint" mode="append"> <bool>false</bool> </edit> </match> <alias> <family>Noto Sans Symbols2</family> <default> <family>Symbol</family> </default> </alias> </fontconfig> which matches SYMBOL as well as fantasy. Since 58 < 61 (the number of the regular PS symbol config file, I think -- not being anything like an expert -- that it resolves by using the noto-sans font first if symbol is requested. There is probably some way of avoiding this in Xft (so it is legitimately a bug, perhaps, in xfig) but a simple ENOUGH solution is to simply backport the F39 58-google-noto-sans-symbols2.conf to F37 and/or F38's RPM set. I'm going to give this a try on my F38 system in a moment just to avoid any side effects of completely (transiently) removing the 58 noto-sans-symbols2 conf file.
It works (copying back from 59). At least, xfig/evince still work. Hopefully anything needing the fantasy symbol font as well.
@rgb Thank you for all investigation and work! So do I understand correctly, if the conf file from F39 is used, the .otf font file is not needed? Because I saw the issue on F39 as well, F40 worked for me without .otf.
No, the fix is twofold, but varies depending on release. On F38, you have to use the conf file from F39 AND add the OTF file. On 39, only the OTF file is needed. I haven't upgraded to F40 yet, so I don't know what is going on then, but while xfig MAY have worked for X40 without the OTF file, it probably did so via the symbol-font-specific patch in u_fonts.c in the xfig sources, which is basically a workaround. I may install/upgrade my third laptop to F40 this week; if so I'll obviously be testing all of this if the fixes have made it into the mainstream releases by then or as soon as something breaks otherwise. Background: All of the other fonts in /usr/share/fonts/urw_base35 have three files associated with the font: font.afm, font.otf and font.t1. Except (in the last few Fedora releases) StandardSymbolPS. Even the Dingbats font, now named D050000L, is there with all three files. AFM are "font metric" font descriptions for Type 1 fonts. T1 is (if I understand it correctly) the actual PS type 1 font. OTF files are "OpenType Postscript" fonts, designed to be portable where Apple and Microsoft actually used incompatible PS font sets, obviously creating problems, and dropping the OTF file from the font set was and remains almost certainly a bug, or a broken fix to a bug somewhere else that breaks other things just as badly. OTFs are preferred because of the "open" and "portable" bit, and I'm guessing that the Xft developers have spent more time ensuring that OTFs are resolved correctly, scale, rotate, etc portably. In any event, all of the other fonts used by xfig are loaded as OTFs, which seems to be the default choice if available. However, the way font configuration resolves conflicts when two fonts have the same name or provide the same alias is still a bit of a mess, because there are SO many fonts out there. /etc/fonts/conf.d is the user/root controllable part of it (where a user can install their own personal override, if they know what they are doing and don't mind hacking xml files to get there). The better solution in the long run -- IMO -- is to ensure that font names don't collide, at least where the issue isn't one of preferring one rendering of e.g. courier over another where both actually work. With xfig, of course, the application assumes that "Symbol" is THE postscript symbol font and the Google fonts are not actually compatible. The F39 conf file seems to just remove the section that allows Xft to identify the Google NotoSans ttf "symbol2" font as an alias for symbol (where TTF is similar to OTF -- the original rendering of the portable type 1 font that supposedly was portable across Apple and Microsoft especially with regard to printers).
(In reply to Zdenek Dohnal from comment #4) > Matthias, > > would you mind verifying whether the attached rpms break something for you > in the present? > > I've tried old reproducers from > https://bugzilla.redhat.com/show_bug.cgi?id=1534206 and the artificial code > still shows zeroes, but evince shows the correct greek symbols when I open > greek.ps. I can confirm that the greek.ps file is displayed correctly in evince with the .otf version installed, which used to not be the case. If I run ps2pdf to create greek.pdf, this file is not displayed correctly in evince without the .otf version installed, but is displayed correctly with the .otf version installed. So Here including the .otf version would be an improvement. However, running the greekletters.C in root to create the greek.ps created a broken postscript file with the .otf version installed, but creates a correct file without it installed. This is because the cmap data in the files differ. The .t1 version has the following platform/encoding cmaps: Platform: 3 Encoding: 1 -- unicode mapping (alpha is 0x03b1) Platform: 7 Encoding: 2 -- legacy mapping (alpha is 0x61) This are the same tables as the old urw symbol font (s050000l.pfb) had. The .otf version has the followin3 platform/encoding cmaps: Platform: 0 Encoding: 3 -- legacy mapping (alpha is 0x61) Platform: 3 Encoding: 1 -- also legacy mapping (alpha is 0x61) -- which is wrong since 3/1 is supposed to be unicode Platform: 7 Encoding: 2 -- this one seems broken, both 0x61 and 0x03b1 returns 0, so not clear how to write alpha with this one It is possible the get root to work with the .otf vesion, but it requires to patch to the code to use platform/encoding 0/3 if it exists with higher priority than 7/2 and rebuilding the package. Given that including the .otf version solves other issues making this change seems reasonable.
(In reply to Mattias Ellert from comment #12) > It is possible the get root to work with the .otf vesion, but it requires to > patch to the code to use platform/encoding 0/3 if it exists with higher > priority than 7/2 and rebuilding the package. Given that including the .otf > version solves other issues making this change seems reasonable. I have updated root accordingly (root 6.30.04-2). Adding the .otf version of StandardSymbolsPS to the font package will now not break root.
Shouldn't this bug be reassigned back to urw-base35-fonts? So that the .otf version can be put back into the font package.
Thank you for checking and making changes, Mattias! I'll put the file back into urw-base35-fonts.
FEDORA-2024-abfe646054 (urw-base35-fonts-20200910-20.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-abfe646054
FEDORA-2024-7ef68e43d5 (urw-base35-fonts-20200910-20.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-7ef68e43d5
FEDORA-2024-a7a8f8f01b (urw-base35-fonts-20200910-20.fc38) has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2024-a7a8f8f01b
FEDORA-2024-7ef68e43d5 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-7ef68e43d5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-7ef68e43d5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-abfe646054 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-abfe646054` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-abfe646054 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-a7a8f8f01b has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-a7a8f8f01b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-a7a8f8f01b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FWIW, I just tested the F39 update, and it works fine. It replaced the StandardSympolPS.otf I had installed by hand and works flawlessly in xfig AFAICT so far.
FEDORA-2024-abfe646054 (urw-base35-fonts-20200910-20.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-7ef68e43d5 (urw-base35-fonts-20200910-20.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-a7a8f8f01b (urw-base35-fonts-20200910-20.fc38) has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.