font display problems after chmod

Ok. It's finally time to confront this problem and attempt to resolve it.
I've been sort of limping along with improperly displaying fonts for some
time now, but now some pdf documents I really need to view are displaying
with invisible text. I need to finally figure out what is causing this
font wierdness on this Debian Sid system and try to fix it. First,
symptoms: when I use Opera browser, it displays with really wierd fonts
(e.g., something meant to look like hand written scrawl). Previously, it
displayed with more normal-looking fonts. When I try to view pdf
documents, they can appear as largely blank pages, except where, for
example, an underline occurs. This refers to the program xpdf. ps2pdf
has been failing for me as well, with output like the following:

me@mymachine:~$ ps2pdf pentateu.ps pentateu.pdf
Error: /invalidfont in findfont
Operand stack:
F0 Times-Roman Font Times-Roman 272297 Times-Roman
--nostringval-- Courier NimbusMonL-Regu (NimbusMonL-Regu)
NimbusMonL-Regu (NimbusMonL-Regu) NimbusMonL-Regu
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval--
--nostringval-- 2 %stopped_push --nostringval-- --nostringval--
--nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3
%oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2
--nostringval-- --nostringval-- --nostringval-- 2 %stopped_push
--nostringval-- --nostringval-- 2 3 %oparray_pop 3 3
%oparray_pop --nostringval-- --nostringval-- --nostringval--
--nostringval-- --nostringval-- false 1 %stopped_push 6 4
%oparray_pop --nostringval-- --nostringval-- --nostringval-- 5
-1 1 --nostringval-- %for_neg_int_continue --nostringval--
--nostringval--
Dictionary stack:
--dict:1050/1123(ro)(G)-- --dict:0/20(G)-- --dict:72/200(L)--
--dict:17/17(ro)(G)-- --dict:1050/1123(ro)(G)--
Current allocation mode is local
Last OS error: 2
Current file position is 2801
GPL Ghostscript 8.01: Unrecoverable error, exit code 1

When I try to open a pdf file with GV, I get the following:

GPL Ghostscript 8.01: Unrecoverable error, exit code 1
Error: /invalidfont in findfont
Operand stack:
--dict:7/7(L)-- F1 20 --dict:9/9(L)-- --dict:9/9(L)--
TimesNewRomanPSMT --dict:15/15(L)-- Times-Roman Times-Roman Font
Times-Roman 397215 Times-Roman --nostringval-- Courier
NimbusMonL-Regu (NimbusMonL-Regu) NimbusMonL-Regu (NimbusMonL-Regu)
NimbusMonL-Regu
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval--
--nostringval-- 2 %stopped_push --nostringval-- --nostringval--
--nostrin

Here's where I believe the source of the problem lies. Some time ago, I
was having trouble getting Mozilla browser and Firefox to run on this
machine after apt-get dist-upgrad(ing). Basically, each would segfault.
Someone advised me to run the programs through strace to see where the
problem lay ("strace mozilla" at the command line). Doing so revealed
that the segfault occurred after a certain font could not be loaded. In
good newbie fashion, I decided that some fonts I had imported into the
system had not had their permissions set corrrectly - i.e., that the
mozilla problem was traceable to newbie error. Since I had way too many
fonts to examine manually for permissions I decided I should "correct"
them en masse by cd'ing to their directory and issuing "chmod 644 * -r",
then issuing "chown root * -r" (I may have recounted those commands
slightly wrong: I did this some weeks ago and would have to execute the
steps all over again to recall precisely). I got these settings by
examining fonts at random and determining that most of them were set to
644 and owned by root. Running those commands had an adverse effect at
first since the subdirectories' permissions also got changed to 644, but
changing them back to 755 largely took care of that. But it was after
this, as I recall, that the wierd fonts began to display in Opera and I
began to get blank documents when opening pdf's using xpdf.

Let me ask: does it seem modifying font permissions and ownership as I've
done could be the source of these font display problems? If so, what are
the correct font permissions and ownership, and how should I go about
modifying them? Input will be much appreciated: this problem must finally
be confronted and resolved for this machine to fulfill my needs.

Thanks, James

