On 14 Dec 2005, at 20:23, Volker Christian Behr wrote:
This might also be due to some settings for character encoding. I
suggest
the following tests:
1st: print the CUPS printer test page to CUPS-PDF and check whether
there
the text appears properly
Test page works perfectly.
2nd: create a postscript from a simple text file (e.g. by a2ps or
encode),
check it with ghostview and print this postscript to CUPS-PDF
I created a text file ("blah.txt") containing the characters "Blah",
then used a2ps to create a PostScript file ("blah.ps"), a2ps blah.txt
-o blah.ps.
The PostScript file looks fine, and cups-pdf converts it to PDF just
fine.
3rd: if 1st and 2nd work, to get to the PostScript file that is used by
CUPS-PDF you will have to edit the source code of cups-pdf ...
Finished this - the postscript in the CUPS spool (/var/spool/cups) and
the cups-pdf backend spool (/var/spool/cups-pdf/SPOOL) are identical
(which seems reasonable enough), and both render fine in kghostview
(I'm using KDE3 on my Linux workstations, Mac OS X 10.3 on my desktop).
When trying to open one of the PostScript files in Preview (the Mac OS
X equivalent of Kghostview) I get the error, "Can't create CMap
Adobe-Identity-UCS2." Does this provide any hints as to the nature of
the problem?
I guess the next step is to go through the process that is automated by
cups-pdf to figure out at what point the "damage" is being done.
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
