xfig doesn't render properly the postscript greek fonts in the GUI even after installing additional fonts like dnf install google-noto-sans-symbols* dnf install texlive-noto* dnf install urw-base35-standard-symbols-ps-fonts.noarch to test , start xfig , select Text input in the left menu , change text font to Symbol, add some text , there is no greek letter a rebuild of the rpm from https://dl.fedoraproject.org/pub/epel/9/Everything/source/tree/Packages/x/xfig-3.2.8b-4.el9.src.rpm and a downgrade to the xfig-3.2.8b-4 version on fedora 39 and fedora 37 (tested versions with the xfig-3.2.9-1.fc39.x86_64 and xfig-3.2.9-1.fc37.x86_64) solve the problem , am i the only one or should we downgrade the version ? Reproducible: Always Steps to Reproduce: 1.start xfig 2.select Text input in the left menu 3.change text font to Symbol 4.add some text Actual Results: there is no greek letter Expected Results: should show the text with the proper font a rebuild of the rpm from https://dl.fedoraproject.org/pub/epel/9/Everything/source/tree/Packages/x/xfig-3.2.8b-4.el9.src.rpm and a downgrade to the xfig-3.2.8b-4 version on fedora 39 and fedora 37 (tested versions with the xfig-3.2.9-1.fc39.x86_64 and xfig-3.2.9-1.fc37.x86_64) solve the problem
I encountered this problem in both an upgrade to 38 and a full install of 39 on the old thread where this sort of issue was originally resolved (with fonts, at that time). Downgrading was recommended to test if it fixes the problem and as data for re-fixing the problem. Here are the results: Both: sudo rpm -Uvh --oldpackage xfig-3.2.8b-4.fc38.x86_64.rpm sudo rpm -Uvh --oldpackage xfig-3.2.8b-5.fc39.x86_64.rpm work correctly (both in xfig and evince/eps) in 38 and 39 respectively. This will hold me for the time being -- xfig doesn't exactly move quickly. I'll repost this to the other (this!) bug report. Thanks so much! rgb
For people who also want to downgrade for now, you can download the old rpms here: F38: https://koji.fedoraproject.org/koji/buildinfo?buildID=2134823 F39: https://koji.fedoraproject.org/koji/buildinfo?buildID=2258365 Since this seems to be introduced by the new upstream release and since I unfortunately have very little time to work on this, can someone please report this to xfig upstream ? : https://sourceforge.net/p/mcj/tickets/
Done (reporting it on sourceforge) Hans. It's already there, of course. Reading the thread, It looks to me like the real problem is a build problem, maybe not a source problem. They keep tweaking gcc and the build tools and standard of practice build rules, and half the battle now is getting a source package to build on red hat AND fedora AND Debian AND Ubunto AND every-single-maverick-distro-out-there. They don't all enforce the same build rules and library/include paths, so fixing it so it will build on neo-Slackware might end up subtly breaking it on Fedora. If you install the downgrade fix suggested by Hans while waiting for a fix in the meantime, be sure to edit /etc/dnf/dnf.conf as follows: # see `man dnf.conf` for defaults and possible options [main] gpgcheck=True installonly_limit=3 clean_requirements_on_remove=True best=False skip_if_unavailable=True ## Exclude following Packages Updates ## exclude=xfig (Basically, add the final two lines -- in principle they protect the downgrade from being upgraded the next time you or the system run dnf update.) You'll likely want to pay attention and periodically retry it, although if/whe upstream DOES fix it, if I discover it/test it and it works I'll certainly repost to this thread, so if you're on the recipient list you'll hear about it and can remove/comment out the line.
> It's already there, of course. Ah, I missed that sorry. Thank you for pointing this out. > Reading the thread, It looks to me like the real problem is a build problem, maybe not a source problem. There actually is a real new bug in xfig 3.2.9 causing this and there is a fix linked from the upstream issue: https://sourceforge.net/p/mcj/tickets/159/ https://sourceforge.net/p/mcj/xfig/ci/1e2d842875502b4ce0e74ec779454304c71efe54/ The discussion is about some new compiler warning with some compiler versions after applying the fix. But the fix itself is good and has already been applied by upstream. I'm preparing a fixed Fedora pkg with the fix now. Please let me know if this fixes things for you (once available).
FEDORA-2024-5eec074a18 (xfig-3.2.9-4.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-5eec074a18
FEDORA-2024-6ea6db37c5 (xfig-3.2.9-4.fc38) has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2024-6ea6db37c5
FEDORA-2024-8ea8def54e (xfig-3.2.9-4.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-8ea8def54e
FEDORA-2024-3e9ab1faa6 (xfig-3.2.9-4.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-3e9ab1faa6
FEDORA-2024-5eec074a18 (xfig-3.2.9-4.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-3e9ab1faa6 (xfig-3.2.9-4.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-8ea8def54e 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-8ea8def54e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-8ea8def54e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-6ea6db37c5 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-6ea6db37c5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6ea6db37c5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
rgbatduke, I saw your comment on the update that it does not fix things, that is unfortunate. Can you maybe share a xfig file (or create a simple example xfig file) which demonstrates the problem? Then I'll try to reproduce the issue and we can see from there.
Created attachment 2019420 [details] xfig source file to demonstrate symbol font bug.
Sure, no problem. Just open xfig, select T(ext), click a point on the drawing window and type in abcdef. It will render nicely in the default font. Click "Edit", select the text, change the font to "Symbol", apply, and poof! It will disappear. Not only disappear, but it seems now to have almost zero dimensions -- if you exit Edit and try to move or delete the (now invisible, but still there) string, you have to hit AFAICT a single pixel. Interestingly, Wingdings (which I basically never use but which was reported as being a problem earlier) now DOES work. It could be that Symbol works, but that the characters are being treated as if they have zero height and width, making them vanish. They still (fortunately) still appear correctly rendered when exported to e.g. eps or pdf or even a bitmap like jpg. So the bug seems confined to a single font, in the primary working window. I'm copying in an xfig file below, although I did try to attach it to the thread below. Mouse-save the following into test.fig or whatever, and current xfigs won't show the second line. #FIG 3.2 Produced by xfig version 3.2.8b Landscape Center Metric A4 100.00 Single -2 1200 2 4 0 0 50 -1 0 24 0.0000 4 270 1095 1620 2565 abcdef\001 4 0 0 50 -1 32 24 0.0000 4 390 1290 1620 3015 abcdef\001 4 0 0 50 -1 34 24 0.0000 4 315 1770 1620 3555 abcdef\001
Created attachment 2019421 [details] Trying again with symbol-wingding.fig
FEDORA-2024-8ea8def54e (xfig-3.2.9-4.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-6ea6db37c5 (xfig-3.2.9-4.fc38) has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
Created attachment 2020402 [details] Screenshot of continuing problem... The latest test fix still does not work, although something (finally) changed -- with the lastest try released for 39 (see below, JUST tested) the symbol font now actually produces a couple of characters. Sadly, they aren't the right characters and most of the ones typed come in blank/zero dimensional (the plus/minus mu in the screenshot should be \alpha\beta\chi\delta\epsilon\phi in place of abcdef). rgb@lakshmi|B:1045>xfig -v Xfig 3.2.8b still works perfectly under 39. The following traces my steps. I just updated xfig to get the current version in 39: rgb@lakshmi|B:1005#dnf install xfig Last metadata expiration check: 2:30:34 ago on Wed Mar 6 12:39:07 2024. Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Installing: xfig x86_64 3.2.9-4.fc39 updates 5.9 M Transaction Summary ================================================================================ Install 1 Package Total download size: 5.9 M Installed size: 14 M Is this ok [y/N]: y Downloading Packages: xfig-3.2.9-4.fc39.x86_64.rpm 7.0 MB/s | 5.9 MB 00:00 -------------------------------------------------------------------------------- Total 6.2 MB/s | 5.9 MB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : xfig-3.2.9-4.fc39.x86_64 1/1 Running scriptlet: xfig-3.2.9-4.fc39.x86_64 1/1 Verifying : xfig-3.2.9-4.fc39.x86_64 1/1 Installed: xfig-3.2.9-4.fc39.x86_64 Complete! rgb@lakshmi|B:1044>xfig dummy.fig rgb@lakshmi|B:1044>xfig -v Xfig 3.2.9 AND it doesn't work, producing the screenshot attached.
Just in case interested parties, especially Hans, on this thread aren't following the latest developments on the font thread, you may want to visit here: Red Hat Bugzilla – Bug 2268363 to get my latest comments. In a nutshell, I've solved the problem. xfig was failing for two reasons -- one is that a key font file (/usr/share/fonts/urw-base35/StandardSymbolsPS.otf) was for some reason missing from the standard urw-base35 font rpms, so Xtf could not locate it and use it. Adding the file back "instantly" fixed F39 to work for xfig 3.2.9-4. However, on F38 it still failed. The reason there turned out to be that the Google Noto-Sans symbol fonts were being given precedence over the StandardSymbolsPS font in urw via a spurious entry in /etc/fonts/conf.d/58* (rulesets for resolving conflicts and determining precedence) so letters appeared but were not greek. Removing the spurious entry -- which happened between F38 and F39 anyway -- again resolved the problem so that F38's xfig 3.2.9-4 works fine as well. I can't test F37, and it still works on my one remaining F36 system (which I'm about to upgrade). Once the font situation is stably resolved, the weird section in xfig's u_fonts.c at the end that pads out symbol and dingbat fonts can probably go way. If the correct *.otf files are installed in /usr/share/fonts/urw-base35, the specialized code that tries to make the old fonts "work" although they weren't UTF8 compliant is not reached -- Xft picks the UTF8 fonts out correctly and completely skips both of the conditionals tested for in the remapping routine. Took me a while and much decoration with inline output statements to figure this out, but it finally makes sense. I'm actually moderately impressed with Xft. Fonts have been a complete PITA in linux forever, and it looks like this one API may finally both provide the patchwork so legacy apps will run AND provide a simple upwardly mobile path to doing the fonts right -- that is, scalably, rotatably, with accelerated graphics even as needed. Very cool.
rgb@phy thank you for getting to the bottom of this. So if I understand things correctly, then from the xfig pov this is resolved now and this bug can stay in the closed state, correct? As for the fallback code added in 3.2.9-4 not actually being necessary, I took that from upstream git, so it will be in the next upstream release anyways and I guess it does help on some other distros with a different font setup.
"...from the xfig pov this is resolved now and this bug can stay in the closed state, correct?" I think so, but you might want to check in with the font people or periodically check until you see StanardSymbolsPS.otf appear in /usr/share/fonts/urw-base35. I haven't gotten any firm reply that they are pushing the resolution out right away. Also, since you may hear from people using F37 or 38, I thought you needed to know how to advise them to eliminate the Noto-Sans problem in the meantime. Sorry to hear about the unneeded code -- it WAS being triggered until the OTF file was restored, but it just doesn't work, at least not in Fedora. Still don't know why -- I didn't/don't have time to delve into the depths of Xft and legacy fonts. If the entire world goes UTF8 I won't complain, although there could certainly be better userspace tools to mess with the font configurations. Still too much like black magic, although the Fedora rules look to be pretty strict for the future so maybe it will all go away in a year or so more.
I don't know if the following problem is going to be eliminated when the other fixes land, but currently xfig-3.2.9-4 crashes if it tries to load StandardSymbolsPS.t1 because the code at the bottom of u_fonts.c calls the strcasestr() function but this isn't defined in any of the included headers and so you get these compiler warnings... u_fonts.c:976:33: warning: implicit declaration of function 'strcasestr'; did you mean 'strcasecmp'? [-Wimplicit-function-declaration] 976 | if ((fullname = strcasestr((char*)pattern, "fullname="))) { u_fonts.c:976:31: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion] ...and the implicit conversion makes a 64-bit pointer from a 32-bit int which then crashes when accessed. According to the strcasestr man page, you need to define _GNU_SOURCE before including <string.h> in order to get this function defined.