[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ghostscript CMap files



On 01/25/2011 12:14 PM, Kenshi Muto wrote:
Hi Jonas and Till,

(I'm so sorry about I've been inactive nowadays)

At Tue, 25 Jan 2011 01:38:03 +0100,
Jonas Smedegaard wrote:
On Mon, Jan 24, 2011 at 11:30:31PM +0100, Till Kamppeter wrote:
On 01/24/2011 09:04 PM, Jonas Smedegaard wrote:
I noticed that recent Ghostscript packaging for [Ubuntu] dropped the
indirection of CMap files.

I am not knowledgeable in DeFoMa, but recent changelog entry of
gs-cjk-resource seems to indicate that even dropping DeFoMa it still
makes sense to preserve the indirection.

Ghostscript 9 made progress in releasing CMap files under a DFSG-free
license, but still some of them need to be stripped, so I suspect some
users still rely on gs-cjk-resource for their needs with Ghostscript.

Making /var/lib/ghostscript/CMap from gs-cjk-resource is just aimed
for old DFSG-free Ghostscript style.
It's better that ghostscript package itself provides CMap files.

My suggestion is symlinking the CMap files of gs-cjk-resource into the
CMap directory of Ghostscript or by simply letting them get installed
into Ghostscript's CMap directory. If the files are already shipped by
Ghostscript, the gs-cjk-resource and/or cmap-adobe-japan1 packages will
get superfluous and should get removed from Debian.

The origin of those CMap files is Adobe, not Ghostscript, and they are
usable for other purposes that with Ghostscript.

Any packages without gs-cjk-resource doesn't use CMap files of
cmap-adobe-* package. Poppler uses their CMap, poppler-data package.

So basically removing gs-cjk-resource and cmap-adobe-* from Debian
after ghostscript has them is no problem.

The remained issue is 'how to make cidfmap'. cidfmap is the map
definition between TrueType font name and CID font name.
Currently it is handled by gs-cjk-resource and can be moved to
ghostscript.

Thanks,

So if Ghostscript is the only user of the CMaps then having them provided by Ghostscript and removing the gs-cjk-resource and cmap-adobe-* packages would be the much easier way in terms of maintainability. We naturally need to check whether we do not loose anything by that.

   Till


Reply to: