Bug 1523624

Additional comment

same linux i686 machine 
kernel 4.13.16-302.fc27.i686

I have recompiled xfig 3.6.2a from the source code available at sourceforge
xfig-full-3.2.6a.tgz

./configure and make worked but after using libpng12 (argument -lpng12 instead of -lpng in the Makefile)

This other xfig executable now displays several fonts, butnot all.
The following fonts are still not displayed : Bookman, Palatino, Symbol(Greek) and Helvetica Narrow

Exported files to .ps and .pdf are displayed OK with gv and xpdf for all fonts in the attached xfig file

Same problem here.  Mission critical for me as I use xfig to draw both textbook diagrams and quiz/exam questions and the semester starts tomorrow.  Xfig complains about the missing fonts when it starts up.  This is after a double upgrade from 25->26, then 26->27.

Did some font packages get dropped or renamed in some way that the upgrade missed them?

OK, I spent an hour or so on it today as I really, really need it to work.

For whatever reason, /usr/share/fonts/default/Type1 is missing on F27.  There is a Type1 directory under /usr/share/X11/fonts but it seems to be missing nearly everything.   I have access to a F25 system, and copied its Type1 directory in, rebuilt the app from source from sourceforge as above (didn't alter libpng and it seemed to build OK) and ran the binary.  It still isn't scaling on the display the way it did, but it does much better -- it now recognizes a nearly random selection of the fonts -- some Helvetica work, some don't, ditto Bookman.  The good news is all three times roman fonts work and symbol works, although when you are typing the characters onto the display they are spaced wrong until you exit the string entry function.

I did install fonts.dir and fonts.scale in that directory as described in:

https://bugzilla.redhat.com/show_bug.cgi?id=478786

(as this seems to happen every six or eight releases as somebody monkeys with fonts).  I'm guessing a lot of the rest of the problem is changes of some sort in urw fonts, as that is the other big place where people report problems.  The system installed xfig still doesn't work even reinstalled.

Note well I don't understand the way the fonts directories work these days and so I have no good idea of what is actually wrong, but it is pretty obvious that xfig can't find a lot of the fonts it needs where it expects them and/or can't figure out how to scale them if it finds them.

OK, a further update.  If I enter:

export LC_ALL=C

on the command line, it suppresses the error messages regarding fonts.  This was suggested by this:

https://access.redhat.com/solutions/409033

so it is possible that the locale variable isn't getting set correctly.  However, this is NOT the root cause of the font problem, as the fonts are still missing in the f27 rpm build.  I'm about to try to rebuild from the source rpm WITH the missing Type1 directory in place, as that is what seemed to fix the sources -- except for the still missing fonts.

OK, I've got it.

The fix has three parts:

a) Put back /usr/share/fonts/default/Type1 from F25 (or F26?).  It is the key file that was dropped in F27.  It is essential to xfig (basically a dependency and should be listed as such).  Make sure fonts.scale and fonts.dir exists in the directory (you may need to run:

  mkfontscale /usr/share/fonts/default/Type1
  mkfontdir   /usr/share/fonts/default/Type1

b) Put the following symlink in:

  cd /etc/X11/fontpath.d:
  ln -s /usr/share/fonts/default/Type1 fonts-default

(This is what I was missing before.)  Don't forget to run:

  xset fp rehash

in your current X session if you want to test it before logging out/in again.

c) Put:

  export LC_ALL=C

in your .bash_profile (really I expect this should be in /etc/bashrc as I can't see any good reason each user should have to set it).  This prevents the ugly font scaling messages.  They might not be there after a) and b), but it is pretty clear that it locale should be set anyway.

Then the stock xfig/transfig work perfectly without needing a rebuild.  It was indeed just a font issue, in particular the required Type1 fonts going away.

One last remark before leaving the thread to get back to real work -- I suspect one CAN make xfig work with the new urw-base35 fonts.  However, it is absolutely going to require the hacking of the xfig-3.2.5-urwfonts.patch in the src rpm.  If you look at the patch (and the resulting file, ./src/u_fonts.c) you can see that xfig has to match very specific strings from fonts.dir.  Those strings are correct in the fonts.dir for the Type1 fonts in the old urw-fonts rpm that now conflicts with urw-base35.  They are just plain wrong for the ones in fonts.dir in urw-base35.

So the probable REAL fix -- assuming you fedora folks want to migrate to urw-base35 for real -- is to make a new urwfonts.patch (and debug it!) -- or allow urw-fonts to NOT conflict with urw-base35 so they can both be installed.

Finally, there are still a few fonts missing, but I suspect they really are missing.  Nearly all of them work perfectly, including the (almost) correct scaling as they are appearing in the drawing window.

Arrgh!  Now xfig and its standard fonts works perfectly, but when I try to export to postscript the symbol font is missing (blanks instead of symbols).  The new urw-base35 fonts ARE all postscript fonts, and I'm guessing that they conflict with the old (ghostscript? adobe?) postscript fonts presumably installed in the old urw-fonts!

I suppose I can try to replace just one line in the xfontlist and get this to work, but this is very frustrating.  So close!

A bunch more quick reading and we end up with the following:

Hand edit /usr/share/ghostscript/9.22/Resource/Init/Fontmap.gs
and replace:

/Symbol                         /StandardSymL   ;
% /Symbol                               /StandardSymbolsPS      ;

and things like evince will start to work perfectly AFAICT at this point.  I'm pretty sure this forces it back to the type 1 symbol font in the old type1 directory, but curiously it does fine with all of the others.  Could just be a problem with the OTF symbol font.

I suspect that I'm tied up in a knot at this point -- I would need to install a clean F27 system to try to get xfig to work with urw-base35 correctly.  I will say that I TRIED to use a line that pointed into the urw-based35/fonts.dir directly for symbol, and xfig crashed instantly when I tried to select the font, so while it might be as simple as rewriting u_fonts.c, it might also be a problem upstream in whatever library it is using to try to access the fonts in the first place.  I will say that the eps files it produces are perfectly fine but they no longer display correctly if the /Symbol directive points to the otf fonts (the commented out line).

Anyway, I'm reasonably certain that I can do my work at this point, hopefully until an actual upstream person can read all of this and solve the problem correctly.  The fundamental problem is still that u_fonts.c (patched) doesn't have the correct strings to match what is in fonts.dir in urw-base35, so no matter what, until that is changed it isn't going to work.  On the other hand, if the display libraries (athena?  raw X11) can't handle the otf fonts in urw-base35, that isn't going to work either until those libraries are fixed.

Many thanks to rgb for finding how to solve the display bug in xfig under F27.
I'll try to implement this and see what happens.
Meanwhile I have tested what happens on a 64-bit machine under F27 and exactly same bug occurs with exactly the same behavior.
However after re-building xfig from sourceforge source, more fonts did appear on screen, and all exports to .ps and .pdf worked fine including symbols.

Hi David,

xfig is another package expecting to find the old fonts (also very old, also not active upstream).  It doesn't seem to use t1lib, but I haven't investigated it further.  There might be other info in this report that means more to you than to me.

It looks like xfig completely rolls its own font handling.  The fedora xfig package includes a patch (xfig-3.2.5-urwfonts.patch) that appears to update xfig to use the old (2.4) urw fonts, replacing lines from u_fonts.c like

{"-*-times-medium-r-normal--", (struct xfont*) NULL}

with a font that was included in the old urw-fonts packages:

{"-urw-nimbus roman no9 l-medium-r-normal--", (struct xfont*) NULL}

I tried updating those based on the output of xlsfonts with lines like

{"-urw-nimbus roman-medium-r-normal--", (struct xfont*) NULL},

Debugging the code, I see the code uses XListFonts to check if fonts are available.  XListFonts returns something when asked about

-urw-nimbus roman-medium-r-normal--0-0-*-*-*-*-ISO8859-*

later the code tries to load an actual font via XLoadQueryFont

-urw-nimbus roman-medium-r-normal--13-*-*-*-*-*-ISO8859-*

and that fails.  If I try from the commandline

xlsfonts -fn '-urw-nimbus roman-medium-r-normal--13-*-*-*-*-*-ISO8859-*'

I get 10 fonts.  I'm not sure what's going on.  I'll keep poking around, but I'm not sure what the code is doing wrong at this point.

Hello guys,

sorry for the late replied, but it was just today when Andrew put me in the loop here... :) I'm the maintainer of urw-fonts and urw-base35-fonts (aka "source of your problems" :D).

First I want to say I'm sorry for any inconvenience this bug caused you, and kudos for you hacking in to see what's wrong!

The main reason why 'urw-fonts' is now obsoleted (and will be completely dropped at EOL of F27) is Ghostscript. It has been for some time that Ghostscript is using completely new version of so called PostScript Core 2 Font Set (base35).

These fonts come from the company called (URW)++, and the versioning for those fonts has become total mess. Artifex company (upstream for Ghostscript and all urw-* fonts) decided to switch to the new version and started with new versioning scheme.

In order to bring the latest version of Ghostscript to Fedora, we needed to switch at some point to the new base35 fonts. I saw this as an opportunity to do a cleanup in the fonts package for base35 fonts, and created a new package from scratch (urw-base35-fonts). It follows the Fedora Packaging Guidelines (FPG).

And in regards to the issue, you are facing, there are actually several problems that have come together, and my change was the "last drop" that caused it to finally go down...

List of issues here:
--------------------
 * xfig is quite old, and upstream is apparently more or less dead. If possible, we need to start looking for a replacement for this software (the sooner the better) - for reasons below - or find somebody willing to dive in this, fork the xfig and become de facto new upstream (which is unlikely to happen).

 * xfig is using some kind of its own implementation of font locating, which makes it harder to solve this issue (when upstream is dead). Most modern software is using some kind of font management tool (fontconfig in Fedora).

 * Switch to fontconfig isn't IMHO viable, unless somebody knows the code properly. And the more downstream patches we have, the more problems we usually have in the future.

 * X11 is getting IMHO quite old as well, and it feels to me it's like in a maintanance mode most of the time. Fixing issues in upstream can be quite PITA.

 * During the update process for urw-base35-fonts it is automatically calling the 'xset fp rehash'. However, this does not work during the upgrades when X11 is not running. I have already reported this bug, but it won't get fixed:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1466254

 * The Type1 format of fonts is now deprecated in Fedora. Every software should switch to OTF/TTF format of fonts as soon as possible. The only reason why base35 fonts are still available in Type1 format is that Ghostscript (and some other critical software) still hasn't switch to newer formats.

 * Some software already switched to OTF/TTF fonts and have deprecated the Type1 fonts - for example LibreOffice in Fedora 26. Because of this, we are currently shipping both Type1 and OTF versions for base35 at the same time.

 * I expect that at some point in the future the whole Fedora will switch to OTF/TTF, and all software that wasn't ported to use OTF/TTF will be deprecated/dropped (unless it will get an exception from FESCo).

 * The urw-fonts and urw-base35-fonts contain both 35 fonts that should be equivalent. They might not look completely the same, but they are supposed to work interchangably. The biggest difference is just naming changes.

 * If any software uses the fontconfig for font management, then the update to urw-base35-fonts should be transparent to it, because urw-base35-fonts have its own fontconfig configuration files to map the old names to new ones.

 * Even fontconfig itself has switched to new base35 fonts naming in its default configuration files.

 * The new fonts location for urw-base35-fonts is: /usr/share/fonts/urw-base35,
this is in accordance to FPG. In case any package needs this path during it's build time, it can use the urw-base35-fonts-devel subpackage as its build requirement. This will result in all of the fonts to be installed for the build purposes, and the %{urw_base35_fontpath} macro containing the path to base35 fonts will be available. (Don't forget to add correct requirements for urw-base35-* package(s) as well.)

Hmm, I think this is all I can think of from top of my head...

To resolve this issue properly, we need to do these steps:
 1) Fix the xfig-3.2.5-urwfonts.patch so it does have correct names based on urw-base35-fonts. The question is how is xfig comparing the strings with the actual fonts, and thus how to correctly update the patch? This might need some poking around.

 2) Update the specfile to have BuildRequirements for 'urw-base35-fonts-devel' and Requirements for 'urw-base35-fonts', if needed.

 3) Update the specfile to ship 2 additional symlinks:
    /etc/X11/fontpath.d/fonts-default -> /usr/share/fonts/urw-base35
    /usr/share/fonts/default/Type1 -> /usr/share/fonts/urw-base35

   ->> I don't want to have this inside the specfile for urw-base35-fonts unless it is really necessary. So far, every other package/software was able to adapt to the new fonts path. If I would ship these symlinks, it would not "force" an update in Fedora, thus just postponing the issues that need to be solved.

I can created a pull-request for this, at some point, but it won't soon enough. I'm currently deep inside my primary job responsibilites... :-/ So if anyone else wants to create a pull-request for this, I can at least review it. :)

Best regards,

 -- Dee'Kej --

To quote:

To resolve this issue properly, we need to do these steps:
 1) Fix the xfig-3.2.5-urwfonts.patch so it does have correct names based on urw-base35-fonts. The question is how is xfig comparing the strings with the actual fonts, and thus how to correctly update the patch? This might need some poking around.

 2) Update the specfile to have BuildRequirements for 'urw-base35-fonts-devel' and Requirements for 'urw-base35-fonts', if needed.

 3) Update the specfile to ship 2 additional symlinks:
    /etc/X11/fontpath.d/fonts-default -> /usr/share/fonts/urw-base35
    /usr/share/fonts/default/Type1 -> /usr/share/fonts/urw-base35

I've already downloaded the source to see if I can fix it with changes "like" this, but I too have a day job and was just trying in a bit of a panic to get xfig working again because it is the base package for maybe 4000 textbook illustrations and uncountable quiz and exam diagrams used in the physics courses I teach.  In other words, it is mission critical to my daily work, even though that work itself takes a lot of my time.

So far I haven't had any success with step 1.  I've tried replacing at least a few of the font names in the actual software with the new/correct names, but the program either crashed or malfunctioned without crashing as far as I had time to test (once I figured out how to put back the old fonts and make it work, I had to stop and move on at least then, as the semester was just starting and I was swamped).  A possible contributor to this problem was that I had just upgraded F25 -> F27 (and am pretty sure I upgraded F24-F25 before that).  "Upgrade" vs a real clean install is always a bit dicey, and I didn't want to do all sorts of hacking until I had a pristine F27 install to work on.  For all I know, some of these problems are artifacts of using upgrade vs install.

I'm scheduled for a new laptop, likely in the next couple of weeks, and the first thing I'll be doing is putting F27 on it clean and transferring the /home partition.  If xfig doesn't work then, I'll go into the source and try to hotwire the font paths and add the symlinks you suggest.  Then IF I have time, I'll see what I can do about debugging it if/when this alone doesn't work.  I'm already a somewhat slovenly and behind upstream devel on a project of my own (dieharder) and I don't really want to tackle another, especially a package I didn't write myself, and I never wrote anything that did a lot of stuff with fonts so I know "nothing" about the font interface, but xfig is really, really important to me.

What about the new containerizing interface I've been hearing about?  Since xfig isn't really changing but works more or less perfectly, isn't a reasonable solution to take xfig in a configuration that worked (say, F25), make a minipackage of it and its core dependencies, and put it in a container?  That way nobody has to fix anything ever again (as long as X itself remains functional, and as an Old Guy I have to say I shudder to think that might happen and obsolete an enormous mountain of code, even though YES it was flawed way back in the 90's when it basically beat out PS-based windowing systems that were scalable but not portable).  I might be willing to try to figure out containerizing before I tried to hack xfig itself, as there are or hopefully will be a comparatively simple toolset to help set up a containerized build.

Hi!

Thank you all for your comments. 
I've been using xfig for 20 years and I'm really happy with it, so any solution like providing all required font files in the package as suggested by rgb.edu will be a good solution for xfig users.

I have tested the same xfig 3.2.6a version with a 64-bit machine and the behaviour is exactly the same as with my old 32-bit machine, so it is probably not a 32-bit / 64-bit issue.

I have re-compiled xfig from the original tar file xfig-full-3.2.6a.tgz available on xfig.info, release date JAN 2017.

Some fonts now display properly, namely those I use basically like Times Roman and Helvetica. Unfortunately, Helvetica Narrow is not displayed, but nevertheless it is exported to .ps and .pdf properly.

Almost fall onts are exported correctly throught fig2dev and yield a useable and printable .ps or .pdf file, the exception being Greek Symbols ("Symbol"), no display, no show when applying ghostscript to the output .ps file.

Below I have cut-pasted a few lines from a .ps file where I have one line of text to display ZapfChangery, dingbats and Greek Symbols

None of those font are displayed, but ZapfChangery and dingbats are recognised in the .ps output file and displayed properly by ghostscript.
/Symbol in the .ps file does not display anything under ghostscript.
Same behaviour if exported as .pdf and displayed with acrobat reader or xpdf.

....

% Fig objects follow
%
% 
% here starts figure with depth 50
% Polyline
0 slj
0 slc
7.500 slw
n 180 405 m 180 180 l
 450 180 l gs col7 s gr 
% Polyline
n 11835 8595 m 11835 8820 l
 11565 8820 l gs col7 s gr 
/ZapfChancery-MediumItalic-iso ff 793.75 scf sf
585 2185 m
gs 1 -1 sc (ZapfChancery-MediumItalic) col0 sh gr
/ZapfDingbats ff 793.75 scf sf
585 3185 m
gs 1 -1 sc (ZapfDingbats) col0 sh gr
/Times-Roman-iso ff 301.62 scf sf
495 1305 m
gs 1 -1 sc (Greek symbol follow:) col0 sh gr
/Symbol ff 793.75 scf sf
4140 1260 m
gs 1 -1 sc (Symbol) col0 sh gr
% here ends figure;
pagefooter
showpage
%%Trailer
%EOF


....................................................

As a summary, I'm able to use xfig 3.2.6a from the re-compiled version under F27, a few fonts are displayed correctly. 
Only Greek symbols are lost when exporting to .ps or .pdf, but I have a simple workaround for this, namely using small .eps files generated by LaTeX.

Hello Emmanuel,

(In reply to Emmanuel Bigler from comment #14)
> I've been using xfig for 20 years and I'm really happy with it, so any
> solution like providing all required font files in the package as suggested
> by rgb.edu will be a good solution for xfig users.

No, this is a no-go. Shipping the old fonts and the new versions is against Fedora Packaging Guidelines. It would only create another set of problems.

So no - xfig has to adapt to these new chagnes, there's no other way.

> I have tested the same xfig 3.2.6a version with a 64-bit machine and the
> behaviour is exactly the same as with my old 32-bit machine, so it is
> probably not a 32-bit / 64-bit issue.
> 
> I have re-compiled xfig from the original tar file xfig-full-3.2.6a.tgz
> available on xfig.info, release date JAN 2017.
> 
> Some fonts now display properly, namely those I use basically like Times
> Roman and Helvetica. Unfortunately, Helvetica Narrow is not displayed, but
> nevertheless it is exported to .ps and .pdf properly.
> 
> Almost fall onts are exported correctly throught fig2dev and yield a useable
> and printable .ps or .pdf file, the exception being Greek Symbols
> ("Symbol"), no display, no show when applying ghostscript to the output .ps
> file.

There are some changes to Ghostscript in F28 that might help, but I don't want to backport all of those changes into F27. It could break too many things (not to mention it is against FPG as well).

> Below I have cut-pasted a few lines from a .ps file where I have one line of
> text to display ZapfChangery, dingbats and Greek Symbols
> 
> None of those font are displayed, but ZapfChangery and dingbats are
> recognised in the .ps output file and displayed properly by ghostscript.
> /Symbol in the .ps file does not display anything under ghostscript.
> Same behaviour if exported as .pdf and displayed with acrobat reader or xpdf.

The problem with Standar Symbol PS (/Symbol) might be related to BZ #1534206. Try updating the urw-base35-fonts package to latest version.

Best regards,

 -- Dee'Kej --

Thanks do David Kaspar, your suggestions solved one of my pending bugs with .ps files generated by xfig.

>> The problem with Standard Symbol PS (/Symbol) might be related to BZ #1534206. 
>> Try updating the urw-base35-fonts package to latest version.

I have upgraded urw base 35 fonts and now my .ps file generated by xfig will display Greek symbols correctly throught ghostscript.
So far, in my F27 environment, be it 32 or 64 bit, all fonts accessible within xfig are displayed properly in .ps or .pdf exported files. A very good point indeed.

This does not solve the X11 font display bug in xfig, but at least, current transfig converts xfig files into valid .ps and .pdf files.

If we can understand why the re-compiled xfig version under current F27 environment **does** display Times Roman and Helvetica correctly, and not other fonts, may be this could help to find a viable solution to this bug.

And I can of course understand that Fedora maintainers don't want to ship old pieces of old software within future Fedora releases.
It means that xfig users will have to manage themselves with some extra files not shipped by Fedora ;-)

BTW, speaking about old software, I'm using another software older than, or contemporary of xfig named ... GNU-emacs, but for GNU-emacs I'm confident that all problems related to the move from old X11 to something "modern" will eventually be solved ;-)

All the best, and  thanks to all xfig and Fedora maintainners !

Some details regarding xfid 3.2.6a fonts that are displayed and fonts not displayed

source package xfig-full-3.2.6a.tar.xz
https://sourceforge.net/projects/mcj/files/xfig-full-3.2.6a.tar.xz/download

fedora 27 - X11  

last version of urw base 35 fonts installed
rpm -qa | grep -i urw
urw-base35-fonts-20170801-4.fc27.1.noarch
urw-base35-nimbus-mono-ps-fonts-20170801-4.fc27.1.noarch
urw-base35-d050000l-fonts-20170801-4.fc27.1.noarch
urw-base35-standard-symbols-ps-fonts-20170801-4.fc27.1.noarch
urw-base35-c059-fonts-20170801-4.fc27.1.noarch
urw-base35-p052-fonts-20170801-4.fc27.1.noarch
urw-base35-bookman-fonts-20170801-4.fc27.1.noarch
urw-base35-nimbus-sans-fonts-20170801-4.fc27.1.noarch
urw-base35-nimbus-roman-fonts-20170801-4.fc27.1.noarch
urw-base35-fonts-devel-20170801-4.fc27.1.noarch
urw-base35-fonts-common-20170801-4.fc27.1.noarch
urw-base35-gothic-fonts-20170801-4.fc27.1.noarch
urw-base35-z003-fonts-20170801-4.fc27.1.noarch

./configure works and creates a valid Makefile

make OK no error except that I needed to link against library png12 instead of png on my 32-bit machine

make install OK into /usr/local/bin

/usr/local/bin/xfig runs fine exept x11 display bug

list of  xfig 3.2.6a fonts displayed "almost" correctly under X11 and exported correctly to .ps and .pdf

"almost" note : fonts bigger than size 24 are displayed as 24, but exported correctly to .ps and .pdf

 0  Times-Roman
 1  Times-Italic
 2  Times-Bold
 3  Times-BoldItalic

 12 Courier
 13 Courier-Oblique
 14 Courier-Bold
 15 Courier-BoldOblique

 16 Helvetica
 17 Helvetica-Oblique
 18 Helvetica-Bold
 19 Helvetica-BoldOblique

 24 NewCenturySchlbk-Roman
 25 NewCenturySchlbk-Italic
 26 NewCenturySchlbk-Bold
 27 NewCenturySchlbk-BoldItalic

----------------------------------------------------------------------

list of fonts not displayed under X11 *but* exported correctly to .ps and .pdf

 4  AvantGarde-Book
 5  AvantGarde-BookOblique
 6  AvantGarde-Demi
 7  AvantGarde-DemiOblique

 8   Bookman-Light
 9   Bookman-LightItalic
 10  Bookman-Demi
 11  Bookman-DemiItalic

 20  Helvetica-Narrow
 21  Helvetica-Narrow-Oblique
 22  Helvetica-Narrow-Bold
 23  Helvetica-Narrow-BoldOblique

 28  Palatino-Roman
 29  Palatino-Italic
 30  Palatino-Bold
 31  Palatino-BoldItalic

 32  Symbol
 33  ZapfChancery-MediumItalic
 34  ZapfDingbats

Additional remark : the reason why the un-patched xfig  program, re-compiled from source under F27 does display some fonts on my computer, is probably that I have a legacy of old font directories and files found by xfig. 
I have upgraded fedora since, at least fedora, 23, and I have never erased /usr since.

Additional comment:  The show-stopper, of course, is symbol.  I do nearly everything with Times-Roman regular or italic and don't care too much about fancier fonts, but I absolutely can't live without symbol fonts.  It is the entire reason xfig is the best choice for scientific drawings -- I can draw or graph things with physics symbols like \alpha or \Delta in them, and scale them up or down as needed.  Dingbats, not so important, but Symbol baaaad to not have it work.

Hi,

Same, or at least, related problem here. Fonts are displaying, but always with the same size. Although, pdf export is fine.
Fedora 25 upgrated to 26 then 27.
Xfig 3.2.6a from fedora.
all urw packakge from fedora installed.
I need XFig, as I have not found equivalent for scientific drawing which allows to include Latex typesettings.

this is https://bugzilla.redhat.com/show_bug.cgi?id=1523624

Hi!

I have summarised in a set of test files how xfig 3.2.6a works in my F27 environment.
I have re-compiled xfig 3.2.6a from source without the urw patch. I do have some x11 fonts displayed because I have some x11 font legacy directories files installed since at least F23.

tar file is here to download
http://bigler.blog.free.fr/public/docs-en-pdf/2018-02-23-xfig-bug-F27-1523624-test-files.tar

description of files

xfig font test file; lists all fonts in size 24 from #0 (Times Roman) to #34 (dingbats); Greek Symbols is #32
test-fonts-xfig-0-34-s24.fig   

explanation
2018-02-23-list-of-displayed-fonts.txt

screen capture with bug, xfig 3.2.6a recompiled from original source
without urw patch, environment is fedora 27 with some x11 font legacy files
2018-02-23-104812-test-fonts-xfig-0-34-s24-X11-screen-capture.png

xfig export to ps ; a very compact file! displays correctly through ghostscript
2018-02-23-104637-test-fonts-xfig-0-34-s24.ps

xfig export to png displays correctly through various image viewers
2018-02-23-104812-test-fonts-xfig-0-34-s24.png

xfig export to jpg displays correctly through various image viewers
2018-02-23-104813-test-fonts-xfig-0-34-s24.jpg

xfig export to pdf displays correctly through various pdf viewers including xpdf
2018-02-23-104813-test-fonts-xfig-0-34-s24.pdf

exported pdf file re-converted to ps through pdf2ps, much bigger than the direct export to ps!!
2018-02-23-104813-test-fonts-xfig-0-34-s24-B.ps.gz

A quick update on this, I've been working on a fix for this tonight and its almost ready. I expect to have a fixed updated xfig package ready for testing tomorrow.

Correction I decided to just finish this tonight :)

Here is the changelog of the upcoming update:

* Thu Mar 01 2018 Hans de Goede <hdegoede> - 3.2.6a-6
- Fix font issues (rhbz#1523624) :
 - Adjust xfig-3.2.5-urwfonts.patch for new font names in urw-base35-fonts
 - Except for the symbols font, use the old un-scalable Adobe PCF Symbol font
   for now as StandardSymbolsPS.otf from urw-base35-fonts is currently broken
 - Add a patch to deal with some fonts being scalable, while Symbol is not
 - Note the dingbats font is also broken in urw-base35-fonts, but there is no
   replacement for it, so that font is still broken, see rhbz#1534206
- ghostscript-core no longer exists, instead require ghostscript (rhbz#1536581)
- Remove obsolete icon-cache and desktop-database scriptlets
- Add a patch from Debian fixing some issues with arrows

So the fonts not working problem really was 2 problems:

1) The font names of the urw fonts have changed, and we want to use those because they are scalable, instead of only allowing a limited number of sizes

2) The urw symbol ps font is broken and does not work with X11, so we ended up falling back to the adobe symbol font, but that is not scalable and we were requesting an unavailable size. The problem is that xfig has separate code-paths for scalable vs unscalable fonts (where it picks the closest size) but the check for this was only checking the "Times" font and then applying this to all fonts. I've added a patch which makes the check per-font and makes xfig pick the scaled / unscaled font behavior on a per font basis.

Note the new urw symbol font being broken is tracked in bug 1534206. As mentioned there the fonts for ZapfChancery and for ZapfDingbats are also broken, I've mapped ZapfChancery to TimesBoldItalic for now, for Dingbats no suitable replacement is available, so the Dingbats font is still broken in the upcomig update.

xfig-3.2.6a-6.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-871ca0eb51

Thank you, Hans. That's a great work out there! :)

Thanks to Hans de Goede for the new version.

I have downloaded the 32-bit version and installed from rpm. 

https://kojipkgs.fedoraproject.org//packages/xfig/3.2.6a/6.fc27/i686/xfig-3.2.6a-6.fc27.i686.rpm

No problem at install,  xorg-x11-fonts-100dpi.noarch 7.5-18.fc27 was automatically installed as a dependency. I'm using western European characters ISO8859-1 which were already installed for x11. my LANG and LC_ALL are fr_FR.ISO8859-1.

/usr/bin/xig with no options starts correctly but does not display fonts from my test file with all fonts, only Greek Symbols are displayed (they were not displayed before, so the bug is partially solved for me)

All fonts listed in my test file are size 24, not 27
this is what I have in my xfig test file
4 0 0 50 -1 0 24 0.0000 4 345 1995 1045 1000 font #0 24\001
4 0 0 50 -1 1 24 0.0000 4 450 1980 1045 1500 font #1 24\001
4 0 0 50 -1 2 24 0.0000 4 345 2070 1045 2000 font #2 24\001
4 0 0 50 -1 3 24 0.0000 4 450 2025 1045 2500 font #3 24\001



the xfig error message is
File test-fonts-xfig-0-34-s24.fig:
Can't find -urw-nimbus roman-medium-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus roman-medium-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus roman-bold-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus roman-bold-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-urw gothic-medium-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-urw gothic-medium-o-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-urw gothic-semibold-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-urw gothic-semibold-o-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-urw bookman-light-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-urw bookman-light-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-urw bookman-semibold-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-urw bookman-semibold-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus mono ps-medium-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus mono ps-medium-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus mono ps-bold-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus mono ps-bold-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus roman-bold-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus sans-medium-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus sans-medium-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus sans-bold-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus sans-bold-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus sans narrow-medium-r-semicondensed--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus sans narrow-medium-o-semicondensed--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus sans narrow-bold-r-semicondensed--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus sans narrow-bold-o-semicondensed--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-c059-medium-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-c059-medium-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-c059-bold-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-c059-bold-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-p052-medium-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-p052-medium-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-p052-bold-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-p052-bold-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13

Hi Emmanual,

Please make sure that you've urw-base35-fonts-20170801-3.fc27 or newer, you can download the latest F27 version here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1047716

After installing that do:

xset fp rehash

Before starting xfig.


If things still do not work then, try doing:

cd /etc/X11/fontpath.d/urw-base35-fonts/
sudo mkfontdir .
sudo mkfontscale .

xset fp rehash

And retry, if that is necessary something is still wrong with the urw-base35-fonts package.

Many thanks, Hans for your help, we are progressing but at my level, on my 32-bit machine, so far no font is displayed except Greek Symbols evenn after following your instructions

Re-doing the instructions step by step

>> Please make sure that you've urw-base35-fonts-20170801-3.fc27 or newer

done

packages installed
rpm -qa | grep -i urw
urw-base35-p052-fonts-20170801-5.fc27.noarch
urw-base35-z003-fonts-20170801-5.fc27.noarch
urw-base35-nimbus-sans-fonts-20170801-5.fc27.noarch
urw-base35-gothic-fonts-20170801-5.fc27.noarch
urw-base35-bookman-fonts-20170801-5.fc27.noarch
urw-base35-fonts-devel-20170801-5.fc27.noarch
urw-base35-standard-symbols-ps-fonts-20170801-5.fc27.noarch
urw-base35-nimbus-roman-fonts-20170801-5.fc27.noarch
urw-base35-d050000l-fonts-20170801-5.fc27.noarch
urw-base35-fonts-common-20170801-5.fc27.noarch
urw-base35-fonts-20170801-5.fc27.noarch
urw-base35-nimbus-mono-ps-fonts-20170801-5.fc27.noarch
urw-base35-c059-fonts-20170801-5.fc27.noarch


>> xset fp rehash

done ; xfig display bug still present

>> cd /etc/X11/fontpath.d/urw-base35-fonts/
>> sudo mkfontdir .
>> sudo mkfontscale .
>>
>> xset fp rehash

done all this, bug is still there, error message is identical, no change
File test-fonts-xfig-0-34-s24.fig:
Can't find -urw-nimbus roman-medium-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
...
Can't find -urw-p052-bold-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13

Greek Symbol fonts #32 are displayed OK in size 24 ; so far this is the only font actually displayed on my machine with installed rpm upgrade
https://kojipkgs.fedoraproject.org//packages/xfig/3.2.6a/6.fc27/i686/xfig-3.2.6a-6.fc27.i686.rpm

This is what xlsfonts yields after the previous configuration commands were
done, as far as iso-8859 x11 fonts are concerned

xlsfonts | grep urw | grep 8859-1$
-urw-c059-bold-i-normal--0-0-0-0-p-0-iso8859-1
-urw-c059-bold-r-normal--0-0-0-0-p-0-iso8859-1
-urw-c059-medium-i-normal--0-0-0-0-p-0-iso8859-1
-urw-c059-medium-r-normal--0-0-0-0-p-0-iso8859-1
-urw-nimbus mono ps-bold-i-normal--0-0-0-0-m-0-iso8859-1
-urw-nimbus mono ps-bold-r-normal--0-0-0-0-m-0-iso8859-1
-urw-nimbus mono ps-medium-i-normal--0-0-0-0-m-0-iso8859-1
-urw-nimbus mono ps-medium-r-normal--0-0-0-0-m-0-iso8859-1
-urw-nimbus roman-bold-i-normal--0-0-0-0-p-0-iso8859-1
-urw-nimbus roman-bold-r-normal--0-0-0-0-p-0-iso8859-1
-urw-nimbus roman-medium-i-normal--0-0-0-0-p-0-iso8859-1
-urw-nimbus roman-medium-r-normal--0-0-0-0-p-0-iso8859-1
-urw-nimbus sans narrow-bold-o-semicondensed--0-0-0-0-p-0-iso8859-1
-urw-nimbus sans narrow-bold-r-semicondensed--0-0-0-0-p-0-iso8859-1
-urw-nimbus sans narrow-medium-o-semicondensed--0-0-0-0-p-0-iso8859-1
-urw-nimbus sans narrow-medium-r-semicondensed--0-0-0-0-p-0-iso8859-1
-urw-nimbus sans-bold-i-normal--0-0-0-0-p-0-iso8859-1
-urw-nimbus sans-bold-r-normal--0-0-0-0-p-0-iso8859-1
-urw-nimbus sans-medium-i-normal--0-0-0-0-p-0-iso8859-1
-urw-nimbus sans-medium-r-normal--0-0-0-0-p-0-iso8859-1
-urw-p052-bold-i-normal--0-0-0-0-p-0-iso8859-1
-urw-p052-bold-r-normal--0-0-0-0-p-0-iso8859-1
-urw-p052-medium-i-normal--0-0-0-0-p-0-iso8859-1
-urw-p052-medium-r-normal--0-0-0-0-p-0-iso8859-1
-urw-urw bookman-light-i-normal--0-0-0-0-p-0-iso8859-1
-urw-urw bookman-light-r-normal--0-0-0-0-p-0-iso8859-1
-urw-urw bookman-semibold-i-normal--0-0-0-0-p-0-iso8859-1
-urw-urw bookman-semibold-r-normal--0-0-0-0-p-0-iso8859-1
-urw-urw gothic-medium-o-normal--0-0-0-0-p-0-iso8859-1
-urw-urw gothic-medium-r-normal--0-0-0-0-p-0-iso8859-1
-urw-urw gothic-semibold-o-normal--0-0-0-0-p-0-iso8859-1
-urw-urw gothic-semibold-r-normal--0-0-0-0-p-0-iso8859-1
-urw-z003-medium-i-normal--0-0-0-0-p-0-iso8859-1


Possibly a name mismatch between what xlsfonts yields and what xfig is
expecting ? I am not familar with x11 font naming.

I'll try tonight with another machine which is not as old as my 32-bit PC,
and with a very different history of fedora upgrades. My 32-bit machine is
storing a lot of legacy directories and files that may interfere with the
present debugging process.

(In reply to Emmanuel Bigler from comment #28)
> Many thanks, Hans for your help, we are progressing but at my level, on my
> 32-bit machine, so far no font is displayed except Greek Symbols evenn after
> following your instructions

Weird, it works, even with your locale setting for me on an up2date F27 x86_64 install, but I doubt that this is 32 bit related ...

> xlsfonts | grep urw | grep 8859-1$
> -urw-c059-bold-i-normal--0-0-0-0-p-0-iso8859-1

<snip>

That looks fine.

> Possibly a name mismatch between what xlsfonts yields and what xfig is
> expecting ? I am not familar with x11 font naming.

On a manual compare between the errors and the xlsfonts output everything looks ok.

BTW the font-size of 27 comes from this part of the xfig code in src/w_drawprim.c:

        /* if user asks, adjust for correct font size */
        if (appres.correct_font_size)
            size = round(size*80.0/72.0);

Where correct_font_size defaults to true. This only influences how the fonts are shown, not their size in "printing". This makes 27 out of the 24 you input.

> I'll try tonight with another machine which is not as old as my 32-bit PC,
> and with a very different history of fedora upgrades. My 32-bit machine is
> storing a lot of legacy directories and files that may interfere with the
> present debugging process.

Ok, I'm curious to see how this works for you on your other machine.

Do you perhaps have some custom X app resources for xfig, maybe disabling scalable fonts?

Hi Hans and thanks again. I'll check  tonight with the other machine and report here.

The only cutomizations that I use with xfig are a few lines in my .Xdefault file, as follows. Some were installed 15 years ago and might be obsolete now.


!#  xfig section
! make the F3 key paste text in the canvas
Fig*canvas.translations: #override \n\
			<Key>F3: PasteCanv()\n
!# printer name
!# If the following resource is NOT set, xfig will use the PRINTER 
!# shell environment variable for the printer name
Fig*printer*string:	lp1	
!#Fig*job_params*string:		-h %f
Fig*job_params*string:		-h 
!#Fig*job_params*string:           %f -Plp3

! Browser - put your favorite browser here.  
! 		This is for viewing the xfig html reference.
!# For netscape, this command will open the help pages in a running netscape,
!#     or start a new netscape if one isnt already running

Fig.browser:	firefox -remote 'openFile(%f)' || firefox %f

! pdfviewer - put your favorite pdf viewer here.  
!		This is for viewing the xfig how-to guide and man pages
Fig.pdfviewer:			xpdf %f

Fig*edit_panel*Text_text*international: true
Fig*edit_panel*inputMethod: xim

xfig-3.2.6a-6.fc27 has been pushed to the Fedora 27 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-2018-871ca0eb51

Hello all!

I have installed the improved version 3.2.6a-6.fc27.x86_64 of xfig on a 64-bit machine
https://kojipkgs.fedoraproject.org//packages/xfig/3.2.6a/6.fc27/x86_64/xfig-3.2.6a-6.fc27.x86_64.rpm

I have exactly the same versions of urw-base35 fonts as on my 32 bit machine

Unfortutately the  behavior on my 64-bit machine is the same, fonts not found except x11 Symbol font.

I tried 

>> xset fp rehash

then

>> cd /etc/X11/fontpath.d/urw-base35-fonts/
>> sudo mkfontdir .
>> sudo mkfontscale .
>>
>> xset fp rehash

but no change, same error messages inside xfig

File test-fonts-xfig-0-34-s24.fig:
Can't find -urw-nimbus roman-medium-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus roman-medium-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus roman-bold-r-normal--27-*-*-*-*-*-ISO8859-*, using 6x13
Can't find -urw-nimbus roman-bold-i-normal--27-*-*-*-*-*-ISO8859-*, using 6x13

My be I am missing some FC27 package??
this is all I have under the urw keyword
rpm -qa | grep -i urw
urw-base35-nimbus-sans-fonts-20170801-5.fc27.noarch
urw-base35-gothic-fonts-20170801-5.fc27.noarch
urw-base35-c059-fonts-20170801-5.fc27.noarch
urw-base35-fonts-20170801-5.fc27.noarch
urw-base35-bookman-fonts-20170801-5.fc27.noarch
urw-base35-nimbus-mono-ps-fonts-20170801-5.fc27.noarch
urw-base35-p052-fonts-20170801-5.fc27.noarch
urw-base35-standard-symbols-ps-fonts-20170801-5.fc27.noarch
urw-base35-d050000l-fonts-20170801-5.fc27.noarch
urw-base35-nimbus-roman-fonts-20170801-5.fc27.noarch
urw-base35-fonts-devel-20170801-5.fc27.noarch
urw-base35-z003-fonts-20170801-5.fc27.noarch
urw-base35-fonts-common-20170801-5.fc27.noarch

the command
 xlsfonts | grep urw | grep 8859-1$
yields exactly the same list as on the 32-bit machine.

So I'm ready to continue the debugging process!

Thanks and ugh, I've just spend a couple of hours debugging this after reproducing it with a fresh install in a vm.

The main problem is that the new urw-base35-fonts are not usable at all by apps which use X11 core (server-side) fonts, I've filed bug 1551219 for this.

Things worked for me because xfig did think it could use them as they are listed in xlsfonts (but they don't actually work) so it was using the scalable font paths for these fonts, and the scalable fonts code uses fallback fonts from xorg-x11-fonts-100dpi. This normally breaks because these are unscalable, but the iso8859-2-100dpi-fonts package which I had installed wrongly defines scalable alias-es for them (bug 1551221), causing things to work for me.

For now I'm preparing a new update which removes the use of urw-fonts for displaying fonts in xfig. This means that for now we get:

1) unscalable fonts, using the closest smaller matching size
2) fallback (different) fonts for Bookman, New Century Schoolbook and Palatino
3) Zapf Chancery and Zapf Dingbats being replaced by the "fixed" font

Once bug 1551219 is resolved I will prepare another update moving back to the use of urw-fonts for displaying fonts in xfig so that they are a (closer) match to what actually ends up in a generated image / ps / pdf.

xfig-3.2.6a-7.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-871ca0eb51

xfig-3.2.6a-7.fc27 has been pushed to the Fedora 27 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-2018-871ca0eb51

Many thanks to Hans for the new version
https://kojipkgs.fedoraproject.org/packages/xfig/3.2.6a/7.fc27/x86_64/xfig-3.2.6a-7.fc27.x86_64.rpm

I have installed it, 64-bit version, and everything works as described above.

BTW this version solves a long-term bug I had with Helvetica Narrow fonts not displayed. Now Helvetica Narrow are displayed which is very useful when making slides for presentations. And Symbols are displayed which is perfect also for those using equations.

I understand that this bug is related to the gradual replacement of x11 by some other software and this is a long term task !
Thanks again in the behalf of all xfig users !

Hello and thanhs again to Hans.
I have prepared an updated set of test files to show where we are.

tested xfig FC27 rpm version is
https://kojipkgs.fedoraproject.org/packages/xfig/3.2.6a/7.fc27/x86_64/xfig-3.2.6a-7.fc27.x86_64.rpm

test files to download from here
http://bigler.blog.free.fr/public/docs-en-pdf/2018-03-04-test-fonts-xfig-0-34-s24-screen-capture-3-2-6a-7-fc27.tgz

contents:

an xfig input test file listing all fonts from #0 (Times Roman) tp #34 (Zapf dingbats)
 test-fonts-xfig-0-34-s24.fig

screen capture for xfig-3.2.6a-7.fc27.x86_64.rpm
 test-fonts-xfig-0-34-s24-screen-capture-3-2-6a-7-fc27.png

For missing fonts an approximate rendering is implemented. 
For example Helvetica Narrow are displayed as plain Helvetica, hence the actual length of a piece of text is shown on screen longer than it should be, but export to .ps and .pdf are eventually fine.

exported file to ps through fig2dev in transfig-3.2.6a-1.fc27.x86_64
 test-fonts-xfig-0-34-s24.ps

exported file to pdf through fig2dev in transfig-3.2.6a-1.fc27.x86_64
 test-fonts-xfig-0-34-s24.pdf

I downloaded and installed the 32-bit version of xfig-3.2.6a-7.fc27
https://kojipkgs.fedoraproject.org/packages/xfig/3.2.6a/7.fc27/i686/xfig-3.2.6a-7.fc27.i686.rpm

runs fine, no difference with the 64-bit version.

xfig-3.2.6a-7.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

The problem appears to persist in xfig-3.2.6a-7.fc27. I am running an up-to-date version of fc27, x86_64 and have urw-base35-fonts-20170801-5.fc27 installed. 

urw-base35-fonts]# xlsfonts | grep urw shows the same set of installed fonts as listed on Emmanuel's earlier post. However, xfig gives a "Unable to load any usable fontset" error. The symbol font is available and scalable, but nothing else is. 

Like some others this is mission-critical for me; I have over 15 years work invested in xfig figures!

Hi,

(In reply to philipls.au from comment #40)
> The problem appears to persist in xfig-3.2.6a-7.fc27. I am running an
> up-to-date version of fc27, x86_64 and have urw-base35-fonts-20170801-5.fc27
> installed. 
> 
> urw-base35-fonts]# xlsfonts | grep urw shows the same set of installed fonts
> as listed on Emmanuel's earlier post. However, xfig gives a "Unable to load
> any usable fontset" error. The symbol font is available and scalable, but
> nothing else is. 
> 
> Like some others this is mission-critical for me; I have over 15 years work
> invested in xfig figures!

Hmm, can you try doing:

sudo rm /etc/X11/fontpath.d/urw-base35-font
xset fp rehash

And then run xfig again.

If that does not resolve things, what is the output of:

ls /etc/X11/fontpath.d/

On your system?

Regards,

Hans

Hi Hans, thanks for your quick response. I had already tried: 

sudo rm /etc/X11/fontpath.d/urw-base35-font
xset fp rehash

It still produces the "Unable to load any usable fontset" error message. The output of ls /etc/X11/fontpath.d/ is:

liberation-fonts  'xorg-x11-fonts-100dpi:unscaled:pri=30'
urw-base35-fonts  'xorg-x11-fonts-misc:unscaled:pri=10'

Philip

Solved, thanks to mystery benefactor Peter. 

The steps were:

1. Locate and download a set of *.pfb font files

2. Install those files in /usr/share/fonts/default/xfigfonts

3. Link to default-fonts on the X11 fontpath:

ln -s /usr/share/fonts/default/xfigfonts /etc/X11/fontpath.d/default-fonts

Inexpressible gratitude for the help!

Philip

(In reply to philipls.au from comment #42)
> Hi Hans, thanks for your quick response. I had already tried: 
> 
> sudo rm /etc/X11/fontpath.d/urw-base35-font
> xset fp rehash

Ugh, typo.

That should be:

sudo rm /etc/X11/fontpath.d/urw-base35-fonts
xset fp rehash

Note that is font_s_

So that:

> It still produces the "Unable to load any usable fontset" error message. The
> output of ls /etc/X11/fontpath.d/ is:
> 
> liberation-fonts  'xorg-x11-fonts-100dpi:unscaled:pri=30'
> urw-base35-fonts  'xorg-x11-fonts-misc:unscaled:pri=10'

urw-base35-fonts is no longer here.

Removing the broken urw-base35-fonts from the Xserver font path is being tracked in bug 1551219.

(In reply to philipls.au from comment #43)
> Solved, thanks to mystery benefactor Peter. 
> 
> The steps were:
> 
> 1. Locate and download a set of *.pfb font files
> 
> 2. Install those files in /usr/share/fonts/default/xfigfonts
> 
> 3. Link to default-fonts on the X11 fontpath:
> 
> ln -s /usr/share/fonts/default/xfigfonts /etc/X11/fontpath.d/default-fonts

Hmm, can you try dropping both the new /etc/X11/fontpath.d/default-fonts and the /etc/X11/fontpath.d/urw-base35-font symlinks, followed by "xset fp rehash" and see if that also fixes things?

I'm happy that you've solved this for yourselves, but we really need to fix this in such a way that it works OOTB.

Hans,

Deleting those links reverts to the previous behaviour; Symbol is available and scalable, but none of the other fonts are. The contents of /etc/X11/fontpath.d is:

lrwxrwxrwx. 1 root root 27 Dec 21 00:18  liberation-fonts -> /usr/share/fonts/liberation
lrwxrwxrwx. 1 root root 27 Jul 28  2017 'xorg-x11-fonts-100dpi:unscaled:pri=30' -> /usr/share/X11/fonts/100dpi
lrwxrwxrwx. 1 root root 25 Jul 28  2017 'xorg-x11-fonts-misc:unscaled:pri=10' -> /usr/share/X11/fonts/misc

Philip

Hello guys!

I have created a scratch-build with the new StandardSymbolsPS.otf inside it:

https://dkaspar.fedorapeople.org/share/scratch-build/fedora/

Please test the packages, and let me know the results. Thanks!

(In reply to David Kaspar [Dee'Kej] from comment #46)
> Hello guys!
> 
> I have created a scratch-build with the new StandardSymbolsPS.otf inside it:
> 
> https://dkaspar.fedorapeople.org/share/scratch-build/fedora/
> 
> Please test the packages, and let me know the results. Thanks!

Thanks, but that is not going to help until the bug about apps using the old X11 core fonts not being able to use otf fonts is fixed (bug 1551219 ).

(In reply to Hans de Goede from comment #47)
> Thanks, but that is not going to help until the bug about apps using the old
> X11 core fonts not being able to use otf fonts is fixed (bug 1551219 ).

I'm already doing a new builds for it, but they do not contain the new StandardSymbolsPS.otf font. I didn't want to include it until we are sure it is fixed.

Also, looks like the Nimbus Sans needs fixing as well: #1535051
(Upstream already knows about it, but it can take up to 2 weeks before we get fix, since they have some conference coming up.)

(In reply to David Kaspar [Dee'Kej] from comment #48)
> I'm already doing a new builds for it, but they do not contain the new
> StandardSymbolsPS.otf font. I didn't want to include it until we are sure it
> is fixed.
https://bodhi.fedoraproject.org/updates/urw-base35-fonts-20170801-6.fc27
https://bodhi.fedoraproject.org/updates/urw-base35-fonts-20170801-9.fc28

As discussed in bug 1551219 as a workaround for libXfont2 no being able to deal with the new urw fonts, the old ones are now packaged as urw-base35-fonts-legacy.

I've just prepared an update for xfig to the new upstream release 3.2.7a and for that release I'm moving back to using the urw-fonts (using the new -legacy package), this should fix xfig not displaying the right fonts for Bookman, New Century Schoolbook and Palatino and should also make the display of other fonts a closer match to the image rendered when exporting.

xfig-3.2.7a-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-db3bd64475

xfig-3.2.7a-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-009f178c43

xfig-3.2.7a-1.fc28 has been pushed to the Fedora 28 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-2018-009f178c43

xfig-3.2.7a-1.fc29 has been pushed to the Fedora 29 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-2018-db3bd64475

xfig-3.2.7a-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Many thanks for fixing this!

I downloaded and tested xfig-3.2.7a-1 under fedora 28 on an X86_64 machine and everything works like a charm!

You can download from here 
http://bigler.blog.free.fr/public/docs-en-pdf/2018-11-19-test-fonts-xfig-327a-0-34-s24-files.tgz

the following test files
xfig input file
test-fonts-xfig-0-34-s24.fig

327a screen capture
test-fonts-xfig-327a-0-34-s24-screen-capture.png

exports to pdf and ps
test-fonts-xfig-327a-0-34-s24.pdf
test-fonts-xfig-327a-0-34-s24.ps

Thanks again! Long life to xfig!

xfig-3.2.7a-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

I hate to reawaken this old bug, but it has resurfaced somewhere between 36 and 38/39.  I just upgraded two of my systems, one an "upgrade" from 36 to 38 and one a clean install to 39, and xfig no longer displays the symbol font (again).  In the meantime, the layout of /usr/share/fonts has changed -- in particular there is no longer a /usr/share/font/default directory and the Type1 font is not there at all (but is in /usr/share/X11/fonts/Type1, apparently).  I tried a few simple things -- putting in symlinks that seemed to fix the problem last time but they didn't work.  I haven't looked back at the source code to see what is going wrong, but again, this is a mission critical app for me and while symbol fonts DO still correctly display in e.g. EPS or PDF conversions, they don't display in xfig itself. Out of the box they are either blank or replaced by a standard alphabet font.

Could a maintainer look at this and see if a simple tweak can fix it again?  I'm guessing that a path or something got shifted out from underneath xfig and running down new locations may fix it -- again.

(In reply to rgb from comment #58)
> I hate to reawaken this old bug, but it has resurfaced somewhere between 36
> and 38/39.  I just upgraded two of my systems, one an "upgrade" from 36 to
> 38 and one a clean install to 39, and xfig no longer displays the symbol
> font (again).  In the meantime, the layout of /usr/share/fonts has changed
> -- in particular there is no longer a /usr/share/font/default directory and
> the Type1 font is not there at all (but is in /usr/share/X11/fonts/Type1,
> apparently).  I tried a few simple things -- putting in symlinks that seemed
> to fix the problem last time but they didn't work.  I haven't looked back at
> the source code to see what is going wrong, but again, this is a mission
> critical app for me and while symbol fonts DO still correctly display in
> e.g. EPS or PDF conversions, they don't display in xfig itself. Out of the
> box they are either blank or replaced by a standard alphabet font.
> 
> Could a maintainer look at this and see if a simple tweak can fix it again? 
> I'm guessing that a path or something got shifted out from underneath xfig
> and running down new locations may fix it -- again.

Right, I believe that this issue re-surfacing has already been reported
in bug 2260359.

According it the reporter there this is a regression in the new
3.2.9 version. Which suggests that this is not an issue caused by Fedora
font path changes, but rather by some changes done by upstream.

Can you verify that downgrading to xfig-3.2.8:

F38: https://koji.fedoraproject.org/koji/buildinfo?buildID=2134823
F39: https://koji.fedoraproject.org/koji/buildinfo?buildID=2258365

To downgrade, download xfig-3.2.8b-4.fc38.x86_64.rpm /
xfig-3.2.8b-5.fc39.x86_64.rpm from there in and run:

sudo rpm -Uvh --oldpackage xfig-3.2.8b-4.fc38.x86_64.rpm

or:

sudo rpm -Uvh --oldpackage xfig-3.2.8b-5.fc39.x86_64.rpm

If you can confirm that downgrading fixes this can you please
report this issue upstream? I unfortunately don't really have
time to maintain xfig properly anymore, so I hope that upstream
can look into this (esp. since it seems to be caused by an upstream
change).

If you report a bug upstream, please also add a note to
bug 2260359 that you have reported this upstream.

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 bug report.

Thanks so much! rgb

OK, I've figured out what is wrong.  In:

    /usr/share/fonts/urw-base35

the REQUIRED file

 StandardSymbolsPS.otf

is missing.  This is the actual binary font representation, AFAICT.  Without it, xfig tries to load an old-style X11 version padded with 00's but there is no actual font available so it makes everything 0 size emptyness except where buffer overwrites appear to produce accidental crap.

With it, it correctly uses UTF8 throughout and the font appears as it should in xfig.  I've verified that the font rotates and moves and scales as it should

I demonstrated this by downloading StandardSymbolsPS.otf from:

https://github.com/twardoch/urw-core35-fonts/blob/master/StandardSymbolsPS.otf

and putting the file in /usr/share/fonts/urw-base35.  Instantly, everything worked.

This is clearly a bug in urw-base35-fonts-common, but the bug is a key dependence for xfig (and probably more) as they convert to Xtf fonts.  I'll try to file it there as well, but in any event, this tells anyone/everyone wanting to resolve the bug "now" a way to do it while the bug fix works its way through the system.