Bug 1502175 - [grace] aborts upon startup and complains "--> Broken or incomplete installation - read the FAQ!"
Summary: [grace] aborts upon startup and complains "--> Broken or incomplete installat...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: grace
Version: 27
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Terje Røsten
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 1503909 1530000 (view as bug list)
Depends On:
Blocks: 1494563
TreeView+ depends on / blocked
 
Reported: 2017-10-14 19:43 UTC by Joachim Frieben
Modified: 2018-06-29 08:05 UTC (History)
20 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-06-25 10:54:15 UTC


Attachments (Terms of Use)
FontDataBase for new urw-base35 fonts (2.50 KB, text/plain)
2018-01-17 20:35 UTC, Michael Weinert
no flags Details
patch to grace.spec (2.72 KB, patch)
2018-01-28 05:41 UTC, Andrew Schultz
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1471223 None CLOSED Program fails to launch 2019-02-21 14:26 UTC

Internal Trackers: 1471223 1549084

Description Joachim Frieben 2017-10-14 19:43:59 UTC
Description of problem:
When launching xmgrace from the command line, it aborts and returns the message:

  "--> Broken or incomplete installation - read the FAQ!".

Version-Release number of selected component (if applicable):
grace-5.1.25-9.fc27

How reproducible:
Always

Steps to Reproduce:
1. Run "xmgrace" from the command line.

Actual results:
Program aborts and returns "--> Broken or incomplete installation - read the FAQ!".

Expected results:
xmgrace is launched successfully.

Additional info:
- There is a stale symbolic link "type1 -> ../../fonts/default/Type1" in directory /usr/share/grace/fonts.
- Issue is absent for Fedora 26.

Comment 1 Sammy 2017-10-16 22:38:53 UTC
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.

Comment 2 Richard Kalhöfer 2017-11-19 11:31:10 UTC
(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!

Comment 3 baoboa 2017-12-07 14:51:03 UTC
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@redhat.com (urw-base35-fonts maintainer ) could comment on that.

Comment 4 baoboa 2017-12-07 15:07:43 UTC
/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

Comment 5 David Kaspar [Dee'Kej] 2017-12-08 16:02:16 UTC
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@redhat.com (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 --

Comment 6 baoboa 2017-12-12 12:44:24 UTC
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/.

Comment 7 David Kaspar [Dee'Kej] 2017-12-12 14:15:48 UTC
(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

Comment 8 David Kaspar [Dee'Kej] 2018-01-02 09:09:06 UTC
*** Bug 1530000 has been marked as a duplicate of this bug. ***

Comment 9 Paul van Maaren 2018-01-06 12:56:35 UTC
Thanks baoboa, this works for me. 

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

Comment 10 David Kaspar [Dee'Kej] 2018-01-08 09:03:03 UTC
Has anyone contacted upstream yet in order to get this properly fixed?

Comment 11 Andrew Schultz 2018-01-10 14:42:16 UTC
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.

Comment 12 David Kaspar [Dee'Kej] 2018-01-10 14:54:27 UTC
(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?

Comment 13 Sammy 2018-01-10 16:21:15 UTC
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.

Comment 14 David Kaspar [Dee'Kej] 2018-01-10 16:41:31 UTC
(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. :)

Comment 15 Sammy 2018-01-10 16:52:51 UTC
That is the link in comment #11

Comment 16 Andrew Schultz 2018-01-12 04:02:27 UTC
(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.

Comment 17 David Kaspar [Dee'Kej] 2018-01-12 14:44:24 UTC
(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.

Comment 18 Sammy 2018-01-12 14:50:20 UTC
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.

Comment 19 Andrew Schultz 2018-01-12 14:56:17 UTC
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.

Comment 20 Michael Weinert 2018-01-17 20:35 UTC
Created attachment 1382607 [details]
FontDataBase for new urw-base35 fonts

Comment 21 Michael Weinert 2018-01-17 20:43:39 UTC
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.

Comment 22 David Kaspar [Dee'Kej] 2018-01-18 13:05:54 UTC
(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

Comment 23 Joachim Frieben 2018-01-22 09:09:28 UTC
*** Bug 1503909 has been marked as a duplicate of this bug. ***

Comment 24 Eric M 2018-01-22 13:54:55 UTC
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

Comment 25 Michael Weinert 2018-01-22 16:56:14 UTC
(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.)

Comment 26 Sammy 2018-01-22 17:09:13 UTC
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

Comment 27 Andrew Schultz 2018-01-28 05:33:46 UTC
(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/.

Comment 28 Andrew Schultz 2018-01-28 05:41 UTC
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.

Comment 29 Andrew Schultz 2018-01-28 05:43:19 UTC
(the FontDataBase35 in the spec is attachment 1382607 [details] from comment 20)

Comment 30 David Kaspar [Dee'Kej] 2018-01-29 11:57:21 UTC
(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).

Comment 31 Javier Lorenzo 2018-02-09 17:18:58 UTC
I resolve the same problem with:

yum install urw-fonts.noarch --allowerasing

Good luck!!

Comment 32 Michael Weinert 2018-02-09 17:32:32 UTC
(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).

Comment 33 David Kaspar [Dee'Kej] 2018-02-12 12:57:34 UTC
(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).

Comment 34 Dominik 'Rathann' Mierzejewski 2018-02-22 09:32:04 UTC
(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?

Comment 35 Dominik 'Rathann' Mierzejewski 2018-02-22 10:10:59 UTC
(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.

Comment 36 Dominik 'Rathann' Mierzejewski 2018-02-22 10:30:21 UTC
(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?

Comment 37 Dominik 'Rathann' Mierzejewski 2018-02-22 10:54:09 UTC
(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.

Comment 38 baoboa 2018-02-23 20:29:20 UTC
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

Comment 39 Michael Weinert 2018-02-24 01:37:27 UTC
(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.

Comment 40 Sammy 2018-02-24 14:26:25 UTC
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.

Comment 41 Sammy 2018-02-24 17:18:46 UTC
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

Comment 42 Sammy 2018-02-25 17:53:24 UTC
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.

Comment 43 baoboa 2018-02-26 11:21:27 UTC
(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

Comment 44 Andrew Schultz 2018-03-01 04:36:22 UTC
(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

Comment 45 Joachim Frieben 2018-04-16 12:42:04 UTC
It looks like package grace needs to be rebuilt with an additional requirement for the new package urw-base35-fonts-legacy, thanks.

Comment 46 Jussi Eloranta 2018-04-26 23:30:36 UTC
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.

Comment 47 David Kaspar [Dee'Kej] 2018-04-27 09:59:11 UTC
(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 --

Comment 48 David Kaspar [Dee'Kej] 2018-05-02 12:25:36 UTC
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! :)

Comment 49 Andrew Schultz 2018-05-02 16:16:42 UTC
If t1lib is fixed (with a patch in bug 1550358), all that's needed for grace is to update the list of fonts.

Comment 50 Terje Røsten 2018-05-22 18:23:42 UTC
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

Comment 51 l.skywalker 2018-05-29 21:14:38 UTC
Terje's build is working here.   Thanks.

Comment 52 Bogdan Costescu 2018-05-30 10:50:18 UTC
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!

Comment 53 Roderick Johnstone 2018-06-11 15:10:39 UTC
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.

Comment 54 Terje Røsten 2018-06-11 18:01:16 UTC
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.

Comment 55 Andrew Schultz 2018-06-12 02:20:42 UTC
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 56 Terje Røsten 2018-06-20 17:55:06 UTC
Comment 49 is tracked in bug BZ#1593397. 

Fix for current issue will be pushed to testing today.

Comment 57 Fedora Update System 2018-06-20 17:59:06 UTC
grace-5.1.25-12.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c996834ba0

Comment 58 Fedora Update System 2018-06-20 17:59:25 UTC
grace-5.1.25-12.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1e56494ab2

Comment 59 Fedora Update System 2018-06-21 13:41:01 UTC
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

Comment 60 Fedora Update System 2018-06-21 16:13:56 UTC
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

Comment 61 Fedora Update System 2018-06-25 10:54:15 UTC
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.

Comment 62 Fedora Update System 2018-06-29 08:05:13 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.