Bug 1502175

The problem is with the urw-base35 fonts which seems to remove the old urw
fonts names n019004l.afm n019004l.pfb.....etc.....This package needs to be
adopted to the new fonts.

To fix it for yourself you can put these old fonts into $user/.grace/fonts/type1
and everything should work. I am surprised that a font package is pushed
with little regard to dependencies. grace also depends on urw-fonts that needs
to change.

(In reply to Sammy from comment #1)
> The problem is with the urw-base35 fonts which seems to remove the old urw
> fonts names n019004l.afm n019004l.pfb.....etc.....This package needs to be
> adopted to the new fonts.
> 
> To fix it for yourself you can put these old fonts into
> $user/.grace/fonts/type1
> and everything should work. I am surprised that a font package is pushed
> with little regard to dependencies. grace also depends on urw-fonts that
> needs
> to change.

One also needs to copy the FontDataBase file to $user/.grace/fonts, but then everything works. Thank you!

Nothing new ? 

to work around that i did build a compatibility package on copr

https://copr.fedorainfracloud.org/coprs/baoboa/urw-fonts-compat/

the deprecation of urw-fonts is link to licensing problem, i don't know if  dkaspar (urw-base35-fonts maintainer ) could comment on that.

/usr/share/fonts/default/Type1/n019064l.afm (urw-fonts)

and

/usr/share/fonts/urw-base35/NimbusSans-BoldItalic.afm (urw-base35-nimbus-sans-fonts)

looks quite different, i don't know if it's possible to do a 100% mapping

Hello folks,

(In reply to baoboa from comment #3)
> Nothing new ? 
> 
> to work around that i did build a compatibility package on copr
> 
> https://copr.fedorainfracloud.org/coprs/baoboa/urw-fonts-compat/

Please, don't. This can cause a lot of headache and troubles not just for Fedora fonts maintainers, but also fontconfig maintainer/upstream developer, and least but not last - the users themselves.

Doing a compat package is complete step backwards, that can actually break things, and woulnd't "force" other packages to actually upgrade. And I don't wish to be held responsible for this.

It's not just that fonts were updated to a newer package, but also the fontconfig was updated in upstream to reflect to these changes.

> the deprecation of urw-fonts is link to licensing problem, i don't know if 
> dkaspar (urw-base35-fonts maintainer ) could comment on that.

Well, there were (and still are) lots of issues with urw-fonts. I am continuosly dealing with this package almost a year now.

More details for you, if you are interested:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZVKEWUFRE25HA2VFIFDPD43RDQ7XMTBX/

I was planning to finish the transition before F27, but unfortunately I got hold by my primary job responsibilites.

But it seemed that everything was working OK, because by default the software depending on fonts should used fontconfig to locate font files, rather than depending on hardcoded font paths (and expecting the fonts to stay same for eternity). Fonts evolve over time, and that's why we need fontconfig for managing them.

The latest rules if Fedora for fontconfig and urw-base35-fonts provide a backward compatibility layer, that should automatically map the old fonts names to the newer versions of the fonts, without user needed to do anything.

If these mappings are broken, then please let me know about them.

However, I think in this case the problem is in the *grace* software itself for not properly using/utilizing the fontconfig.

Even though these fonts might not look exactly the same, they all fall into PostScript Core Font Set (Level 2) category, which provides the necessary 35 fonts for correctly displaying PostScript files.

In regards the format, the *.pfb is just a compressed binary format of *.t1 (Type1) format. Upstream no longer provides the *.pfb formats.

Also, please note that Type1 is deprecated in Fedora, and I will be providing the OTF versions of these fonts soon as well. If the grace can, it should utilize the OTF format primarily. The Type1 format will be provided for some time until Ghostscript switches to OTF, which can happen anytime.

If you have any more questions, feel free to ask. :)

My plan is to finish the Fedora transition to urw-base35-fonts completely before f28-beta. The urw-fonts package is going to be dropped at the EOL of F26, and the ghostscript-fonts package should be dropped soon.

Best regards,

 -- Dee'Kej --

thanks for this detailed response, i will try to modify the grace package with symbolic link to the new fonts, if it failed i will ship the fonts directly in /usr/share/grace/fonts/.

(In reply to baoboa from comment #6)
> if it failed i will ship the fonts
> directly in /usr/share/grace/fonts/.

Please, don't do this. If possible, try to contact upstream first for them to fix the issue. Otherwise this does not follow the "upstream first" rule. I'm willing to land a hand if needed, but I'm strongly against any downstream patches. Those should be used as a last resort only.

Also note that shipping the fonts directly in the grace package is against Fedora Packaging Guidelines / Policy. See here:
https://fedoraproject.org/wiki/Packaging:Guidelines#Avoid_bundling_of_fonts_in_other_packages

*** Bug 1530000 has been marked as a duplicate of this bug. ***

Thanks baoboa, this works for me. 

I assume I can uninstall the urw-fonts-compat rpm when this eventually gets fixed?

Has anyone contacted upstream yet in order to get this properly fixed?

Somebody did so back in November:
http://plasma-gate.weizmann.ac.il/Grace/phpbb/viewtopic.php?f=6&t=3142

But... grace has had 4 releases since 2008 and is basically in maintenance mode.  Most of the fixes are build config updates to keep it chugging along the way it always has.  I don't have a lot of hope that someone is going to rewrite font handling to use fontconfig.

(In reply to Andrew Schultz from comment #11)
> Somebody did so back in November:
> http://plasma-gate.weizmann.ac.il/Grace/phpbb/viewtopic.php?f=6&t=3142
> 
> But... grace has had 4 releases since 2008 and is basically in maintenance
> mode.  Most of the fixes are build config updates to keep it chugging along
> the way it always has.  I don't have a lot of hope that someone is going to
> rewrite font handling to use fontconfig.

Hmm, OK, this is definitely problematic. This will definitely require some more digging inside how grace works to find the optimal solutin. I will try to think of something in the meantime.

But I will need to have some answers:
 * What exact format of fonts is grace expecting?
 * Does grace has capability to use uncompressed Type1 fonts? (*.pfb is basically compressed binary version of *.t1)
 * Does grace needs AFM files as well? (*.pfa is compressed binary version of AFM files)
 * Does greace expects the old fonts by the names? Or is it able to work with the new font names if they are in correct format?

Also, if grace is so old - isn't there a project which could replace its functionality?

I am the one who filed the grace bug. As far as I can tell the maintainer
does look at these so if you post these questions under my bug he most
likely will respond.

To answer your other inquiry, Grace is motif based and very solid gui driven
graphics package. There are two derivatives of grace:

qtgrace: https://sourceforge.net/projects/qtgrace/

gracegtk: https://sourceforge.net/projects/gracegtk/

These are pretty good and have more functionality but the visuals of the gui
look better for the motif grace. However, it would be very good if someone
can properly package these two alternatives.

(In reply to Sammy from comment #13)
> I am the one who filed the grace bug. As far as I can tell the maintainer
> does look at these so if you post these questions under my bug he most
> likely will respond.

Can you provide me with the link please? I don't know where to look for it. :)

That is the link in comment #11

(In reply to David Kaspar [Dee'Kej] from comment #12)
> But I will need to have some answers:

The basic answer is that grace uses t1lib to handle fonts.  t1lib requires a font database (hardcoded list of font names), which grace provides; t1lib handles the rest of the details.  The DB file includes filenames, but grace does not seem to use them.  The t1lib website seems to be half-defunct, but the t1lib-devel fedora package includes a PDF of documentation.

> Also, if grace is so old - isn't there a project which could replace its
> functionality?

As Sammy mentioned, there are ports of grace to other toolkits.  I have tried using other (more modern) scientific plotting programs, but not found any to be as useful as grace.

(In reply to Sammy from comment #15)
> That is the link in comment #11

Thanks! :) Sorry, I haven't had time to register there and ask the questions there yet.

(In reply to Andrew Schultz from comment #16)
> The basic answer is that grace uses t1lib to handle fonts.  t1lib requires a
> font database (hardcoded list of font names), which grace provides; t1lib
> handles the rest of the details.  The DB file includes filenames, but grace
> does not seem to use them.  The t1lib website seems to be half-defunct, but
> the t1lib-devel fedora package includes a PDF of documentation.
Okay, so hypothetically it should be possible for to update the DB file and have it read/loaded by t1lib for grace. We could do this with cooperation with upstream, if they will be responsive enough. :)

> As Sammy mentioned, there are ports of grace to other toolkits.  I have
> tried using other (more modern) scientific plotting programs, but not found
> any to be as useful as grace.

OK, it's a shame that grace doesn't have a bigger support in this case. But my guess is we have to keep it in Fedora as a result for now.

Recently xpdf have done such a change by modifying their font table
(see xpdf-4.0 changelog for -3 and the patch in the source). I looked
little bit to see if I can see a similar table in grace but I am not
a c programmer and gave up. I think something similar needs to be done.

The font database file in grace is (in the tarball) at fonts/FontDataBase.  This file gets read in t1fonts.c from line 97 to line 116 of t1fonts.c (function init_t1).  The fonts are mapped in the map_fonts function.

Created attachment 1382607 [details]
FontDataBase for new urw-base35 fonts

xmgrace will work with the latest urw-base35 fonts once the *.t1 files in /usr/share/fonts/urw-base35 are linked to *.pfb files and /etc/grace/FontDataBase is updated (#20) to use the new names. (The *.pfb links are needed because of t1lib requirements - it doesn't recognize *.t1 extensions.)

Because I wanted to make the least possible changes to the system provided packages, what I actually did was copy the urw-base35 *afm and *t1 files to a directory in /usr/local/, made the links between the .t1 and .pfb files, and then linked that directory to /usr/share/grace/fonts/Type1. Then in /usr/share/grace/fonts, changed the link type1 -> Type1, and changed the FontDataBase link so it points to the new version instead of /etc/grace/FontDataBase. 

As a suggestion for packaging these changes, the /usr/share/grace/fonts/type1 (or Type1) directory could be populated with the correct links to urw-base35 as part of the installation process; that is a straightforward script.

As an aside, I also have not found a good alternative to xmgrace, and would hate to have it not be supported.

(In reply to Michael Weinert from comment #21)
> As a suggestion for packaging these changes, the
> /usr/share/grace/fonts/type1 (or Type1) directory could be populated with
> the correct links to urw-base35 as part of the installation process; that is
> a straightforward script.

I can help with packaging of this. I actually use similar approach in Ghostscript, where I create the symlinks during the build phase, so they are correctly recognized by RPM (rpm -V). For that I have a build requirement on
'urw-base35-fonts-devel' subpackage, which contains an auxiliary macro %{urw_base35_fontpath} that can be used for generating the symlinks.

After that you just need to make sure you package has requirement on 'urw-base35-fonts' package... :)

https://src.fedoraproject.org/rpms/ghostscript/blob/master/f/ghostscript.spec#_336

*** Bug 1503909 has been marked as a duplicate of this bug. ***

I posted a link to this thread on the Grace development forum in case the maintainer was not aware of the issue. 

http://plasma-gate.weizmann.ac.il/Grace/phpbb/viewtopic.php?f=3&t=3285

(In reply to David Kaspar [Dee'Kej] from comment #22)
> I can help with packaging of this. I actually use similar approach in
> Ghostscript, where I create the symlinks during the build phase, so they are
> correctly recognized by RPM (rpm -V). For that I have a build requirement on
> 'urw-base35-fonts-devel' subpackage, which contains an auxiliary macro
> %{urw_base35_fontpath} that can be used for generating the symlinks.
> 
> After that you just need to make sure you package has requirement on
> 'urw-base35-fonts' package... :)
> 
> https://src.fedoraproject.org/rpms/ghostscript/blob/master/f/ghostscript.
> spec#_336

First thanks to David for dealing with general Fedora font issues, including packaging the new urw-base35 fonts, and the offer to help here. Is there someone who can/does actually do the packaging of grace?  [I'm a lowly user :), and while I can make some suggestions, I'm not competent to take this on.]

Again, in the meantime, xmgrace works (including generating eps files) on 27 with the latest urw-base35 fonts after doing the links to the font files and using the FontDataBase file I uploaded previously. (The only two changes to the installed files are changes to where the links /usr/share/grace/fonts/type1 and /usr/share/share/grace/fonts/FontDataBase point. Generating a *proper* binary package from the src rpm, however, is where I don't trust myself.)

I have implemented the above changes to my source rpm for grace that originated from some of the earlier Fedora grace srpms. I use you FontDataBase and make the changes under the comment line:
# use fonts from type1fontdir linked from urw_base35_fontpath
rm -rf fonts/type1
mkdir -p %{buildroot}%{_datadir}/%{type1fontdir}
for file in %{_datadir}/%{urw_base35_fontpath}/*.t1; do
  base=`basename $file .t1`
  ln -sf $file %{buildroot}%{_datadir}/%{type1fontdir}/$base.pfb
  ln -sf %{_datadir}/%{urw_base35_fontpath}/$base.afm %{buildroot}%{_datadir}/%{type1fontdir}/$base.afm
done
ln -s ../../%{type1fontdir} fonts/type1
cp -f %{SOURCE6} fonts/FontDataBase
mv fonts/FontDataBase %{buildroot}%{_sysconfdir}/%{name}
ln -s ../../../../%{_sysconfdir}/%{name}/FontDataBase fonts/FontDataBase

with definitions on top:
# relative to datadir
%define type1fontdir fonts/default/Type1
%define urw_base35_fontpath fonts/urw-base35

(In reply to Michael Weinert from comment #21)
> As a suggestion for packaging these changes, the
> /usr/share/grace/fonts/type1 (or Type1) directory could be populated with
> the correct links to urw-base35 as part of the installation process; that is
> a straightforward script.

I've tried this approach, and while it makes xmgrace happy, .eps files do not seem to render properly, even those produced with older versions of grace; all characters with a symbol font are missing.  To get them to show up, I have seem to need pfb->t1 symlinks in the /usr/share/fonts/urw-fonts35/.

Created attachment 1387082 [details]
patch to grace.spec

I was able to get a happy build of grace (and eps files with symbols render properly) after rebuilding with the changes in this patch.  If pfb->t1 symlinks live in the urw package, then that bit could be removed from here.

(the FontDataBase35 in the spec is attachment 1382607 [details] from comment 20)

(In reply to Andrew Schultz from comment #28)
> Created attachment 1387082 [details]
> patch to grace.spec
> 
> I was able to get a happy build of grace (and eps files with symbols render
> properly) after rebuilding with the changes in this patch.  If pfb->t1
> symlinks live in the urw package, then that bit could be removed from here.

IMHO, this looks good. However, could you please use the %{urw_base35_fontpath} macro instead of %{type1fontdir}?

The %{urw_base35_fontpath} macro is provided by the 'urw-base35-fonts-devel' package, and it provides the full-path to the fonts folder. (The *-devel supbackage will pull in all the fonts as well).

I resolve the same problem with:

yum install urw-fonts.noarch --allowerasing

Good luck!!

(In reply to Javier Lorenzo from comment #31)
> I resolve the same problem with:
> 
> yum install urw-fonts.noarch --allowerasing
> 
> Good luck!!

While that works now, the urw-fonts are the *old* (no longer supported) ones, not the urw-base fonts that replace them. The suggestions above do require some manual steps now, but have the advantage that they also provide a path forward for packaging grace (e.g., #28).

(In reply to Javier Lorenzo from comment #31)
> I resolve the same problem with:
> 
> yum install urw-fonts.noarch --allowerasing
> 
> Good luck!!

The 'urw-fonts' package is no longer supported with updates, and it will be deleted in the future versions of Fedora (you won't be able to find it in the repositories). Moreover, many applications decided to disable support for Type1 fonts, starting with LibreOffice (in Fedora 26).

(In reply to David Kaspar [Dee'Kej] from comment #30)
> (In reply to Andrew Schultz from comment #28)
> > Created attachment 1387082 [details]
> > patch to grace.spec
> > 
> > I was able to get a happy build of grace (and eps files with symbols render
> > properly) after rebuilding with the changes in this patch.  If pfb->t1
> > symlinks live in the urw package, then that bit could be removed from here.
> 
> IMHO, this looks good. However, could you please use the
> %{urw_base35_fontpath} macro instead of %{type1fontdir}?
> 
> The %{urw_base35_fontpath} macro is provided by the 'urw-base35-fonts-devel'
> package, and it provides the full-path to the fonts folder. (The *-devel
> supbackage will pull in all the fonts as well).

Also, I'm getting:
$ xmgrace 
Failed mapping a font
Failed mapping a font
Failed mapping a font
Failed mapping a font
Failed mapping a font
Failed mapping a font
Failed mapping a font
Failed mapping a font
Failed mapping a font
Failed mapping a font
Failed mapping a font
Failed mapping a font
Failed mapping a font
Failed mapping a font

Any idea why?

Could you open a pull request against the package with those changes?

(In reply to Dominik 'Rathann' Mierzejewski from comment #34)
[...]
> Also, I'm getting:
> $ xmgrace 
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> Failed mapping a font
> 
> Any idea why?

Scratch that, I had an empty FontsDataBase35 file when building locally.
Sorry for the noise.

(In reply to Andrew Schultz from comment #27)
[...]
> I've tried this approach, and while it makes xmgrace happy, .eps files do
> not seem to render properly, even those produced with older versions of
> grace; all characters with a symbol font are missing.  To get them to show
> up, I have seem to need pfb->t1 symlinks in the
> /usr/share/fonts/urw-fonts35/.

Could that be something we can fix in t1lib?

(In reply to Dominik 'Rathann' Mierzejewski from comment #36)
> (In reply to Andrew Schultz from comment #27)
> [...]
> > I've tried this approach, and while it makes xmgrace happy, .eps files do
> > not seem to render properly, even those produced with older versions of
> > grace; all characters with a symbol font are missing.  To get them to show
> > up, I have seem to need pfb->t1 symlinks in the
> > /usr/share/fonts/urw-fonts35/.
> 
> Could that be something we can fix in t1lib?

The test_for_t1_file() function at lib/t1lib/t1base.c:875 looks like the right place to start.

I did try to change test_for_t1_file() without success, so i did work with  symlink, it work approximately.

i didn't find any link to oblique courier fonts in urw-base35 , outside there is just liberation mono which is in ttf format.   

see there

https://copr.fedorainfracloud.org/coprs/baoboa/grace/

The default template is expecting some default font, i've been forced to rename some font name in FontsDataBase .

that's why we got those warning  "> Failed mapping a font"

aside of that

i did try to build a package for gtkgrace but the ./configure did not work in mock , i don't know why , i did build the package from the generated makefile.

https://copr.fedorainfracloud.org/coprs/baoboa/gracegtk/
  
hope it help

(In reply to baoboa from comment #38)
> I did try to change test_for_t1_file() without success, so i did work with 
> symlink, it work approximately.
> 
> i didn't find any link to oblique courier fonts in urw-base35 , outside
> there is just liberation mono which is in ttf format.   
> 
> see there
> 
> https://copr.fedorainfracloud.org/coprs/baoboa/grace/
> 
> The default template is expecting some default font, i've been forced to
> rename some font name in FontsDataBase .
> 
> that's why we got those warning  "> Failed mapping a font"
> 

If you use the FontDataBase from #20, you'll see that Courier oblique is mapped to NimbusMonoPS-Italic of the urw-base35 fonts. Those identifications were made by comparing the new t1 and old pfb files (which are all special PostScript files). The above FontDataBase is working for me, and for others also I believe.

To comment #38,

Regarding gracegtk, why did you build the rc0 rather than rc2? it looks
like rc3 is approaching soon. I will try the package.

Again to comment #38,

I am having rebuilding gracegtk from source rpm due to errors coming in from
linuxdoc-tools and nsgmls (in doc directory). Am I missing a dependence?

===============================
linuxdoc --language=english --papersize=letter --backend=latex --output=dvi FAQ.sgml
Processing file FAQ.sgml
nsgmls:<OSFD>0:5:8:E: document type does not allow element "ARTICLE" here; assuming missing "LINUXDOC" start-tag
nsgmls:<OSFD>0:7:8:E: document type does not allow element "TITLE" here; assuming missing "TITLEPAG" start-tag
nsgmls:<OSFD>0:8:9:E: document type does not allow element "AUTHOR" here
nsgmls:<OSFD>0:8:10:E: character data is not allowed here
nsgmls:<OSFD>0:9:7:E: document type does not allow element "DATE" here

The problem with linuxdoc is if docbook-dtds is installed it seems to mess up linuxdoc. It works if docbook-dtds is removed temporarily. This is reported in Bug #1489451.

(In reply to Sammy from comment #40)
> To comment #38,
> 
> Regarding gracegtk, why did you build the rc0 rather than rc2? it looks
> like rc3 is approaching soon. I will try the package.

I did create this package one year ago, i just rebuild it for f27 before the week-end. I should update it, but i will try to contact the author first. 

About the build, the conflict is only during the build and docbook-dtds is not part of the dependencies, build it with mock to avoid any side effect.

https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds

Thank of your interest in gtkgrace but maybe this discussion should be done in a different bug entry. -> Bug 1549084

(In reply to Dominik 'Rathann' Mierzejewski from comment #37)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #36)
> > (In reply to Andrew Schultz from comment #27)
> > [...]
> > > I've tried this approach, and while it makes xmgrace happy, .eps files do
> > > not seem to render properly, even those produced with older versions of
> > > grace; all characters with a symbol font are missing.  To get them to show
> > > up, I have seem to need pfb->t1 symlinks in the
> > > /usr/share/fonts/urw-fonts35/.
> > 
> > Could that be something we can fix in t1lib?
> 
> The test_for_t1_file() function at lib/t1lib/t1base.c:875 looks like the
> right place to start.

Indeed.  I've filed bug 1550358

It looks like package grace needs to be rebuilt with an additional requirement for the new package urw-base35-fonts-legacy, thanks.

So, this is still broken with Fedora 28 (upgraded from 27). Although I understand the benefits of having guidelines for font packaging, it is not acceptable to have a non-functional application because of all this.

(In reply to Jussi Eloranta from comment #46)
> So, this is still broken with Fedora 28 (upgraded from 27). Although I
> understand the benefits of having guidelines for font packaging, it is not
> acceptable to have a non-functional application because of all this.

It's not that simple, Jussi. The Ghostscript package (which primarily ships the fonts) depends on it, and Ghostscript (and those fonts) are used by many other packages. I can't just keep the old fonts to not break one package, and have dozen other packages misbehaving because of that...

I have even released temporary changes to partially mitigate the problems.
https://bugzilla.redhat.com/show_bug.cgi?id=1551219

Please, try not to be upset on me because some other packages that I don't own are broken, and I have fixed the packages I maintain.

Now its up to other to fix the issues / design problems other packages. (X11 needs fixing, xfig needs fixing.)

FYI, if xfig still needs the old fonts as a workaround, it can use the urw-base35-fonts-legacy subpackage to get them (urw-fonts package is not completely gone).

However, be aware that I will drop the urw-base35-fonts-legacy subpackage once the X11 Core Server is fixed. The xfig should be ready for it by that time. :)

Best regards,

 -- Dee'Kej --

José, what is the current plan with this BZ? I have done what I could on my side. Do you plan to make any more changes to grace? Or could we close this BZ? Thanks! :)

If t1lib is fixed (with a patch in bug 1550358), all that's needed for grace is to update the list of fonts.

hi guys,

I just did a summary of your work and created a PR:
 https://src.fedoraproject.org/rpms/grace/pull-request/1#

Packages can be downloaded from koji while maintainer pushes the fix.

rawhide:
 https://koji.fedoraproject.org/koji/taskinfo?taskID=27128297
f28:
 https://koji.fedoraproject.org/koji/taskinfo?taskID=27128305
f27:
 https://koji.fedoraproject.org/koji/taskinfo?taskID=27128317

Terje's build is working here.   Thanks.

I can also confirm that the package for F28 from comment 50 works and pulling urw-base35-fonts-legacy as dependency.

For F27 I have found first bug 1503909 and installed from there urw-fonts-compat-2.4-24.fc27.noarch.rpm which works, along with the native grace package from F27.

Thank all for the fixes!

I don't see the builds from Comment 50 (specifically I'm looking for the F28 build) and the new grace package doesn't seem to be in updates-testing yet for F28, although urw-base35-fonts-legacy-20170801-9.fc28.noarch.rpm is but didn't seem to be enough to fix this issue on its own.

Is the new grace package still available somewhere? Maybe I just didn't look in the right place.

Thanks.

I am sorry, koji removes builds after some days. 

No feedback from maintainer, I will to try to get W access to repo and push the update.

Note (again) as suggested in comment 49, that it would be better to fix t1lib (bug 1550358) coupled with a simple update of grace to use the new fonts than to hack the font directory with symlinks (as done in the PR)

Comment 49 is tracked in bug BZ#1593397. 

Fix for current issue will be pushed to testing today.

grace-5.1.25-12.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c996834ba0

grace-5.1.25-12.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1e56494ab2

grace-5.1.25-12.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-c996834ba0

grace-5.1.25-12.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-1e56494ab2

grace-5.1.25-12.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

grace-5.1.25-12.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.