[tex-live] (fwd) Bug#322713: dvipdfm doesn't understand gs anymore
hille42 at web.de
Sat Sep 17 15:50:52 CEST 2005
Hi Thomas, hi TeX Live team,
the following bug we got here down in the Debian Bug Tracking system.
During the discussion it came to our attention, that the dvipdfm
development has stalled and the upstream can assumed to be dead (last
version was released in 2001, the ML of the project got 3 mails last
year and probably none in this year.
Frank then pointed to the project dvipdfmx, which is an extension of
dvipdfm and actively developed (we got very fast responses from the
maintainers). They said, dvipdfmx can be used as replacement of
dvipdfm as it is fully compatible.
Please consider to drop dvipdfm in favor of dvipdfmx!
----- Forwarded message from debbug2 at danisch.de -----
From: debbug2 at danisch.de
Reply-To: debbug2 at danisch.de, 322713 at bugs.debian.org
To: submit at 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 at danisch.de>
X-Mailing-List: <debian-tetex-maint at lists.debian.org> archive/latest/12542
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
[1(../../../../Common/Doku/logo4c.eps<PS>Invalid PDF name
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
9 0 R]endobj
10 0 obj
That HKS#2043#20K name is understood by every pdf application
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.
----- End forwarded message -----
http://www.hilmar-preusse.de.vu/ #206401 http://counter.li.org
More information about the tex-live