Bug 691990 - How do I fix gs 9.01 "Warning: the Xfonts feature is deprecated and will be removed in a future release."
Summary: How do I fix gs 9.01 "Warning: the Xfonts feature is deprecated and will be r...
Status: RESOLVED WONTFIX
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Font API (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-21 00:50 UTC by William Bader
Modified: 2011-02-22 02:30 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William Bader 2011-02-21 00:50:27 UTC
I built gs 9.01 with the same script on several versions of Linux.
On some, but not all, of the Linux systems, gs displays "Warning: the Xfonts feature is deprecated and will be removed in a future release."

In the short term, the message is a problem because I usually run gs through gv, and when gs generates messages, gv opens an error window that takes a click to close.  This makes the message very annoying to anyone who views postscript through a front-end like gv.

In the long term, I think that the message is saying that gs pulled a font from the X server instead of from a font directory.  When I run "gs -h", on all of my Linux systems, the directory list includes the directory where I unpacked ghostscript-fonts-std-8.11.tar.gz.  On the Linux systems where I get the message, when I display the colorcir.ps example, the letters run into each other.

When I add -dNOPLATFONTS to the gs command line, I don't get the warning, and the letters at the bottom of colorcir.ps are OK.

Is adding -dNOPLATFONTS to gv the solution to the warning?

Does the deprecation warning mean that a future version of gs will run as if it was hard-coded with -dNOPLATFONTS?

William
Comment 1 Chris Liddell (chrisl) 2011-02-21 08:21:06 UTC
First ghostscript-fonts-std-8.11.tar.gz is outdated, and you should use the fonts included with the Ghostscript release (in Resource/Font).

Second, yes -dNOPLATFONTS is an acceptable way to prevent GS from trying to load platform dependent fonts (in this case, as you surmise, fonts from the X server).

Thirdly, it is planned that the Xfonts (eXternal fonts) feature will be removed completely in a near future release (within the next year). There have been numerous quality and compatibility problems with Xfonts, some of which might be soluble, but at least some of which are totally outside our control, thus it was felt that the best strategy would be to remove the feature.

But we recognise that removing a feature is not something to be done lightly, so I felt that an (intentionally!) annoying warning message would ensure that anyone using Xfonts would now be aware that was the case, and more importantly, anyone whose application relied on Xfonts behaviour would have a chance to make a case which might change our plans.
Comment 2 William Bader 2011-02-21 14:42:46 UTC
Thanks for the explanation.

When I add directories to the font search path with -I on the gs command line, is there a way to add directories to the end of the path?

When "gs -h" says "Initialization files are compiled into the executable.", does that include all of Resource or only Resource/Init?
My gs executable is 16 MB stripped, while "du --hum --sum Resource/Font" returns 3.3 MB.
Comment 3 Chris Liddell (chrisl) 2011-02-21 15:01:59 UTC
(In reply to comment #2)
> Thanks for the explanation.
> 
> When I add directories to the font search path with -I on the gs command line,
> is there a way to add directories to the end of the path?

I don't believe so, I believe user values take precedence over default "built-in" ones.

> When "gs -h" says "Initialization files are compiled into the executable.",
> does that include all of Resource or only Resource/Init?
> My gs executable is 16 MB stripped, while "du --hum --sum Resource/Font"
> returns 3.3 MB.

Everything under Resource/* is compiled in - this is to make it simpler to get a functioning default build, because there is no need to specify search paths just to get something to run.

./configure --disable-compile-inits (or editing the makefile setting of COMPILE_INITS) should disable this, but you then will need to ensure that Ghostscript can find it's various resource files before it will run correctly.
Comment 4 William Bader 2011-02-21 20:25:06 UTC
>Everything under Resource/* is compiled in

Thanks.
gs -h returns
%rom%Resource/Init/ : %rom%lib/ : ... : /usr/local/share/ghostscript/9.01/Resource/Font : ...
so I was under the impression that the lack of %rom%Resource/Font/ or other directories under %rom%Resource/ and the references to subdirectories of /usr/local/share/ghostscript/9.01/Resource meant that not everything under Resource/* was compiled in.

Are there any files outside Resource/* that still must be distributed?
For example, base/unixinst.mak copies iccprofiles.

William
Comment 5 Chris Liddell (chrisl) 2011-02-21 20:44:46 UTC
The executable should have everything needed to run: init files, the pdf interpreter files, the fonts, the other PS resources, the icc profiles.....

I haven't looked at the install targets, but I don't see where it copies the icc profiles, unless COMPILE_INITS=0.
Comment 6 William Bader 2011-02-22 02:30:19 UTC
>The executable should have everything needed to run

Thanks!  That is perfect.  I didn't realize that it had everything.