PS I've learned a harsh lesson about Mozilla under Sid, it seems.
Someone from the Debian users list advised me to avoid these packages,
since they are plagued with problems. Another observed that a program
should not segfault on font problems. The first-mentioned fellow advised
me to use downloads directly from Mozilla and avoid the Debian packages.
Much as I want to avoid by-passing the package management system, it seems
like it may come to this: I simply must have a useable graphical browser
on this system. Seems like my assumption of newbie error was wrong in
this case, and that my problems were actually caused by flaky
maintainership.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: font display problems after chmod

At 03:32 PM 9/8/2004 -0500, James Miller wrote:
>Ok. It's finally time to confront this problem and attempt to resolve it.
>I've been sort of limping along with improperly displaying fonts for some
>time now, but now some pdf documents I really need to view are displaying
>with invisible text. I need to finally figure out what is causing this
>font wierdness on this Debian Sid system and try to fix it. First,
>symptoms: when I use Opera browser, it displays with really wierd fonts
>(e.g., something meant to look like hand written scrawl). Previously, it
>displayed with more normal-looking fonts. When I try to view pdf
>documents, they can appear as largely blank pages, except where, for
>example, an underline occurs. This refers to the program xpdf. ps2pdf
>has been failing for me as well, with output like the following:
>
>me@mymachine:~$ ps2pdf pentateu.ps pentateu.pdf
>Error: /invalidfont in findfont
>Operand stack:
> F0 Times-Roman Font Times-Roman 272297 Times-Roman
>--nostringval-- Courier NimbusMonL-Regu (NimbusMonL-Regu)
>NimbusMonL-Regu (NimbusMonL-Regu) NimbusMonL-Regu
>Execution stack:
> %interp_exit .runexec2 --nostringval-- --nostringval--
>--nostringval-- 2 %stopped_push --nostringval-- --nostringval--
>--nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3
>%oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2
>--nostringval-- --nostringval-- --nostringval-- 2 %stopped_push
>--nostringval-- --nostringval-- 2 3 %oparray_pop 3 3
>%oparray_pop --nostringval-- --nostringval-- --nostringval--
>--nostringval-- --nostringval-- false 1 %stopped_push 6 4
>%oparray_pop --nostringval-- --nostringval-- --nostringval-- 5
>-1 1 --nostringval-- %for_neg_int_continue --nostringval--
>--nostringval--
>Dictionary stack:
> --dict:1050/1123(ro)(G)-- --dict:0/20(G)-- --dict:72/200(L)--
>--dict:17/17(ro)(G)-- --dict:1050/1123(ro)(G)--
>Current allocation mode is local
>Last OS error: 2
>Current file position is 2801
>GPL Ghostscript 8.01: Unrecoverable error, exit code 1
>
>When I try to open a pdf file with GV, I get the following:
>
>GPL Ghostscript 8.01: Unrecoverable error, exit code 1
>Error: /invalidfont in findfont
>Operand stack:
> --dict:7/7(L)-- F1 20 --dict:9/9(L)-- --dict:9/9(L)--
>TimesNewRomanPSMT --dict:15/15(L)-- Times-Roman Times-Roman Font
>Times-Roman 397215 Times-Roman --nostringval-- Courier
>NimbusMonL-Regu (NimbusMonL-Regu) NimbusMonL-Regu (NimbusMonL-Regu)
>NimbusMonL-Regu
>Execution stack:
> %interp_exit .runexec2 --nostringval-- --nostringval--
>--nostringval-- 2 %stopped_push --nostringval-- --nostringval--
>--nostrin
>
>Here's where I believe the source of the problem lies. Some time ago, I
>was having trouble getting Mozilla browser and Firefox to run on this
>machine after apt-get dist-upgrad(ing). Basically, each would segfault.
>Someone advised me to run the programs through strace to see where the
>problem lay ("strace mozilla" at the command line). Doing so revealed
>that the segfault occurred after a certain font could not be loaded. In
>good newbie fashion, I decided that some fonts I had imported into the
>system had not had their permissions set corrrectly - i.e., that the
>mozilla problem was traceable to newbie error. Since I had way too many
>fonts to examine manually for permissions I decided I should "correct"
>them en masse by cd'ing to their directory and issuing "chmod 644 * -r",
>then issuing "chown root * -r" (I may have recounted those commands
>slightly wrong: I did this some weeks ago and would have to execute the
>steps all over again to recall precisely). I got these settings by
>examining fonts at random and determining that most of them were set to
>644 and owned by root. Running those commands had an adverse effect at
>first since the subdirectories' permissions also got changed to 644, but
>changing them back to 755 largely took care of that. But it was after
>this, as I recall, that the wierd fonts began to display in Opera and I
>began to get blank documents when opening pdf's using xpdf.
>
>Let me ask: does it seem modifying font permissions and ownership as I've
>done could be the source of these font display problems? If so, what are
>the correct font permissions and ownership, and how should I go about
>modifying them? Input will be much appreciated: this problem must finally
>be confronted and resolved for this machine to fulfill my needs.
>
>Thanks, James
>
>PS I've learned a harsh lesson about Mozilla under Sid, it seems.
>Someone from the Debian users list advised me to avoid these packages,
>since they are plagued with problems. Another observed that a program
>should not segfault on font problems. The first-mentioned fellow advised
>me to use downloads directly from Mozilla and avoid the Debian packages.
>Much as I want to avoid by-passing the package management system, it seems
>like it may come to this: I simply must have a useable graphical browser
>on this system. Seems like my assumption of newbie error was wrong in
>this case, and that my problems were actually caused by flaky
>maintainership.

