Hi Alessandro-- On 02/01/2010 11:49 AM, Alessandro De Zorzi wrote: > thanks for your interest, I tried to make a tcpdf package after php-fpdf troubles... anyway my tcpdf package cleaned [1] REJECTED due some .ai binary files... (if I right understand) > > I agree the strong Debian checks before accept new packages, anyway my opinion is that .ai (Abobe Illustratr) is a format like a PostScript file (vector image), and others debian packages contains .ai files [2] > > after these experiences I think that is not easy give my help to Debian This sounds frustrating, i'm sorry to hear you had that experience. Looking at the files you have in http://open.rhx.it/debian/source/ i do see tiger.ai, pelican.ai, and bug.eps in the images/ directory, but i also don't think they're needed for the package, so it would be relatively easy to just strip them out if there's any question about their licensing. i suspect that the font issues are more serious. the package contains several font files that don't look human-generated at all -- they're presumably the output of some other machine-generated process. in the latest version from upstream (4.8.031?), it looks like they've included those tools in fonts/utils, but as separate (embedded) tarballs for the pfm2afm and ttf2ufm utilities. Those programs themselves might be better broken out as separate packages, so that they could be reviewed and maintained independently. they present their own issues: pfm2afm: the licensing for the embedded source appears to say: * Copyright: * * pfm2afm - Copyright (C) IBM Corp., 1991 * * * * This code is released for public use as long as the * * copyright remains intact. This code is provided asis * * without any warrenties, express or implied. * This doesn't appear to allow modification or redistribution of modifications. (as it's distributed as part of tcpdf, i'm baffled that they claim OSI certification) ttf2ufm is *much* larger and i haven't had a chance to review it. So i think tcpdf could enter debian more easily if the entire images and fonts subdirectories were cleaned out (perhaps leaving the scripts which do have explicit DFSG licensing). no need to include the embeddable versions of the dejavu or freefont families either -- once the font transformation tools are packaged up, users can create their own variants of system-installed fonts (or an energetic maintainer could hook into fontconfig and auto-build embeddable versions of every font installed on the system. This would leave tcpdf somewhat less useful (as we wouldn't even have the tools available to create embedded versions of fonts), but might also spur work on getting the font conversion utilities into debian, and creating an infrastructure for people to generate the embedded font blobs. Just to be able to use unicode in PHP-generated PDFs would be great, even if we have to use the default PDF fonts. does this make the set of problems more clear? --dkg
Attachment:
signature.asc
Description: OpenPGP digital signature