Bug#322713: (fwd) Bug#322713: dvipdfm doesn't understand gs anymore
Dear all,
I'm sending this E-Mail to the author of dvipdfm and of dvipdfmx as
dvipdfm seems to be dead actually (the latest version is from 2001
and in the Mail archive got 3 Mails in 2004 and none in 2005).
The following bug was submitted here at the Debian Bug Tracking
system. There is an example file demonstrating that behaviuor but it
consist of private content and hence was not published. Please
contact us at 322713@bugs.debian.org if you need it for debugging.
Kind Regards,
Hilmar Preuße
----- Forwarded message from debbug2@danisch.de -----
From: debbug2@danisch.de
Reply-To: debbug2@danisch.de, 322713@bugs.debian.org
To: submit@bugs.debian.org
Subject: Bug#322713: dvipdfm doesn't understand gs anymore
Date: Fri, 12 Aug 2005 13:56:27 +0200
Message-ID: <[🔎] 20050812115627.GA25231@danisch.de>
User-Agent: Mutt/1.5.6+20040907i
X-Mailing-List: <debian-tetex-maint@lists.debian.org> archive/latest/12542
Package: tetex-bin
Version: 2.0.2-31
Hi,
I am producing some reports using latex and dvipdfm. They all include
the same EPS graphics, and it worked well for years.
But since last debian upgrade, dvipdfm terminates with this
error message:
[1(../../../../Common/Doku/logo4c.eps<PS>Invalid PDF name
"HKS#2043#20K"
pdf_new_name: invalid PDF name
I have tracked this down to:
- The EPS contains a command like
1 0.75 0 0 (HKS 43 K) false newcmykcustomcolor
- dvipdfm calls gs to convert included EPS into
PDF. Latest version of gs-eps produces a PDF file
with
[/Separation
/HKS#2043#20K
/DeviceCMYK
9 0 R]endobj
10 0 obj
That HKS#2043#20K name is understood by every pdf application
except dvipdfm.
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.
regards
Hadmut
----- End forwarded message -----
Regards,
Hilmar
--
http://www.hilmar-preusse.de.vu/
Reply to: