As reported in bug 1523624 xfig is having font issues. At first I thought this was caused by a combination of bug 1534206 and the new version of the URW fonts having different names. Further testing has shown this to be not correct. The only reason the new URW fonts seemed to be working is because of a font fallback table in the xfig code. It turns out that neither the new .t1 nor the new .otf file are usable as X11 core fonts by xorg-x11-server. As such installing a symlink to the urw-base35-fonts under /etc/X11/fontpath.d is useless (as is running mkfontscale and mkfontdir). At a minimum the /etc/X11/fontpath.d symlink should be removed. But that leaves X11 applications using server fonts without access to the Bookman, New Century Schoolbook, Palatino, Zapf Chancery and Zapf Dingbats fonts. We are still building the old urw-fonts: https://koji.fedoraproject.org/koji/packageinfo?packageID=905 I believe that a good solution for this would be to: 1) Remove the /etc/X11/fontpath.d symlink from urw-base35-fonts 2) Rename the old urw-fonts to x11-xorg-x11-urw-fonts; and 3) install them under /usr/share/X11/fonts/urw-fonts so that fontconfig will not pick them up and they will only be available to X11 core fonts using apps David Kaspar, I would be greatful if you can take care of this, as I've already spend way too much time on this.
Hello Hans, thank you for your findings. (In reply to Hans de Goede from comment #0) > As reported in bug 1523624 xfig is having font issues. At first I thought > this was caused by a combination of bug 1534206 and the new version of the > URW fonts having different names. > > Further testing has shown this to be not correct. The only reason the new > URW fonts seemed to be working is because of a font fallback table in the > xfig code. > > It turns out that neither the new .t1 nor the new .otf file are usable as > X11 core fonts by xorg-x11-server. What do you mean exactly by that? Can you give me an example, please? Why are the new fonts not usable? > As such installing a symlink to the urw-base35-fonts under > /etc/X11/fontpath.d is useless (as is running mkfontscale and mkfontdir). Well, I can remove those as a workaround, if needed. > At a minimum the /etc/X11/fontpath.d symlink should be removed. But that > leaves X11 applications using server fonts without access to the Bookman, > New Century Schoolbook, Palatino, Zapf Chancery and Zapf Dingbats fonts. > > We are still building the old urw-fonts: > https://koji.fedoraproject.org/koji/packageinfo?packageID=905 We are, but that packages is going to be retired in F29 (after F27 is EOL). > I believe that a good solution for this would be to: > > 1) Remove the /etc/X11/fontpath.d symlink from urw-base35-fonts I can do this as temporary workaround. > 2) Rename the old urw-fonts to x11-xorg-x11-urw-fonts; and > 3) install them under /usr/share/X11/fonts/urw-fonts so that fontconfig will > not pick them up and they will only be available to X11 core fonts using apps Nope, sorry. This is just can't happen. The urw-fonts can't be installed together with the new urw-base35-fonts - they are conflicting each other, and for a good reasons: * Ghostscript is directly depending on the new fonts, and GS is critical for many users who display PS/PDF files, or users who do PS files conversions. Also, many other software is also depending on Ghostscript itself, expecting it to work properly. * Using the old urw-fonts on the system with newer Ghostscript was generating unnecessary bugs because of downstream patches for it. * urw-fonts are no longer receiving updates * Ghostscript's & fontconfig's upstream have already switched to new versions of (URW)++ fonts (urw-base35-fonts) * AFAIK the fontconfig now supports the requests for old (URW)++ font mappings to the new versions, but for that to work it needs the urw-base35-fonts * Most of the packages directly depending on urw-fonts have already switched to urw-base35-fonts (BZ #1494563). Going back isn't IMHO a wise choice. Same applies of having 2 sets of Level 2 Core Font Sets to be installed on the same machine. * Bypassing the conflict (with e.g. renaming the urw-fonts to x11-xorg-urw-fonts) could generate another set of problems that I can't think of ATM. ... IMHO, we need to deal with the xorg and the new fonts themselves, if we are suppose to move forward with development of Fedora. In case the new fonts are missing something, or something needs to be fixed for them, then I will report it to upstream and work on resolving it. In case the xorg is missing some support, then we need to take it to xorg's upstream. I'm not a fan of downstream patches at all, I try to use them only as a last resort. :) > David Kaspar, I would be greatful if you can take care of this, as I've > already spend way too much time on this. Yeah, I understand. I personally have being continuosly working on the problems with (URW)++ fonts for more than half a year now... :-/
Hello David, (In reply to David Kaspar [Dee'Kej] from comment #1) > Hello Hans, > > thank you for your findings. > > (In reply to Hans de Goede from comment #0) > > As reported in bug 1523624 xfig is having font issues. At first I thought > > this was caused by a combination of bug 1534206 and the new version of the > > URW fonts having different names. > > > > Further testing has shown this to be not correct. The only reason the new > > URW fonts seemed to be working is because of a font fallback table in the > > xfig code. > > > > It turns out that neither the new .t1 nor the new .otf file are usable as > > X11 core fonts by xorg-x11-server. > > What do you mean exactly by that? Can you give me an example, please? Why > are the new fonts not usable? They show up in xlsfonts because of the fonts.dir which is generated. But they cannot be actually use in any X applications since the xserver does not know how to deal with t1 / otf files. For example start: xfontsel, click on fmly, then select "nimbus roman" notice the white area below the font specification stays empty, now select "fixed" instead and notice how you do get text (change rgstry to "iso8859" to get western characters). Note if you change back to an urw font the *previous* preview stays in place but gets grayed out to indicate it is not valid. TL;DR: the new urw fonts are not usable as X11 core (server-side) fonts *at all*. > > As such installing a symlink to the urw-base35-fonts under > > /etc/X11/fontpath.d is useless (as is running mkfontscale and mkfontdir). > > Well, I can remove those as a workaround, if needed. It is not a workaround, but yes not having non working fonts listed in the list of available fonts as shown by xlsfonts would be a good first step. > > > At a minimum the /etc/X11/fontpath.d symlink should be removed. But that > > leaves X11 applications using server fonts without access to the Bookman, > > New Century Schoolbook, Palatino, Zapf Chancery and Zapf Dingbats fonts. > > > > We are still building the old urw-fonts: > > https://koji.fedoraproject.org/koji/packageinfo?packageID=905 > > We are, but that packages is going to be retired in F29 (after F27 is EOL). > > > I believe that a good solution for this would be to: > > > > 1) Remove the /etc/X11/fontpath.d symlink from urw-base35-fonts > > I can do this as temporary workaround. Please do. > > 2) Rename the old urw-fonts to x11-xorg-x11-urw-fonts; and > > 3) install them under /usr/share/X11/fonts/urw-fonts so that fontconfig will > > not pick them up and they will only be available to X11 core fonts using apps > > Nope, sorry. This is just can't happen. The urw-fonts can't be installed > together with the new urw-base35-fonts - they are conflicting each other, > and for a good reasons: > * Ghostscript is directly depending on the new fonts, and GS is critical > for many users who display PS/PDF files, or users who do PS files > conversions. Also, many other software is also depending on Ghostscript > itself, expecting it to work properly. > * Using the old urw-fonts on the system with newer Ghostscript was > generating unnecessary bugs because of downstream patches for it. As I wrote a;ready "install them under /usr/share/X11/fonts/urw-fonts so that fontconfig will not pick them, I would expect ghostscript to also not look for them there. The idea is to only use the old versions for apps using X11 core fonts. > * urw-fonts are no longer receiving updates Neither are most apps using X11 core fonts, but a lot of people still use them and some of these apps need the URW fonts. > * Ghostscript's & fontconfig's upstream have already switched to new > versions of (URW)++ fonts (urw-base35-fonts) Which is fine, I'm suggesting making these *only* available as X11 core fonts, note that /etc/fonts/fonts.conf has: <dir>/usr/share/fonts</dir> <dir>/usr/share/X11/fonts/Type1</dir> <dir>/usr/share/X11/fonts/TTF</dir <dir prefix="xdg">fonts</dir> <!-- the following element will be removed in the future --> <dir>~/.fonts</dir> So under /usr/share/X11/fonts fontconfig only looks under /usr/share/X11/fonts/Type1 if we put the old urw fonts under /usr/share/X11/fonts/urw-fonts they will be ignored by fontconfig. Basically we might just as well put the under /foobar/nothing-will-look-for-them-here/other-weird-dirname/. We combine this dirname-noone-will-look-in-for-fonts with a symlink in /etc/X11/fontpath.d to make them available as X11 core fonts. > * AFAIK the fontconfig now supports the requests for old (URW)++ font > mappings to the new versions, but for that to work it needs the > urw-base35-fonts > * Most of the packages directly depending on urw-fonts have already > switched to urw-base35-fonts (BZ #1494563). Going back isn't IMHO a wise > choice. Same applies of having 2 sets of Level 2 Core Font Sets to be > installed on the same machine. Right, so my suggestion is to keep using the new fonts everywhere, except in the old (very old) X11 core font subsystem. So any app using $new font subsys will see the new fonts, and only apps using X11 core fonts will see the old version (and not the new version). > * Bypassing the conflict (with e.g. renaming the urw-fonts to > x11-xorg-urw-fonts) could generate another set of problems that I can't > think of ATM. Right, this is why as part of the package-rename we also put the fonts in a directory where no app will look for them. If you're worried some app might parse all fonts under /usr/share/X11/fonts we can put them somewhere else. > ... IMHO, we need to deal with the xorg and the new fonts themselves, if we > are suppose to move forward with development of Fedora. I don't think anyone is going to add support for these new type of fonts to the xserver's builtin font code. > In case the new fonts are missing something, or something needs to be fixed > for them, then I will report it to upstream and work on resolving it. One workaround which I've found is opening the .t1 or .otf files in fontforge and saving them as .ttf files. But that removes all character maps except for the unicode one and I've no experience with fontforge so I don't know how to fix this. > In case the xorg is missing some support, then we need to take it to xorg's > upstream. I don't think anyone in xorg's upstream is maintaining X11 core fonts support, but sending an email to the xorg-devel mailinglist about this issue is probably a good idea regardless. > I'm not a fan of downstream patches at all, I try to use them only as a last > resort. :) I'm not talking about patching anything here, just keeping the old version of the fonts around for X11, like we already have a lot of fonts under /usr/share/X11/fonts which are only used by apps using X11 core fonts. Regards, Hans
(In reply to Hans de Goede from comment #0) > It turns out that neither the new .t1 nor the new .otf file are usable as > X11 core fonts by xorg-x11-server. libXfont definitely supports loading .otf files.
Hello Hans, I have added Adam Jackson into CC, as according to his words he's "more or less the upstream for Xorg now"... :) In one of his e-mails he wrote about this BZ: "That bug is... something. libXfont has had support for .otf files in its freetype backend for a very long time (at least as of the X.org Foundation revival in late 2003, which is as far back as git history goes). Probably whatever's going wrong there is a problem in libXfont or freetype, as opposed to a problem with the font data itself." ------------- Anyway Hans, I think what you are suggesting is OK to do, with slight modifications: 1) I'll create a new subpackage for the old fonts: urw-base35-fonts-legacy (or urw-base35-fonts-legacy-x11) ... than has already retired the urw-fonts for master and f28, and after some discussion with him I have done this for f27 as well. I also prefer the option to have it all as part of one specfile - to have better control over it, and maybe even to simplify the build process. IMHO it also shouldn't create so much confusion about "what package should I install now?"... ;) 2) For now I will add the workaround for the /usr/share/X11/fonts/Type1 folder, as you suggested. But I would like to get this removed as soon as we can. For that we will need to work on point 3) and 4). 3) We should try to work with ajax to get this fixed for Xorg at some point. I expect Fedora to be switching completely to OTF/TTF support only at some point in the future. For that to be even possible we will need the Xorg to support OTF/TTF completely. 4) I will try to push upstream to fix the charmaps of OTF versions of the fonts. Are you okay with what I propose? :)
(In reply to David Kaspar [Dee'Kej] from comment #4) > Anyway Hans, I think what you are suggesting is OK to do, with slight > modifications: > > 1) I'll create a new subpackage for the old fonts: urw-base35-fonts-legacy > (or urw-base35-fonts-legacy-x11) > > ... than has already retired the urw-fonts for master and f28, and after > some discussion with him I have done this for f27 as well. > > I also prefer the option to have it all as part of one specfile - to have > better control over it, and maybe even to simplify the build process. IMHO > it also shouldn't create so much confusion about "what package should I > install now?"... ;) Ok. > 2) For now I will add the workaround for the /usr/share/X11/fonts/Type1 > folder, as you suggested. But I would like to get this removed as soon as we > can. For that we will need to work on point 3) and 4). No need to anything for that, /etc/fonts/fonts.conf already looks the way as I quoted it, sorry if I was not clear about that. > 3) We should try to work with ajax to get this fixed for Xorg at some point. > I expect Fedora to be switching completely to OTF/TTF support only at some > point in the future. For that to be even possible we will need the Xorg to > support OTF/TTF completely. > > 4) I will try to push upstream to fix the charmaps of OTF versions of the > fonts. > > Are you okay with what I propose? :) Yes, other then 2) not being necessary this sounds good. Thank you. Ajax, before we spend time going down this route, do you have time to take a quick look at what might be the problem and give us a heads up if it looks like you may be able to fix this "soonish"?
(In reply to Hans de Goede from comment #5) > Ajax, before we spend time going down this route, do you have time to take a > quick look at what might be the problem and give us a heads up if it looks > like you may be able to fix this "soonish"? Probably not going to be a quick fix, no. I'm busy with some xserver stuff and the core font code is not very high priority atm. The failure, in an immediate sense, is here: #0 FTFindSize (y_return=<synthetic pointer>, x_return=<synthetic pointer>, trans=0x7fffffffc070, face=0xb891b0) at src/FreeType/ftfuncs.c:367 #1 FreeTypeOpenInstance (load_flags=0, tmp_ttcap=0x7fffffffc260, bmfmt=0x7fffffffc748, spacing=0, trans=0x7fffffffc070, FTFileName=0xb9daa0 "/usr/share/fonts/urw-base35/NimbusRoman-BoldItalic.otf", face=0xb8d1d0, instance_return=0xb88fc0) at src/FreeType/ftfuncs.c:462 #2 FreeTypeLoadFont (font=font@entry=0xb88fc0, info=info@entry=0xb61e58, face=face@entry=0xb8d1d0, FTFileName=FTFileName@entry=0xb9daa0 "/usr/share/fonts/urw-base35/NimbusRoman-BoldItalic.otf", vals=vals@entry=0x7fffffffc818, entry=entry@entry=0xb1cad0, bmfmt=0x7fffffffc748, load_flags=0, tmp_ttcap=0x7fffffffc260, dynStrTTCapCodeRange=0x0, ttcap_spacing=0) at src/FreeType/ftfuncs.c:2903 #3 0x00007ffff7913380 in FreeTypeLoadXFont (fileName=<optimized out>, fileName@entry=0x7fffffffd097 "/usr/share/fonts/urw-base35/NimbusRoman-BoldItalic.otf", vals=vals@entry=0x7fffffffc818, xf=xf@entry=0xb61e50, info=info@entry=0xb61e58, bmfmt=bmfmt@entry=0x7fffffffc748, entry=entry@entry=0xb1cad0) at src/FreeType/ftfuncs.c:3193 #4 0x00007ffff7915452 in FreeTypeOpenScalable (fpe=<optimized out>, ppFont=0x7fffffffd9b0, flags=<optimized out>, entry=0xb1cad0, fileName=0x7fffffffd097 "/usr/share/fonts/urw-base35/NimbusRoman-BoldItalic.otf", vals=0x7fffffffc818, format=512, fmask=31, non_cachable_font=0x0) at src/FreeType/ftfuncs.c:3844 #5 0x00007ffff790cfcf in FontFileOpenFont (fpe=0xa98280, flags=flags@entry=0, name=name@entry=0xbaebf0 "-*-nimbus roman-*-*-*-*-*-*-*-*-*-*-*-*", namelen=namelen@entry=39, format=format@entry=512, fmask=31, pFont=0x7fffffffd9b0, aliasName=0x7fffffffd9b8, non_cachable_font=0x0, id=<optimized out>, client=0x83d280) at src/fontfile/fontfile.c:448 #6 0x00007ffff790d0eb in FontFileOpenFont (client=client@entry=0x83d280, fpe=<optimized out>, flags=flags@entry=0, name=name@entry=0xbaebf0 "-*-nimbus roman-*-*-*-*-*-*-*-*-*-*-*-*", namelen=namelen@entry=39, format=format@entry=512, fmask=<optimized out>, id=<optimized out>, pFont=<optimized out>, aliasName=0x7fffffffd9b8, non_cachable_font=0x0) at src/fontfile/fontfile.c:277 #7 0x00007ffff790f1d5 in CatalogueOpenFont (client=0x83d280, fpe=<optimized out>, flags=0, name=0xbaebf0 "-*-nimbus roman-*-*-*-*-*-*-*-*-*-*-*-*", namelen=39, format=512, fmask=31, id=2097244, pFont=0x7fffffffd9b0, aliasName=0x7fffffffd9b8, non_cachable_font=0x0) at src/fontfile/catalogue.c:300 #8 0x00000000004995ae in doOpenFont (client=client@entry=0x83d280, c=c@entry=0xb75960) at ../dix/dixfonts.c:277 #9 0x0000000000499a73 in OpenFont (client=0x83d280, fid=2097244, flags=0, lenfname=39, pfontname=0xa9d2b0 "-*-nimbus roman-*-*-*-*-*-*-*-*-*-*-*-*y/h\002") at ../dix/dixfonts.c:443 #10 0x000000000049739e in Dispatch () at ../dix/dispatch.c:478 #11 0x000000000049b256 in dix_main (argc=6, argv=0x7fffffffdbe8, envp=<optimized out>) at ../dix/main.c:276 #12 0x00007ffff3ff21bb in __libc_start_main () from /lib64/libc.so.6 #13 0x0000000000419f0a in _start () at ../hw/kdrive/ephyr/ephyrinit.c:51 FTFindSize() is hitting the if (trans->nonIdentity) return BadFontName; path. This seems strange to me, as one would expect pretty much any outline font to have a non-trivial transformation matrix I would think. This could just be a logic error elsewhere, or it could be actual missing support; either way that's about as far as I can investigate atm.
(In reply to Adam Jackson from comment #6) > (In reply to Hans de Goede from comment #5) > > > Ajax, before we spend time going down this route, do you have time to take a > > quick look at what might be the problem and give us a heads up if it looks > > like you may be able to fix this "soonish"? > > Probably not going to be a quick fix, no. I'm busy with some xserver stuff > and the core font code is not very high priority atm. Ok, thank you for taking a quick look. David, lets go ahead with your plan from comment #4 then.
Sorry guys for the delay, I was busy with other responsibilities. I'll look into this during this week.
The temporary workaround as we agreed is ready: https://bodhi.fedoraproject.org/updates/urw-base35-fonts-20170801-6.fc27 https://bodhi.fedoraproject.org/updates/urw-base35-fonts-20170801-9.fc28 However, it does not contain the testing version of StandardSymbolsPS.otf yet (available for testing here: https://dkaspar.fedorapeople.org/share/scratch-build/fedora/) And we still need this to be correctly fixed in X11, and better sooner than later. :)
(In reply to David Kaspar [Dee'Kej] from comment #9) > The temporary workaround as we agreed is ready: > https://bodhi.fedoraproject.org/updates/urw-base35-fonts-20170801-6.fc27 > https://bodhi.fedoraproject.org/updates/urw-base35-fonts-20170801-9.fc28 Thank you and sorry for being really slow to get around to test this. I've just finished preparing a xfig update which uses the new urw-base35-fonts-legacy package and I can confirm that this makes everything work as before in xfig. I see that this bug is now against libXfont2 to make things actually work with the new urw-fonts so that the -legacy subpackage can be dropped, so this bug should be kept open. Note if libXfont2 gets fixed and you plan to drop the -legacy subpackage, please coordinate with me as xfig now depends on the -legacy subpackage.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.