Bug#322713: dvipdfm doesn't understand gs anymore

[Frank Küster <frank@debian.org>]

debbug2@danisch.de 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