Postscript, Ghostscript, Unicode, and TT fonts...
This is a somewhat specifc problem, but I didn't get a reply on
comp.lang.postscript and maybe somebody on this list can help me out
or point me to more specific sources of information.
This is the scenario: I'm trying to use unicode truetype fonts with
the latest StarOffice on a Linux machine. The problem is that SO
supports neither truetype fonts nor unicode. Since I only need about a
dozen glyphs >255 (basically all typographical quotation marks, the
typographical dashes, the french oe ligatures, the single guillemets,
the ellipsis character, the euro sign) I figured I'd just find a way
to map them to the code range that is not used in iso8859-1. Since my
font server (xfsft) is able to remap fonts on-the-fly, I have him
serve the iso10646-1 fonts as microsoft-cp1252 (which supplies all
characters I'm interested in). This is the relevant part of the
remapping process (in decimal codes):
quotesingle 8217 -> 127
Euro 8364 -> 128
quotesinglbase 8218 -> 130
florin 402 -> 131
quotedblbase 8222 -> 132
ellipsis 8230 -> 133
dagger 8224 -> 134
daggerdbl 8225 -> 135
circumflex 710 -> 136
perthousand 8240 -> 137
Scaron 352 -> 138
guilsinglleft 8249 -> 139
OE 338 -> 140
Zcaron 381 -> 142
quoteleft 8216 -> 145
quoteright 8217 -> 146
quotedblleft 8220 -> 147
quotedblright 8221 -> 148
bullet 8226 -> 149
endash 8211 -> 150
emdash 8212 -> 151
tilde 732 -> 152
trademark 8482 -> 153
scaron 353 -> 154
guilsinglright 8250 -> 155
oe 339 -> 156
zcaron 382 -> 158
Ydieresis 939 -> 159
My next step is to supply SO with hacked font metrics files that
correspond to the cp1252 encoding and put all the font names in the
appropriate printer definition file. The idea is to make SO believe
that the fonts are resident printer fonts and not ttfs. Up to this
point, I think I know what I'm doing and everything works fine. The
fonts show up on the screen, SO finds the correct metrics for all
glyphs and prints them.
This is where gs comes in. The print spooler calls gs via an input
filter to convert the ps file to pcl and sends gs' output to my
LaserJet 5L. At this point, gs gets the glyphs from the original ttf
files. Still, this works fine for all characters defined by the
iso8859-1 encoding table. What I can't get to work is the unicode
part, that is the remapped characters (gs substitutes the '.notdef'
character for them).
I have a rather fuzzy idea of what postscript is and how it works, so
please take the following with a grain of salt. If I redirect the ps
output produced by SO to I file, I notice two things, the first being
that at several points the encoding is defined as /ISOLatin1Encoding
and the second that there is a /changesvec section which seems to
provide the mapping information for the characters I'm after. It looks
like this:
/changesvec [
16#80 /euro
16#82 /quotesinglbase
16#83 /florin
16#84 /quotedblbase
16#85 /ellipsis
16#86 /dagger
16#87 /daggerdbl
16#88 /circumflex
16#89 /perthousand
16#8a /Scaron
16#8b /guilsinglleft
16#8c /OE
16#8e /zcaron
16#91 /quoteleft
16#92 /quoteright
16#93 /quotedblleft
16#94 /quotedblright
16#95 /bullet
16#96 /endash
16#97 /emdash
16#98 /tilde
16#99 /trademark
16#9a /scaron
16#9b /guilsinglright
16#9c /oe
16#9e /zcaron
16#9f /Ydieresis
] def
Obviously, the codes given here correspond to the cp1252 mapping and
gs can't find them in the cmap of the ttf file. What I would like to
do is to pipe SO's ps output through a perl script that makes some
changes and corrects this before sending it to gs and the print
spooler. At this point, I'm lost. Should I change the
'ISOLatin1Encoding' to something else or simply fix the codes so that
they correspond to the cmap of the ttf file? I tried the latter by
hand with a sample file, that is I changed
16#84 /quotedblbase
to
16#201e /quotedblbase
but to no avail. gs doesn't give any error messages, it simply
subsitutes 'notdef' for 'quotedblbase'. Is the whole idea nonsense
or is this possible (in theory at least)? And in practice? Please
help me out here...
TIA
--
Philip Lehman <lehman@gmx.net>
Reply to: