[EMAIL PROTECTED] wrote:
> I have tracked this down to:
>
> - The EPS contains a command like
>
> 1 0.75 0 0 (HKS 43 K) false newcmykcustomcolor
Meanwhile, Hadmut has sent me the eps file in private (it cannot be
published), thanks for that.
I can reproduce the bug in sid, but not in sarge. The reason is a
different behavior of gs:
sid has:
$ dpkg -l "gs-*" | grep ^ii
ii gs-afpl 8.14-3 The AFPL Ghostscript PostScript
interpreter
ii gs-common 0.3.8 Common files for different
Ghostscript relea
ii gs-esp 8+8.15rc4.dfsg.1-1 The Ghostscript PostScript
interpreter - ESP
ii gs-gpl 8.15-2 The GPL Ghostscript PostScript
interpreter
whereas sarge has:
~$ dlocate -l gs- | grep ^ii
ii gs-common 0.3.7 Common files for
different Ghostscript releases
ii gs-esp 7.07.1-9 The Ghostscript
PostScript interpreter - ESP version
ii gs-gpl 8.01-5 The GPL Ghostscript
PostScript interpreter
(I didn't try with gs-afpl on my sarge working machine)
On sid, gs-afpl is the only version that does not trigger the bug. Given
that logo4c.eps contains the problematic line
1 0.75 0 0 (HKS 43 K) false newcmykcustomcolor
or similar, as reported by Hadmut, this is a command line to reproduce
it:
cat logo4c.eps | gs -q -sPAPERSIZE=a0 -sDEVICE=pdfwrite \
-dCompressPages=false -dCompatibilityLevel=1.2 \
-dUseFlateCompression=true -dSAFER -sOutputFile=%o - -c quit
(it's the one dvipdfm uses, plus -dCompressPages=false).
As originally reported, gs-esp and gs-gpl produce PDF files that contain
statements like
[/Separation
/HKS#2043#20K
/DeviceCMYK
8 0 R]endobj
9 0 obj
...
However, the name object /HKS#2043#20K seems to be perfectly valid - in
a name, only the delimiters (,),<,>,[,],{,},/, and % and whitespace
characters are forbidden. Although #20 is probably meant to signify
"hexadecimal 20", i.e. ASCII space, it consists of three separate bytes
and is by itself a valid name.
> If I modify (HKS 43 K) into (HKS43K) in the eps, everything
> works again. So it is a problem of the Space characters,
> the way gs convertes them, and dvipdfm not understanding them.
It seems it is rather a problem with dvipdfm being to strict with pdf
name objects and not accepting the #.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
