[Printing-japan] Fixed packages of the CUPS PDF filters

Koji Otani sho @ bbr.jp
2008年 8月 6日 (水) 20:59:42 PDT

Hi Till.
I'm Koji Otani.

Thank you for your working on PDF filters.

From: Till Kamppeter <till.kamppeter @ gmail.com>
Subject: Re: [Printing-japan] Fixed packages of the CUPS PDF filters
Date: Wed, 06 Aug 2008 19:33:39 +0200
Message-ID: <4899E073.7010107 @ gmail.com>

till.kamppeter> I am currently packaging the new PDF filters into Ubuntu Intrepid. I am 
till.kamppeter> adding them to the CUPS package as they are supposed to get part of CUPS 
till.kamppeter> sooner or later.
till.kamppeter> imagetopdf and pdftoraster integrate without any problems. pdftopdf 
till.kamppeter> suffered changes in the libpoppler API. I had to apply the attached 
till.kamppeter> patch. Please check whether the patch is OK.

This patch is not wrong, but it is insufficent.
When you compile pdftopdf with old version poppler, you have problems.

I attached a better patch to this mail.

till.kamppeter> The bigger problem is pdftoopvp. After talking with Martin Pitt, Debian 
till.kamppeter> maintainer of CUPS we decided on not taking this filter with a copy of 
till.kamppeter> Poppler into the CUPS package. It will cause big maintenance problems 
till.kamppeter> due to the frequent occuring of security vulnerablilities in Poppler.
till.kamppeter> Is there really no chance to make the pdftoopvp filter dynamically 
till.kamppeter> linking the libpoppler library? It would be needed until July 20 so that 
till.kamppeter> it can still make it into Ubuntu Intrepid before feature freeze.
till.kamppeter> I would be very grateful if we can have this filter in Intrepid.
till.kamppeter>     Till

There are 3 technical issues.

(1) pdftoopvp depends on modefied Splash codes of poppler.
(2) Modefied poppler code to add a feature that poppler doesn't have
(fill font with pattern). because this modefication is only appropriate
for pdftoopvp, we can't add it to the trunk of poppler.
(3) There are modification to poppler code for raster API of opvp
driver. (Historical Reason)

(1) copying only needed codes into pdftoopvp ?
(2) giving up this feature ?
(3) These codes are needless and we should abandon them ?

Anyway, it's the biggest issue that I have not enough time to work on

Koji Otani

-------------- next part --------------
Index: configure.ac
--- configure.ac	(リビジョン 800)
+++ configure.ac	(作業コピー)
@@ -131,5 +131,11 @@
     AC_DEFINE([HAVE_UGOOSTRING_H],,[Have UGooString.g])
+dnl check CharCodeToUnicode::mapToUnicode interface
+if grep "mapToUnicode(.*Unicode[ ][ ]*\*u" $POPPLER_SRCDIR/poppler/CharCodeToUnicode.h >/dev/null ;then
+    AC_DEFINE([OLD_MAPTOUNICODE],,[Old CharCodeToUnicode::mapToUnicode])
 AC_CONFIG_FILES([Makefile src/Makefile conf/Makefile man/Makefile])
Index: src/P2PFont.cc
--- src/P2PFont.cc	(リビジョン 754)
+++ src/P2PFont.cc	(作業コピー)
@@ -386,10 +386,17 @@
 	CharCode cid;
 	for (cid = 0;cid <= maxRefCID ;cid++) {
 	  int len;
 	  Unicode ucode;
 	  len = octu->mapToUnicode(cid,&ucode,1);
 	  humap[cid*N_UCS_CANDIDATES] = ucode;
+	  Unicode *ucode = NULL;
+	  len = octu->mapToUnicode(cid,&ucode);
+	  humap[cid*N_UCS_CANDIDATES] = *ucode;
 	  for (i = 1;i < N_UCS_CANDIDATES;i++) {
 	    humap[cid*N_UCS_CANDIDATES+i] = 0;
@@ -1109,7 +1116,11 @@
   char *p;
   int len;
   int n;
   Unicode u[8];
+  Unicode *u = NULL;
   CharCode code;
   int uLen;
   double dx,dy,originX,originY;
@@ -1120,8 +1131,13 @@
   p = s->getCString();
   len = s->getLength();
   while (len > 0) {
     n = font->getNextChar(p,len,&code,u,(sizeof(u)/sizeof(Unicode)),&uLen,
+    n = font->getNextChar(p,len,&code,&u,&uLen,
+         &dx,&dy,&originX,&originY);
     code &= (CIDTOGID_SIZE-1); /* mask */
     p += n;

Printing-japan メーリングリストの案内