First, font settings: I checked my reliable Debian-Sid workstation (that
is, the host I do not use for experimentation or development, just for
chores). Every font I checked on it -- the ones in various
/usr/X11R6/lib/X11/fonts/* directories, and the ones in /usr/share/fonts/*
directories -- is either mode 644 or mode 444, owned by root, group root.
Every subdirectory is mode 755. Since this host is about as stock a
Debian-Sid system as you can get, I suggest you rely on its settings as
correct. In any case, they match the usual settings for non-executables
that all users need access to.

You might want to be sure you fixed *all* the fonts, though.

Second, your actual problems: Since you are reporting problems with
"ps2pdf" and Ghostscript, not just Mozilla and Opera, I don't see what
leads you to "flaky maintainership" as the source of the problem. Unless, I
suppose, you think the font packages are being maintained poorly. Me, I'd
be more inclined to suspect a dependency problem.

I can't find a Debian-Sid package for ps2pdf, so for that one, please check
what package the app comes from (with "dpkg -S" followed by the FQN of the
app). Is is perhaps part of the xpdf package or one of the xpdf-* packages
in its dependencies list ... if so, the xpdf-reader package lists gsfonts
as a dependency (see discussion of ghostscript below).

Nor can I find a Debian-Sid package (at least not an *official* one) for
Opera, though in this case, I suspect there is not one, since I believe
Opera's license is not DFSG compatible. I did find a few unofficial Opera
packages, none listing ANY fonts dependencies (but since they are
unofficial, I would not trust them as much as official-package dependency
lists).

The Ghostview (gv, *not* "GV") package depends on gs (Ghostscript), which
is now in package gs-gpl. gs-gpl, lists a dependency on gsfonts; you might
want to verify that it is installed, and, if it is, that its fonts are
correctly mode'd. (The other 2 Ghostscript packages, gs-esp and gs-afpl,
appear to have the same dependency.) You might also need the current
version of gsfonts-x11 installed; I couldn't be certain from the info
"apt-cache show" reports.

Not myself being a user of Mozilla, I can't give you any real advice there.
I'm not even *sure* what specific packages you are referring to
(mozilla-browser and mozilla-firefox, I'd imagine), or how recently you did
an update/upgrade (or dist-upgrade) ... all things that matter in context.

One place to check with all of these apps is libfreetype6. This is the core
font-management library, and you might want to verify that you have the
current version installed. You might also check on fontconfig and
libfontconfig1.

As to the "advice" that ...

>Another observed that a program
>should not segfault on font problems.

.... yeah, right. And planes should take off and land on time, too. The only
segfaults you refer to are with Mozilla (the gv and ps2pdf problems are
errors but not segfaults), and you don't include the details for those (and
if you did previously, I don't remember them). A segfault here might
indicate poor error-handling code in the app, but not a loss of
functionality if the font were available. Ideally, you'd expect all errors
to be trapped in a fully-functional program ... but few applications meet
this ideal.

Closing thought: As I recall, your problems started when you made some
changes "by hand" (that is, outside the package manager) to your Debian-Sid
system. Bypassing the package manager is always risky, but unless you are
an extremely dedicated DebHead, it is occasionally necessary. The lesson
here is not to avoid such changes completely, but to make careful, detailed
notes when you do them, so you are not left trying to remember what you did
so you can undo it.I imagine a similar rule applies to other
package-management systems too.



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: font display problems after chmod

On Wed, 8 Sep 2004, Ray Olszewski wrote:

> First, font settings: I checked my reliable Debian-Sid workstation (that
> is, the host I do not use for experimentation or development, just for
> chores). Every font I checked on it -- the ones in various
> /usr/X11R6/lib/X11/fonts/* directories, and the ones in /usr/share/fonts/*
> directories -- is either mode 644 or mode 444, owned by root, group root.
> Every subdirectory is mode 755. Since this host is about as stock a
> Debian-Sid system as you can get, I suggest you rely on its settings as
> correct. In any case, they match the usual settings for non-executables
> that all users need access to.
>
> You might want to be sure you fixed *all* the fonts, though.

Hello Ray. Thanks for interjecting. I spot-checked fonts again and found
a subdirectory (under /usr/share/fonts/) owned by my user as were all the
fonts within it. I changed them all to be owned by root. It doesn't seem
to have corrected the problem: firing up xpdf to look at a file still
results in a blank document - albeit one with the correct number of pages.
Displaying with an invisible font would be the way to describe it, I
suppose. My further spot-check has revealed that all fonts seem to be
mode 644, owned by root, group root. All directories/subdirs from
/usr/share/fonts/ and /usr/X11R6/lib/X11/fonts/ on down seem to be mode
755, owned by root, group root. None of the fonts seem to be mode 444 -
likely since I changed their mode en masse earlier. Could that be causing
this sort of problem?

> Second, your actual problems: Since you are reporting problems with
> "ps2pdf" and Ghostscript, not just Mozilla and Opera, I don't see what
> leads you to "flaky maintainership" as the source of the problem. Unless, I
> suppose, you think the font packages are being maintained poorly. Me, I'd
> be more inclined to suspect a dependency problem.

Fonts were working fine - nothing unexpected or unusual - prior to running
Mozilla through strace and determining the segfault to be caused by a font
permissions problem. After I tried "correcting" what I thought was my
newbie error by changing font modes/permissions is where all problems
cropped up. From this I deduced that, had the program not segfaulted
because of a font permissions problem, I would not have been led to
correct something that was not really even amiss (mozilla-browser /
mozilla-firefox were amiss - segfaulting where they shouldn't - not my
fonts). That's the chain of logic that leads me to suspect flaky
maintainership as the ultimate source of my current problems. I'd be
happy to be proved wrong though - especially if it means being able to
view pdf's again or getting Opera to use more normal-looking fonts

> I can't find a Debian-Sid package for ps2pdf, so for that one, please check
> what package the app comes from (with "dpkg -S" followed by the FQN of the
> app). Is is perhaps part of the xpdf package or one of the xpdf-* packages
> in its dependencies list ... if so, the xpdf-reader package lists gsfonts
> as a dependency (see discussion of ghostscript below).

I'm not sure what "FQN" means. But issuing "dpkg -S ps2pdf" results in
the following output:

me@mymachine:~$ dpkg -S ps2pdf
gs-common: /usr/share/man/de/man1/ps2pdf.1.gz
xprt-common:
/usr/share/Xprint/xserver/C/print/models/PS2PDFspooldir-GS/p s2pdf_spooltodir.sh
gs-common: /usr/bin/ps2pdfwr
gs-common: /usr/bin/ps2pdf12
gs-common: /usr/bin/ps2pdf13
gs-common: /usr/bin/ps2pdf14
gs-common: /usr/share/man/man1/ps2pdf13.1.gz
gs-common: /usr/bin/ps2pdf
gs-common: /usr/share/man/de/man1/ps2pdf13.1.gz
gs-common: /usr/share/man/man1/ps2pdfwr.1.gz
gs-common: /usr/share/man/man1/ps2pdf.1.gz
gs-common: /usr/share/man/man1/ps2pdf12.1.gz
gs-common: /usr/share/man/de/man1/ps2pdf12.1.gz

Does that help?

> Nor can I find a Debian-Sid package (at least not an *official* one) for
> Opera, though in this case, I suspect there is not one, since I believe
> Opera's license is not DFSG compatible. I did find a few unofficial Opera
> packages, none listing ANY fonts dependencies (but since they are
> unofficial, I would not trust them as much as official-package dependency
> lists).

I added Opera's repository to my sources.list. But, given that Opera was
displaying normal-looking fonts previous to my attempts to "fix" my
system's fonts to suit Mozilla's odd behavior, do you think this could be
an Opera-specific problem?

> Not myself being a user of Mozilla, I can't give you any real advice there.
> I'm not even *sure* what specific packages you are referring to
> (mozilla-browser and mozilla-firefox, I'd imagine), or how recently you did
> an update/upgrade (or dist-upgrade) ... all things that matter in context.

mozilla-browser and mozilla-firefox. apt-get update(d) and apt-get
dist-upgrade(d) yesterday. I've been doing that every week or so for the
last month or two, apart from the last 10 days while I was away on
vacation.

> Closing thought: As I recall, your problems started when you made some
> changes "by hand" (that is, outside the package manager) to your Debian-Sid
> system. Bypassing the package manager is always risky, but unless you are
> an extremely dedicated DebHead, it is occasionally necessary. The lesson
> here is not to avoid such changes completely, but to make careful, detailed
> notes when you do them, so you are not left trying to remember what you did
> so you can undo it.I imagine a similar rule applies to other
> package-management systems too.

Actually, the problems started when I began doing apt-get dist-upgrade
rather than discreetly apt-get install(ing) specific programs I wanted
when there was a new release. Doing that got me a buggy X display, a
broken browser (mozilla 1.6 was working fine: 1.7 has never worked
normally, despite several upgrades) and a loss of network functionality.
I keep hoping X will return to normalcy, but it hasn't yet: I get patches
of black in colored console windows and some jumbling of lines - e.g.,
with mc. I can live with that. I've gotten network functionality
somewhat restored by creating a script that brings up the network
interface (loads the modules) when I issue it from the CLI. Both of these
inconveniences I can live with until determining how/whether to fix them.
The fonts problem has now taken top priority since, as I mentioned, I have
pdf's I need to read. I don't think I have installed any programs without
using apt. I do have some unofficial repositories in my sources.list
though - maybe 3. Opera and evolution-exchange (or something like that)
are the only 2 unofficial packages I've installed, so far as I can recall.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: font display problems after chmod

I'm afraid I have nothing targeted to add. But I've rambled a bit, and you
might find some help in the ramblings.

At 07:13 PM 9/8/2004 -0500, James Miller wrote:
>On Wed, 8 Sep 2004, Ray Olszewski wrote:
>
> > First, font settings: I checked my reliable Debian-Sid workstation (that
> > is, the host I do not use for experimentation or development, just for
> > chores). Every font I checked on it -- the ones in various
> > /usr/X11R6/lib/X11/fonts/* directories, and the ones in /usr/share/fonts/*
> > directories -- is either mode 644 or mode 444, owned by root, group root.
> > Every subdirectory is mode 755. Since this host is about as stock a
> > Debian-Sid system as you can get, I suggest you rely on its settings as
> > correct. In any case, they match the usual settings for non-executables
> > that all users need access to.
> >
> > You might want to be sure you fixed *all* the fonts, though.
>
>Hello Ray. Thanks for interjecting. I spot-checked fonts again and found
>a subdirectory (under /usr/share/fonts/) owned by my user as were all the
>fonts within it. I changed them all to be owned by root. It doesn't seem
>to have corrected the problem: firing up xpdf to look at a file still
>results in a blank document - albeit one with the correct number of pages.
>Displaying with an invisible font would be the way to describe it, I
>suppose. My further spot-check has revealed that all fonts seem to be
>mode 644, owned by root, group root. All directories/subdirs from
>/usr/share/fonts/ and /usr/X11R6/lib/X11/fonts/ on down seem to be mode
>755, owned by root, group root. None of the fonts seem to be mode 444 -
>likely since I changed their mode en masse earlier. Could that be causing
>this sort of problem?

Since the only difference between 644 and 444 is that the owner of the file
can write to it, it would be remarkable if that affected the ability of a
non-owner user to read it. (Sometimes applications will refuse to use files
that are 664 or 666, for security reasons, but I've never seen one that
will object to 644.) Anyway, I checked another host here, one I se up frrom
bare metal just recently, and all fonts on it are mode 644.

But recall that I asked a lot about the gsfonts package. Did you confirm
that it is installed and properly configured? You can check its files in
the Debian Package info at www.debian.org . Basically, it includes a bunch
of files in /usr/share/fonts/type1/gsfonts, plus a hints file in
/etc/defoma/hints/gsfonts.hintsYou might make sure all are present and have
reasonable permissions set.

> > Second, your actual problems: Since you are reporting problems with
> > "ps2pdf" and Ghostscript, not just Mozilla and Opera, I don't see what
> > leads you to "flaky maintainership" as the source of the problem. Unless, I
> > suppose, you think the font packages are being maintained poorly. Me, I'd
> > be more inclined to suspect a dependency problem.
>
>Fonts were working fine - nothing unexpected or unusual - prior to running
>Mozilla through strace and determining the segfault to be caused by a font
>permissions problem. After I tried "correcting" what I thought was my
>newbie error by changing font modes/permissions is where all problems
>cropped up. From this I deduced that, had the program not segfaulted
>because of a font permissions problem, I would not have been led to
>correct something that was not really even amiss (mozilla-browser /
>mozilla-firefox were amiss - segfaulting where they shouldn't - not my
>fonts). That's the chain of logic that leads me to suspect flaky
>maintainership as the ultimate source of my current problems. I'd be
>happy to be proved wrong though - especially if it means being able to
>view pdf's again or getting Opera to use more normal-looking fonts

Can you recall what settings (uid, gid, mode) these fonts had before you
"corrected" them? And what fonts they were -- the ones in
/usr/X11R6/lib/X11/fonts, the ones in /usr/share/fonts, or both? If they
were installed by apt-get, how did they get misset in the first place (and
the difference between what you saw and what I see here tells me they did
get misset somehow)?

Is it possible that in making the font and directory changes, you
accidentally changed something else, probably something that needs to be
755 to 644?

Do other X apps that use fonts seem to be able to access them? I don't know
what you have isntalled, so I can't be very specific here ... I have in
mind apps like xmms or xine, that make incidental use of fonts in their
display and configuration windows. (For example, if you have xmms
installed, can you change the font used in the playlist display?)

> > I can't find a Debian-Sid package for ps2pdf, so for that one, please check
> > what package the app comes from (with "dpkg -S" followed by the FQN of the
> > app). Is is perhaps part of the xpdf package or one of the xpdf-* packages
> > in its dependencies list ... if so, the xpdf-reader package lists gsfonts
> > as a dependency (see discussion of ghostscript below).
>
>I'm not sure what "FQN" means.

FQN = Fully Qualified Name. For example, /bin/bash instead of just bash.
But no matter; your approach worked and determined that the app is part of
package gs-common.

> But issuing "dpkg -S ps2pdf" results in
>the following output:
>
>me@mymachine:~$ dpkg -S ps2pdf
>gs-common: /usr/share/man/de/man1/ps2pdf.1.gz
>xprt-common:
>/usr/share/Xprint/xserver/C/print/models/PS2PDFspooldir-GS/ ps2pdf_spooltodir.sh
>gs-common: /usr/bin/ps2pdfwr
>gs-common: /usr/bin/ps2pdf12
>gs-common: /usr/bin/ps2pdf13
>gs-common: /usr/bin/ps2pdf14
>gs-common: /usr/share/man/man1/ps2pdf13.1.gz
>gs-common: /usr/bin/ps2pdf
>gs-common: /usr/share/man/de/man1/ps2pdf13.1.gz
>gs-common: /usr/share/man/man1/ps2pdfwr.1.gz
>gs-common: /usr/share/man/man1/ps2pdf.1.gz
>gs-common: /usr/share/man/man1/ps2pdf12.1.gz
>gs-common: /usr/share/man/de/man1/ps2pdf12.1.gz
>
>Does that help?

Well, it tells me that the relevant package to check is gs-common. Checking
its dependencies (with apt-cache show) tells me that they include gsfonts
and defoma. defoma is the Debian Font Manager. I've never paid any
attnetion to this app before ... here, it's always done its jobs politely
and unassumingly ... but you may want to investigate whether whatever you
did when you tried to repair things by hand somehow caused a problem here.
All I can do beyond that general observation is read the man page, though,
and you can do that as well as I.

> > Nor can I find a Debian-Sid package (at least not an *official* one) for
> > Opera, though in this case, I suspect there is not one, since I believe
> > Opera's license is not DFSG compatible. I did find a few unofficial Opera
> > packages, none listing ANY fonts dependencies (but since they are
> > unofficial, I would not trust them as much as official-package dependency
> > lists).
>
>I added Opera's repository to my sources.list. But, given that Opera was
>displaying normal-looking fonts previous to my attempts to "fix" my
>system's fonts to suit Mozilla's odd behavior, do you think this could be
>an Opera-specific problem?
>
> > Not myself being a user of Mozilla, I can't give you any real advice there.
> > I'm not even *sure* what specific packages you are referring to
> > (mozilla-browser and mozilla-firefox, I'd imagine), or how recently you did
> > an update/upgrade (or dist-upgrade) ... all things that matter in context.
>
>mozilla-browser and mozilla-firefox. apt-get update(d) and apt-get
>dist-upgrade(d) yesterday. I've been doing that every week or so for the
>last month or two, apart from the last 10 days while I was away on
>vacation.

I should have asked this before: Is apt-get dist-upgrade exiting normally
or is it reporting problems? I've assumed a normal exit, but I should learn
not to make excessive assumptions when I can easily ask.

Also, apt-get's installer usually asks if you want to update or retain a
lot of site-specific stuff. Are you possibly keeping some old config file
that is introducing a problem? (Since I've no real idea what you have on
your system, I can't be very specific here.)

> > Closing thought: As I recall, your problems started when you made some
> > changes "by hand" (that is, outside the package manager) to your Debian-Sid
> > system. Bypassing the package manager is always risky, but unless you are
> > an extremely dedicated DebHead, it is occasionally necessary. The lesson
> > here is not to avoid such changes completely, but to make careful, detailed
> > notes when you do them, so you are not left trying to remember what you did
> > so you can undo it.I imagine a similar rule applies to other
> > package-management systems too.
>
>Actually, the problems started when I began doing apt-get dist-upgrade
>rather than discreetly apt-get install(ing) specific programs I wanted
>when there was a new release. Doing that got me a buggy X display, a
>broken browser (mozilla 1.6 was working fine: 1.7 has never worked
>normally, despite several upgrades)

I don't have it here to check, but in a quick scan of the package contents
in mozilla-browser, the one that catches my eye is

/usr/share/doc/mozilla-browser/enabling_truetype.html

I don't know what actual fonts you are using, but it might benefit you to
see what that instruction set says.

>and a loss of network functionality.
>I keep hoping X will return to normalcy, but it hasn't yet: I get patches
>of black in colored console windows and some jumbling of lines - e.g.,
>with mc. I can live with that.

Was this a side effect of a kernel upgrade? Or did an xfree86-xserver
upgrade cause the XF86Config-4 file to be rewritten (had you made changes
by hand to it that got lost)?

Moreover ... if you are having problems with X, is it possible that xfs
(the X font server) is also having problems? Is the process even running?

>I've gotten network functionality
>somewhat restored by creating a script that brings up the network
>interface (loads the modules) when I issue it from the CLI.

How had you been doing this before the dist-upgrade? If you did it by way
of entries in /etc/modules (the simplest way), and the module names did not
change, I'm very surprised that they are not loading now.

>Both of these
>inconveniences I can live with until determining how/whether to fix them.
>The fonts problem has now taken top priority since, as I mentioned, I have
>pdf's I need to read. I don't think I have installed any programs without
>using apt. I do have some unofficial repositories in my sources.list
>though - maybe 3. Opera and evolution-exchange (or something like that)
>are the only 2 unofficial packages I've installed, so far as I can recall.



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: font display problems after chmod

On Wed, 8 Sep 2004, Ray Olszewski wrote:

> But recall that I asked a lot about the gsfonts package. Did you confirm
> that it is installed and properly configured? You can check its files in
> the Debian Package info at www.debian.org . Basically, it includes a bunch
> of files in /usr/share/fonts/type1/gsfonts, plus a hints file in
> /etc/defoma/hints/gsfonts.hintsYou might make sure all are present and have
> reasonable permissions set.

I did check permissions for all subdirs and some font files under
/usr/share/fonts/type1/ and they were ok. I'll look into gsfonts a bit
more - had trouble understanding what you said about that, so I did not
answer.

> Can you recall what settings (uid, gid, mode) these fonts had before you
> "corrected" them? And what fonts they were -- the ones in
> /usr/X11R6/lib/X11/fonts, the ones in /usr/share/fonts, or both? If they
> were installed by apt-get, how did they get misset in the first place (and
> the difference between what you saw and what I see here tells me they did
> get misset somehow)?

I did not fiddle with anything under /usr/X11R6/lib/X11/fonts, only with
those under /usr/share/fonts. As I recall, mode was set to 444 on some,
and ownership was my user rather than root. These fonts were not
installed by apt-get but rather, as I mentioned earlier, were transferred
from another (Windows) system or downloaded from the 'net. Somehow, I
determined this is where they should go. That they should have weird
permissions (a newbie having placed them there) is thus not out of order.

> Is it possible that in making the font and directory changes, you
> accidentally changed something else, probably something that needs to be
> 755 to 644?

I don't think so. As I mentioned, I had initially erroneously changed
some subdirs to mode 644, but I corrected that (no fonts were working
after I did that, so it was a necessary fix). I've rechecked mode and
permissions 2 or 3 times now, and all seems to be in order. But I suppose
I should check again, since it sounds like some really simple basic thing
is wrong and I'm somehow overlooking it.

> Do other X apps that use fonts seem to be able to access them? I don't know
> what you have isntalled, so I can't be very specific here ... I have in
> mind apps like xmms or xine, that make incidental use of fonts in their
> display and configuration windows. (For example, if you have xmms
> installed, can you change the font used in the playlist display?)

I don't have xmms installed. I tried creating a new OpenOffice document
and using random fonts (6 or so). They all appeared correctly, in accord
with the font face selected. Does that help?

> I should have asked this before: Is apt-get dist-upgrade exiting normally
> or is it reporting problems? I've assumed a normal exit, but I should learn
> not to make excessive assumptions when I can easily ask.

libdiscover1 gets held back. I thought that got straightened out in a
previous apt-get dist-upgrade, but just now trying it reveals it's still
being held back. Other than this, it seems to complete successfully.

> Also, apt-get's installer usually asks if you want to update or retain a
> lot of site-specific stuff. Are you possibly keeping some old config file
> that is introducing a problem? (Since I've no real idea what you have on
> your system, I can't be very specific here.)

Not that I can think of. But I should probably ponder that a bit more.

> I don't have it here to check, but in a quick scan of the package contents
> in mozilla-browser, the one that catches my eye is
>
> /usr/share/doc/mozilla-browser/enabling_truetype.html
>
> I don't know what actual fonts you are using, but it might benefit you to
> see what that instruction set says.

Ok. I'll look. I should mention that, though I may have confused things
a bit by speaking alot about Mozilla, it now works to some degree - at
least in the sense that fonts don't cause it to segfault. It does,
occassionally disappear on normal use (segfault, I guess) and will
predictably fail when I try to view my Freesco router's admin page on the
local network as soon as I move the cursor over the "login" link. But as
far as fonts not rendering, the apps that give me the most trouble since I
"fixed" font modes are xpdf/gv and Opera. Opera is at least useable -
though very difficult to read pages in the weird font faces it uses. The
pdf viewers are not cooperative, as I mentioned earlier. So, Mozilla
figures in as having possibly precipitated the problem by segfaulting on a
fonts permission issue. Resetting mode made Mozilla work somewhat more
normally, but fouled up the other apps. This probably sounds as
hopelessly confusing to you as it does to me as I write it.

> Was this a side effect of a kernel upgrade? Or did an xfree86-xserver
> upgrade cause the XF86Config-4 file to be rewritten (had you made changes
> by hand to it that got lost)?

XF86Config-4 remained - no changes to it were lost. I just began to get
screen jumbling in some console programs I use regularly - namely mc and
Pine (oops, another unofficial package I have installed).

> Moreover ... if you are having problems with X, is it possible that xfs
> (the X font server) is also having problems? Is the process even running?

Top tells me xfs is running, yes.

> How had you been doing this before the dist-upgrade? If you did it by way
> of entries in /etc/modules (the simplest way), and the module names did not
> change, I'm very surprised that they are not loading now.

I told Debian what NIC I had and that I wanted dhcp to run on it when I
did the installation and it apparently set it up in some config file. It
brought up the network fine on bootup for some time. I seem to have lost
that file when I got a kernel upgrade with an apt-get dist-upgrade I ran.
I posted about that to the list a couple of months ago, but the results
were inconclusive.

Thanks for trying to help.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs