I have a Bash script that writes a text watermark to PDF files. It does this by generating an overlay PDF with Ghostscript and then using PDFtk to stamp the overlay onto the original.
All this works perfectly, except that Ghostscript is not writing accented characters correctly. If my input text is, for example, "Français", the output on the PDF will be "Franˆ§ais".
My Ghostscript command line is:
/usr/local/bin/gs -q -o "${TEMPFILE}" \
-sDEVICE=pdfwrite -sPAPERSIZE=letter \
-c "60 23 moveto 0.32 0.23 0.22 setrgbcolor /Helvetica-Oblique findfont 9 scalefont setfont (${WATERMARK}) show"
The $WATERMARK variable contains a single line of text to be written. The problem occurs both when running the Bash script that contains this line and also when I run just this command directly.
I'm seeing this problem using Ghostscript 9.06 on Mac OS X (installed via Homebrew) and 9.05 on Ubuntu 12.04 (installed from the Ubuntu package repository). The Bash script and gs command line were both written by someone else; I have no experience using Ghostscript myself.
Changing the font has no effect on the problem and I've been unable to google anything useful related to this. What are we doing wrong here?
Thanks.
You haven't encoded the font correctly (or indeed at all).
You are assuming that the character code which represents the glyph named ccedilla is the same in the font as it is on your computer system. For Latin fonts, and the ASCII characters up to 127 this is usually true, for characters beyond that it usually isn't and for non-Latin languages (eg Russian, Arabic, CJKV languages, etc) it isn't true at all.
Encoding fonts isn't hard, but it is rather lengthy to go into here, so instead let me recommend the excellent series of articles written by John Deubert of Acumen Training, you can find them here:
http://www.acumentraining.com/acumenjournal.html
For your purposes I suggest the November and December 2001 articles.
Related
I am using pstoedit as a part of a shell script to convert svg to dxf.
When I use pstoedit -psarg '-dNOSAFER' -dt -f 'dxf: -mm' "${epsfile}" "${dxffile}" in script, the result is like the picture below.
But when i use pstoedit -psarg '-dNOSAFER' -dt -f 'dxf_14: -mm' "${epsfile}" "${dxffile}" the result is like the picture below.
See the difference? dxf gives complete lines, but dxf_14 gives small lines not connected. I read pstohedit -help and it mentions to use dxf_14 because it's newer, but I can't if it's going to produce results like this.
I also see a bunch of options specific to dxf_14, but I'm not sure what to use. Can anyone guide me on what switches to use for dxf_14 to get desired result, like the first picture above?
PS. I'm using Inkscape to create svg and then the script converts svg to eps using inkscape cli and the pstoedit is used to convert eps to dxf, if it helps.
PS2. pstoedit version is pstoedit: version 3.74 / DLL interface 108 (built: Oct 31 2019 - release build - g++ 9.2.0 - 64-bit)
I developing pdf conversion app with node.js and Ghostscript. I execute command line gs with exec(). My command definition looks like:
let gs_cmd = `
gs -sDEVICE=pdfwrite \
-dPDFX=true \
-dPDFACompatibilityPolicy=1 \
-sColorConversionStrategy=/CMYK \
-sProcessColorModel=DeviceCMYK \
-sDefaultCMYKProfile=${icc_profile_file} \
-dNoOutputFonts \
-dBATCH \
-dQUIET \
-r${DPI} \
-g${w}x${h} \
-dPDFFitPage \
-NumRenderingThreads=4 \
-o ${target_file}-conv.pdf \
PDFX_def.ps \
#trimbox.in "Trimed" \
${target_file}.pdf
`;
I have problem with line:
#trimbox.in "Trimed" \
which tells to Ghostscript to include file and pass the parameters to in. I can't find a proper way to include parameters that can be used in included file. I want to pass "Trimed" string as $0 argument which will be available in trimbox.in file. I also tried with -t=Trimmed or -t="Trimmed" without effects.
From Ghostscript docs (section 10.1):
#filename
Causes Ghostscript to read filename and treat its contents the same as the command line. (This was intended primarily for getting around DOS's 128-character limit on the length of a command line.) Switches or file names in the file may be separated by any amount of white space (space, tab, line break); there is no limit on the size of the file.
-- filename arg1 ...
-+ filename arg1 ...
Takes the next argument as a file name as usual, but takes all remaining arguments (even if they have the syntactic form of switches) and defines the name ARGUMENTS in userdict (not systemdict) as an array of those strings, before running the file. When Ghostscript finishes executing the file, it exits back to the shell.
How to achieve this?
Running my command causes error:
Error: /undefined in Trimed
Firstly you should review the Ghostscript licence to ensure your use is compliant with the licence (AGPL v3). Note that this includes software as a service applications.
"Trimed" isn't a Ghostscript switch and it isn't the name of an input file, so yes, you get an error. You can't 'pass parameters' to #file, because Ghostscript treats that, literally, as a file containing a bunch of switches. There is no command substitution or anything like that. SO you can't have $0 in the file specified by #file.
So when you say :
#PDFX_def_trimbox.ps "Trimed" \
which tells to Ghostscript to include file and pass the parameters to
in
I'm afraid you are incorrect. There is no way to 'pass parameters' to the file when using the #file syntax.
You haven't said what's in the file 'PDFX_def_trimbox.ps', and I'm suspicious (because of the .ps) that this is a PostScript program. You can't use a PostScript program with the #file syntax, because a PostScript program is not a series of Ghostscript switches.
So where you have :
-sDEVICE=pdfwrite \
-dPDFX=true\
etc, you could put all of those switches into the file specified by #file. But you can't put any PostScript in there.
There are a few other problems. You have specified NumRenderingThreads=4, which will do nothing, because the pdfwrite device doesn't (in general) do any rendering, it preserves the input as far as possible as vector data. So pdfwrite ignores this parameter altogether.
For similar reasons, the -r parameter is less than useful. In the case of pdfwrite that simply affects how accurate the conversion is. You shouldn't set that without good reason.
You've set -sColorConversionStrategy=/CMYK when it should be =-sColorConversionStrategy=CMYK or -dColorConversionStrategy=/CMYK. -s takes strings, -d takes numbers or names.
-g sets teh widht and height of the page in pixels, which isn't a great plan, that depends on the resolution. You should -dDEVICEWIDTHPOINTS and -dDEVICEHEIGHTPOINTS instead, and not set the resolution.
-EDIT-
-response to comment below-
If you want PDF file to contain a 300 dpi image, then you need to create a page which is the correct size so that, when drawn on it, the bitmap data form the image is 300 dpi.
So for example, if you have an image which is 600 pixels by 900 pixels, then in order to get that to be 300 dpi you must make the media size 2 inches by 3 inches, which is 144 by 216 points. Changing the resolution of the pdfwrite device won't affect that at all. Setting -g and -r will alter the media size, but not the resolution of the image, though if you also set -dPDFFitPage then yes it will rescale the image to fit the media, which will alter its resolution.....
I have no idea if your original image was 300 dpi, if it was, and the SVG to PDF conversion maintained that, then you don't need to mess about with media sizes and resolution at all, the pdfwrite device will maintain whatever was there.
As regards the #file syntax, you cannot do this:
-c "[ {ThisPage} << /TrimBox [$0 $1 $2 $3] >> /PUT pdfmark"
in the file supplied via the # comamnd because, as I said, there is no variable replacement in the processing which Ghostscript does on the contents of that file. This is not a bash script.
I have installed MATLAB R2008b on Ubuntu 12.04.4 LTS and Windows XP.
The system locale in Ubuntu is Unicode - en_US.UTF-8.
For compatibility with Windows I launch MATLAB in Ubuntu with ru_RU.CP1251 locale - so I have simple script to launch MATLAB:
cat /opt/MATLAB_R2008b/bin/matlab-run
#!/bin/bash
export LANG="ru_RU.CP1251";
export LC_ALL="ru_RU.CP1251";
/opt/MATLAB_R2008b/bin/matlab -desktop
After that slCharacterEncoding and feature('DefaultCharacterSet') returns desired windows-1251 as expected.
There are many fonts in my system, almost all support Russian (Cyrillic) glyphs.
Russian text displays normally in uicontrol (see screenshot )
uicontrol('String','Русский=Russian','Position',[0 0 200 200])
but does not in figure labels and title, so
x = linspace(0,2*pi,100); y = sin(x);
xlabel('x, в радианах','interpreter','none');
ylabel('y, значение sin(x)','interpreter','none');
title('y, значение sin(x)','interpreter','none');
produce wrong characters in labels and title .
I have no idea how to fix this.
How should I setup MATLAB for correct display of Russian (Cyrillic) characters on figures in Linux?
I solved my problem.
I installed all recommended fonts - packages xfonts-100dpi, xfonts-75dpi, xfonts-cyrillic, t1-cyrillic, cm-super, ttf-freefont, gsfonts-x11.
But what is interesting these fonts work only for UTF-8, so I can use the following fonts for displaying Russian (Cyrillic) text in figures:
clean
free avant garde
free bookman
free chancery
free courier
free helvetian
free paladin
free schoolbook
free times
oldslavic
tahoma guap
teams
terminus
For my original problem I found special ttf-font file, which works as expected and Russian (Cyrillic) text looks as expected in CP/Windows-1251 charset.
I placed this font in /usr/local/share/fonts/truetype, ran mkfontscale, mkfontdir and fc-cache -vf and added this location to /etc/X11/xorg.conf:
Section "Files"
FontPath "/usr/share/fonts/truetype"
FontPath "/usr/local/share/fonts/truetype"
EndSection
.
I installed language-pack-ru and edited /var/lib/locales/supported.d/local as follows:
en_US.UTF-8 UTF-8
ru_RU ISO-8859-5
ru_RU.CP1251 CP1251
ru_RU.KOI8-R KOI8-R
How to make Times working for printing under linux?
I have debian wheezy linux, ghostscript, cups, mscorefonts installed.
But when i do print, i get Times too wide, comparing to windows one -- letter spacing are too wide.
Any way to fix that problem?
Printing done from same Java applet and on Win and on Lin.
Postscript from Lin variant use Times fonts, postscript from Win variant uses TimesNewRomanPSMT font.
Just replacement font name changes it, but not changes anything in output.
=================
Debian Wheezy, Debian Squeeze, Ubuntu Natty checked as linux.
Most of checks was in Debian Wheezy.
ghostscript:
Installed: 9.02~dfsg-2
sun-java6-jre:
Installed: 6.26-1
cups-pdf printer.
PPD is PDF.ppd:
*PCFileName: "CUPS-PDF.PPD"
*Manufacturer: "Generic"
*Product: "(CUPS v1.1)"
*ModelName: "Generic CUPS-PDF Printer"
*ShortNickName: "Generic CUPS-PDF Printer"
*NickName: "Generic CUPS-PDF Printer"
*1284DeviceID: "MFG:Generic;MDL:CUPS-PDF Printer;DES:Generic CUPS-PDF Printer;CLS:PRINTER;CMD:POSTSCRIPT;"
Print result Comparsion: http://piccy.info/code2/1652248/4b2c3b10f5316f9836496af5501892d1/
I DO have Times New Roman font on linux system! PDF for windows was generated on linux with linux ghostscript from postscript source generated on windows machine.
For example, take a look into right upper corner, where 0401060 written.
Windows postscript code:
%%IncludeResource: font TimesNewRomanPS-BoldMT
F /F1 0 /256 T /TimesNewRomanPS-BoldMT mF
/F1S53 F1 [83 0 0 -83 0 0 ] mFS
F1S53 Ji
4292 333 M (0401060)[42 42 42 42 42 42 0]xS
N 367 367 M 1192 367 I K
N 1667 367 M 2492 367 I K
51282 VM?
linux postscript code:
10.0 29 F
<303430313036> 37.44 526.0 52.0 S
10.0 29 F
<30> 6.24 541.0 62.0 S
N
as you can see, it selects font #29 of size 10.0. Font #29 is
/Times-Bold ISOF
and, worst thing, it already writes two lines -- so problem are somewhere in java<=>cups connector.
==================
"Same Java Applet" is internet-bank application iBank2.
"Times" is substituted by Ghostscript to Nimbus, not to TimesNewRoman:
./Init/Fontmap.GS:/Times-Roman /NimbusRomNo9L-Regu ;
./Init/Fontmap.GS:/Times-Italic /NimbusRomNo9L-ReguItal ;
./Init/Fontmap.GS:/Times-Bold /NimbusRomNo9L-Medi ;
./Init/Fontmap.GS:/Times-BoldItalic /NimbusRomNo9L-MediItal ;
./Init/Fontmap.GS:/TimesNewRoman /TimesNewRomanPSMT ;
./Init/Fontmap.GS:/TimesNewRoman,Bold /TimesNewRomanPS-BoldMT ;
./Init/Fontmap.GS:/TimesNewRoman,Italic /TimesNewRomanPS-ItalicMT ;
./Init/Fontmap.GS:/TimesNewRoman,BoldItalic /TimesNewRomanPS-BoldItalicMT ;
(BTW, are you using Ghostscript on Windows at all, or is your printing there going through a native printer driver?)
On windows i'm print onto PostScript native driver to .ps file.
So it is NOT a Ghostscript problem per se... but it maybe originating from different Java versions + configurations on your Win/Lin systems.
It looks like problem in java on printing, but that doesn't depends on java version -- both have latest java6 installed.
That PostScript most likely generated by your Java applet, and Ghostscript is only the consumer of it when it goes through the printing process.
Normally, i just want to make sure it uses TimesNewRoman font for Times one, not Nimbus.
And i have failed to make this.
ISOF macro generated by printing is:
/ISOF {
dup findfont dup length 1 add dict begin {
1 index /FID eq {pop pop} {D} ifelse
} forall /Encoding ISOLatin1Encoding D
currentdict end definefont
} BD
Here is cut of start files, and generated resulting PDF: http://datacompboy.ru/u/smpl.tar.bz2
If this is so, then copy the Windows fontfile to Linux.
it are already copy of windows file. msttcorefonts are identical to one, distributed with windows.
Since in generated postscript file already 0401060 split to two lines, that means, that java applet are while printing found that font too wide, and split upon generating... So question is -- how to substitute Times font in system so, that java printing will find TimesNewRoman instead of Nimbus, and generate correct output?
From what I see in the screenshot, your Win <--> Lin printing differences...
...do NOT originate in Times <--> TimesNewRomanPSMT differences,
...but rather come from [SomeTimes] <--> [SomeTimesBold] differences in the 2 PostScript output(s)
that is consumed by each printer queue (which on Linux very likely involves a Ghostscript installation). (BTW, are you using Ghostscript on Windows at all, or is your printing there going through a native printer driver?)
So it is NOT a Ghostscript problem per se... but it maybe originating from different Java versions + configurations on your Win/Lin systems.
The fact that your Linux PostScript code seems to make use of the /Times-Bold (ISOF????) font is outside of Ghostscript's responsibility. That PostScript most likely generated by your Java applet, and Ghostscript is only the consumer of it when it goes through the printing process.
It looks to me that this ominous ISOF you mentioned is not part of the fontname, but a PostScript procedure that must be pre-defined elsewhere in the PostScript file and is applied to the /Times-Bold font. It is probably a procedure which re-encodes the original font to ISOLatin1Encoding...
You say you have access to both font files (TimesNewRomanPS-BoldMT on Windows and Times-Bold on Linux). If this is so, then copy the Windows fontfile to Linux. Then, to verify the visual differences between the two fonts, run these two commands on each of the fontfiles:
fntsample \
-f /path/to/Times-fontfile.suffix \
-o Times-fontfile.suffix.pdf \
-l \
> Times-fontfile.suffix.txt
and then
pdfoutline \
Times-fontfile.suffix.pdf \
Times-fontfile.suffix.txt \
Times-fontfile-sample.pdf
The resulting PDF(s), Times-fontfile-sample.pdf, will represent a tabular sample of each glyph contained in the fontfiles, and these will be mapped to the respective Unicode codepoints sections.
You can use these PDFs to reveal even minimal visual discrepancies between the two fonts (but I bet your differences will be rather glaring).
In case you don't have installed pdfoutline and fntsample in your Debian, just run sudo apt-get install fntsample...
Update 2 (taking into account the updated problem description):
datacompboy has now provided a tarball containing these 4 files:
-rw-r--r-- datacompboy/datacompboy 37722 2011-06-22 08:54 smpl/linout.ps
-rw-r--r-- datacompboy/datacompboy 15324 2011-06-22 08:54 smpl/linout.pdf
-rw-r--r-- datacompboy/datacompboy 54422 2011-06-22 08:57 smpl/winout.pdf
-rw-r--r-- datacompboy/datacompboy 99099 2011-06-22 08:56 smpl/winout.ps
With these files, it should be very easy to pinpoint the cause of the problem. If datacompboy can run the Windows-generated PS file on a Linux Ghostscript, like this:
gs winout.ps
and if it renders OK (i.e.: the same as winout.pdf), then there is no problem with the GS font mapping, but a problem with the actual file differences in winout/linout.ps. From there, it should be quite easy to continue the analysis.
Unfortunately, right now I cannot run the test myself.
Update 3:
datacompboy's PDF files linout.pdf and winout.pdf have one huge difference: the Linux version doesn't have the font embedded, while the Windows one has... The consequence is that any posterior consumer of linout.pdf will produce fairly arbitrary results when displaying, printing, converting or processing this file with regard to the font.
So here is another test that I can think of. It checks how much the Linux versions of the fonts used for /Times-Bold (which is substituted by Ghostscript with the real /NimbusRomNo9L-Medi) and /TimesNewRomanPS-BoldMT` do differ in their font metrics.
Create three different PDFs with these Ghostscript commandlines:
a.pdf:
gs \
-o a.pdf \
-sDEVICE=pdfwrite \
-dPDFSETTINGS=/prepress \
-c "100 700 moveto \
/TimesNewRoman,Bold findfont \
12 scalefont \
setfont \
(0401060 0401060 0401060 0401060) show \
showpage"
b.pdf:
gs \
-o b.pdf \
-sDEVICE=pdfwrite \
-dPDFSETTINGS=/prepress \
-c "100 700 moveto \
/TimesNewRomanPS-BoldMT findfont \
12 scalefont \
setfont \
(0401060 0401060 0401060 0401060) show \
showpage"
c.pdf:
gs \
-o c.pdf \
-sDEVICE=pdfwrite \
-dPDFSETTINGS=/prepress \
-c "100 700 moveto \
/Times-Bold findfont \
12 scalefont \
setfont \
(0401060 0401060 0401060 0401060) show \
showpage"
The -dPDFSETTINGS=/prepress parameter should enforce the font embedding into output PDFs. (This is important, otherwise the viewer could use an arbitrary replacement font for displaying the PDF.)
What follows the -c parameter is a little PostScript snippet that provides content for the PDF page.
Files 'a.pdf' and 'b.pdf' should not differ. They only test if the font aliasing between /TimesNewRoman,Bold and /TimesNewRomanPS-BoldMT do indeed work as expectd.
File 'c.pdf' could show slight differences in comparison to a.pdf and b.pdf in the order of a few pixel here and there, but NOT in the tracking of the tested string.
If this test goes as predicted, the different fontfiles, the Fontmap.GS and Ghostscript itself all are OK. Then the problem is only with the way the Linux Java applet produces its output (PS or PDF).
I'm trying to get ghostscript to render a pdf file from a Windows box. The pdf file uses the ComicSansMS font. I've copied the comic.ttf file from my Windows7 box into my /usr/share/ghostscript/fonts directory, and I've created a Fontmap file in that same directory containing this line:
/ComicSansMS (comic.ttf) ;
As nearly as I can tell, the font is not being found despite this. The text comes out very poorly, and some of the smaller font sizes are rendered half the size they should be. Access times and strace show that the Fontmap file is being read, but the font file (comic.ttf) is not being accessed at all. There are no error messages:
hope 78$ gs cards-01.pdf
GPL Ghostscript 9.00 (2010-09-14)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
>>showpage, press <return> to continue<<
If I use -dFAPIDEBUG on the gs command line, I see the following:
hope 74$ gs -dFAPIDEBUG -I/usr/share/ghostscript/fonts cards-01.pdf
GPL Ghostscript 9.00 (2010-09-14)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
FAPIhook --nostringval--
Trying to render the font Font --nostringval-- ( aliased from ComicSansMS ) with FAPI...
Font --nostringval-- ( aliased from ComicSansMS ) is being rendered with FAPI=FreeType
FAPIhook --nostringval--
Font --nostringval-- ( aliased from ComicSansMS ) is mapped to FAPI=FreeType
FAPIhook RVJCAL+SymbolMT
Trying to render the font Font RVJCAL+SymbolMT with FAPI...
Font RVJCAL+SymbolMT is being rendered with FAPI=FreeType
FAPIhook RVJCAL+SymbolMT
Font RVJCAL+SymbolMT is mapped to FAPI=FreeType
FAPIhook HYLUQF+ComicSansMS
Trying to render the font Font HYLUQF+ComicSansMS with FAPI...
Font HYLUQF+ComicSansMS is being rendered with FAPI=FreeType
FAPIhook HYLUQF+ComicSansMS
Font HYLUQF+ComicSansMS is mapped to FAPI=FreeType
>>showpage, press <return> to continue<<
Naturally, the line from the above that most concerns me is this one:
Font --nostringval-- ( aliased from ComicSansMS ) is being rendered with FAPI=FreeType
"gs -h" shows that the font directory is, indeed, in the search path:
hope 77$ gs -h
GPL Ghostscript 9.00 (2010-09-14)
[ ... ]
Search path:
/usr/share/ghostscript/9.00/Resource/Init :
/usr/share/ghostscript/9.00/lib :
/usr/share/ghostscript/9.00/Resource/Font :
/usr/share/ghostscript/fonts : /usr/share/fonts/Type1 : /usr/share/fonts
I've tried several permutations of formatting in the Fontmap file, including:
(Comic Sans MS) (comic.ttf) ;
(ComicSansMS) (comic.ttf) ;
/Comic Sans MS (comic.ttf) ;
/ComicSansMS /comic.ttf ;
I'm fairly sure my original one is the correct one, but I was getting desperate. :-P
Any help would be greatly appreciated. Thanks in advance.
I assume that PDF does not have the ComicSansMS font embedded?
You should consider 2 other possibilities as well:
Your PDF file card-01.pdf is somehow corrupted. (Are other PDF viewers rendering that file without a problem? Does it display OK in Acrobat Reader on Widnows?)
Your fontfile comic.ttf is somehow corrupted. (Which method did you use to transfer it from Windows to Linux?)
You could try to positively proof that both these components are getting along well enough with each other by using Ghostscript+comic.ttf to create a PDF (with comic.ttf embedded):
gs \
-sFONTPATH=/usr/share/ghostscript/fonts \
-o comic-ttf.pdf \
-sDEVICE=pdfwrite \
-g5950x8420 \
-c "200 700 moveto" \
-c "/ComicSansMS findfont 60 scalefont setfont" \
-c "(comic.ttf) show showpage"
On Windows, use this variation of above command:
gswin32c.exe ^
-o comic-ttf.pdf ^
-sDEVICE=pdfwrite ^
-sFONTPATH=c:/windows/fonts ^
-g5950x8420 ^
-c "200 700 moveto" ^
-c "/ComicSansMS findfont 60 scalefont setfont" ^
-c "(comic.ttf) show showpage"
When I do this, I see:
gswin32c.exe ^
-o comic-ttf.pdf ^
-sDEVICE=pdfwrite ^
-sFONTPATH=c:/windows/fonts ^
-dHaveTrueTypes=true ^
-g5950x8420 ^
-c "200 700 moveto" ^
-c "/ComicSansMS findfont 60 scalefont setfont" ^
-c "(comic.ttf) show showpage"
GPL Ghostscript 9.00 (2010-09-14)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Scanning c:/windows/fonts for fonts... 423 files, 255 scanned, 240 new fonts.
Loading ComicSansMS font from c:/windows/fonts/comic.ttf... 3343720 1813337 2926116 1611207 1 done.
and my output PDF comic-ttf.pdf looks OK and does have the comic.ttf font embedded.
If this does also work for you, then your Ghostscript and your comic.ttf are OK, but your PDF file cards-01.pdf is not.
I came back to this problem after a delay. Upon further investigation with a magnifying glass, the problem is different from what I initially thought.
Text is definitely being rendered incorrectly in parts of the document. Each letter is far too small, though the spacing is oddly correct. However, the individual letters are the correct shape for the font.
The font on disk is not being accessed, but that's because the fonts are all embedded within the document. This fact would probably have been obvious to a Ghostscript expert from the output I posted in the original question (I'm guessing the "HYLUQF+" prefix is the smoking gun there), but I don't work with Ghostscript much. My fonts were installed correctly, and other documents were able to access them without trouble.
Of course, this still leaves the question of why my embedded fonts are being rendered incorrectly, but I will investigate that separately and/or post a different question. I maintain that the PDF file is uncorrupted (I have several other PDFs which exhibit the same problem), but I still don't know what's wrong.
#pipitas: Thanks very much for trying. You certainly did help verify that my installed fonts are not the problem. Actually, now that I look again, you even gently suggested the font might be embedded, but I either didn't see it, didn't believe it, or didn't know how to check.