Dmitry Ivanov | 3 Dec 05:09 2014

pdf-geom improvements

Hello folks,

I have been playing with functions form pdf-geom.lisp lately and found
them surprisingly useful. But let me a few notes.

First, for representing a point internally a two-element list is used. Why
not just cons? I mean (cons x y)  instead of (list x y) and car/cdr instead
of first/second.

This obvious improvement would lead to code to cons smaller. Are there any
external constraints or other reasons for using (list x y)?

Second, can the function fillet return something meaningful? Yes, the code
can be easily rewritten to return the last point we have finished drawing

Third, I suggest adding the round parameter to the rectangle function. In
addition to rounding corners, it helps in specifying what corner or corners
are to be rounded exactly.

This stuff could allow to improve tables in CL-Typesetting further. I am
going to speak about this in another post.

An example of a "rounded" table is available in

My code is as follows.

(defun rectangle (x y dx dy &key (radius 0) (round :all))
;;; Args: dy    Rectangle height, either positive or negative.
(Continue reading)

Mitch Berkson | 25 Oct 06:26 2014

Multiple existing documents to new page

I would like to include two pdfs in a new pdf.

I have done this using templates, but the resulting file is much larger than
the two original files (35MB vs. 2.5MB + 0.5MB).

I have also experimented with the with-existing-document macro, but have not
been able to add a second file.  The output with just one existing file is
nice and small though.

Is there a straightforward way to include two existing documents in a new
pdf which will have additional content added?
Tomasz | 3 Jun 23:32 2014

reduce PDF size - font subset?


I have issue with national fonts (Polish).
The only way to render them properly we found, was to embed Type1 fonts. The 
problem is that now every file is >200kb since it has full Type1 2 fonts 
When i use, it seems that the embeding of a 
subset of fonts should solve the problem.

Eventually i have 2 questions
1) is there any way to have Polish letters without embeding fonts?
2) if not, is it possible to reduce the size of files? embed subset of the 

Thank you in advance

Best Regards
Tomasz | 3 Jun 21:32 2014

PDF attachment


Is it possible to attach something (XML) to the PDF generated out of cl-pdf?

Thank Tou
Marc Battyani | 10 Nov 20:41 2013

Re: Using zpb-ttf to load Unicode ttf files

Hi all,

I apologize for the 7 years delay to add this into the cl-pdf repository!

It's now committed and pushed into the official cl-pdf repository which is currently on github:

BTW if you know about other stuff I forgot to add to cl-pdf/cl-typesetting please let me know.


On 3/2/06, 17:33, Peter Heslin wrote:
A couple of weeks ago, Zach Beane announced the release of his zpb-ttf library for reading TrueType Unicode font files. cl-pdf already has support for using these fonts, but the metrics have to be read in via a "ufm" file, which has to be generated with a hacked version of ttf2pt1 -- a less than ideal situation. So I tried to get zpb-ttf to load the ttf font metrics. I'll attach the file I came up with, which now allows a pure Lisp solution to using truetype fonts in cl-pdf. I've tested it on just a few fonts, but it seems to work fine. Health warning: I don't have a deep understanding of all of the parts of this code, much of which was munged around and adapted from various parts of font-metrics.lisp. It would be good if someone else who understands the issues were to review it. One thing I did notice is that zpb-ttf reports a different value for the font's descender, as compared to the ufm file generated by ttf2pt1. Also, I used zpb-ttf's line-gap for (leading font-metric), but that's a guess.

_______________________________________________ cl-pdf-devel site list

R. Mattes | 10 Nov 16:56 2013

status of TrueType font support

Hello list,

I just wanted to check the status of truetype integration
via ttf-zpb. There was a patch posted to this list years ago
and there is a git repository at
but that repository lags behind the offical cl-pdf and quicklisp
tracks the official one. Is there any chance of merging these changes
into the official branch?

 TIA Ralf Mattes

R. Mattes -
Hochschule fuer Musik Freiburg

Dave Cooper | 1 Apr 04:22 2013

fix for recent clisp breakage (was: Re: cl-pdf multi-platform support)

Here is a patch to fix the clisp breakage for cl-pdf. I will send a similar patch separately to the cl-typesetting-devel list. 

This is made with git format-patch, so it should be able to be applied with:

  cd cl-pdf
  git apply 001-probe-file-fix-for-clisp.patch

On Sun, Mar 31, 2013 at 5:52 PM, Carlos Ungil <> wrote:
 By the way, the code recently added to set data directories at runtime raises an error in clisp (probe-file can't handle directories on that platform).

My Best,

Dave Cooper, Genworks Support
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
Attachment (0001-probe-file-fix-for-clisp.patch): application/octet-stream, 1122 bytes
cl-pdf-devel site list
Carlos Ungil | 31 Mar 23:52 2013

cl-pdf multi-platform support


I was able to make cl-pdf work on many lisps (tested on macos and windows only) using the following
definitions for +external-format+ and *default-charset* in config.lisp (CMUCL is not listed
explicitly, but it works as well):

(defconstant +external-format+
  #-(or sbcl lispworks clisp allegro ccl abcl ecl) :default
  #+abcl '(:iso-8859-1 :eol-style :lf)
  #+ecl '(:latin-1 :lf)
  #+ccl :latin1
  #+sbcl :latin-1
  #+allegro :octets
  #+lispworks '(:latin-1 :eol-style :lf)
  #+clisp (ext:make-encoding :charset 'charset:iso-8859-1 :line-terminator :unix))

(defvar *default-charset*
  #+(and lispworks5 win32) (ef::ef-coded-character-set win32:*multibyte-code-page-ef*)
  #-(and lispworks5 win32) *char-single-byte-codes*)	; last resort

It seems that the form #+clisp (setf *default-file-encoding* ...) be safely removed. By the way, the code
recently added to set data directories at runtime raises an error in clisp (probe-file can't handle
directories on that platform).

Adding :use-salza2-zlib to *features* compressed files can be created in all the implementations (ECL
tested only on macos) if string-to-octets is defined in zlib.lisp as follows:

(defun string-to-octets (string start end)
  "Convert STRING to a sequence of octets, if possible."
  (declare (type string string)
	   (type buffer-offset start end)
	   (optimize (speed 3) (safety 0)))
  #+(and sbcl (not octet-characters))
  (sb-ext:string-to-octets string :external-format :iso-8859-1 :start start :end end)
  #+(and allegro (not octet-characters))
  (excl:string-to-octets string :external-format :octets :start start :end end :null-terminate nil)
  #+(and clisp (not octet-characters))
  (ext:convert-string-to-bytes string custom:*default-file-encoding* :start start :end end)
  #+(and ccl (not octet-characters))
  (ccl:encode-string-to-octets string :external-format :latin-1 :start start :end end)
  #+(and cmu (not octet-characters))
  (ext:string-to-octets string :external-format :iso-8859-1 :start start :end end)
  #+(or octet-characters lispworks abcl ecl)
  (let* ((length (- end start))
	 (result (make-array length :element-type 'salza2::octet)))
    (loop for i fixnum from start below end
	  for j fixnum from 0
	  do (setf (aref result j) (char-code (aref string i))))
  #+(and (not octet-characters) (not (or sbcl allegro clisp ccl cmu lispworks abcl ecl)))
  (error "Do not know how to convert a string to octets."))

ECL support requires as well making a couple of changes to pdf.lisp to make the conditionals #+allegro,
#-allegro refer to (or allegro ecl) instead:

#-(or allegro ecl) ;; line 575
 (defmethod write-document ((filename pathname) &optional (document *document*))

#+(or allegro ecl) ;; line 585
 (defmethod write-document ((filename pathname) &optional (document *document*))

I also found a minor bug in example10 (the write-document is inside the dolist loop):
 <at>  <at>  -551,5 +551,5  <at>  <at> 
                 (apply #'pdf:set-rgb-fill (hsv->rgb (/ x 9.1) 1 1))
                 (pdf:set-transparency (/ y 9.0) bm)
                 (pdf:circle (* x 50) (* y 80) 30)
-                (pdf:fill-path))))))
-      (pdf:write-document file))))
+                (pdf:fill-path)))))))
+    (pdf:write-document file)))

Best regards,

cl-pdf-devel site list

Dave Cooper | 28 Mar 20:31 2013

Patch to make it so cl-typesetting can be loaded without hyphenation-patterns/ directory in known location

Dear Marc/All,

In followup to my recent patch proposals for cl-pdf, here is a similar patch for cl-typesetting which allows the library to be loaded even if cl-pdf's afm/ and cl-typesetting's hyphen-patterns/ directories are not in the standard/known locations at compile and/or load time. For this case, an initialize! function is provided where you can specify these directories and have things set up at runtime initialization time. 

Feedback welcome (maybe Marc B is waiting for some feedback from the list before he considers going ahead and applying the patches). 

cl-typesetting is not in git yet, so this patch was made with 

 diff -rupN  cl-typesetting/ cl-typesetting-...patched/ 

so I think it would be applied  to a local working directory with 

 cd cl-typesetting/ 
 patch -p1 < cl-typesetting-make-it-so-you-can-load-without-hyphen-patterns.patch

My Best,

Dave Cooper, Genworks Support
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
cl-pdf-devel site list
Dave Cooper | 27 Mar 02:49 2013

compile and load-time dependency on *cl-pdf-base-directory* considered harmful (was: Re: cl-pdf is moving to github)

Hi All,

 I'm not sure if I should put this on this mailing list or as an Issue on the new Github site (where I could claim "First!" : )

How many of you have seen this error at some point during your time using cl-pdf:

 "Error: Font Helvetica not Found" 

As you probably know, one of the things which can cause this is when cl-pdf is being loaded from a compiled fasl which is not in the location of the source codebase, and the source codebase is no longer available at the location where it was during compiling.

So my basic question is: does anyone have suggestions what to do about *cl-pdf-base-directory* and *cl-typesetting-base-directory* so that a fasl or built runtime can be used without the depending on the original absolute pathname to afm/ directory, etc. still existing as they were during compilation? As it is currently, the full hardcoded pathname of the *cl-pdf-base-directory* and *cl-typesetting-base-directory* are baked into a compiled fasl. I understand this used to work from *load-truename* instead of *compile-file-truename*, and the hardcoding of compile-time source location was introduced as a "fix" for the fact that ASDF started using output-translations which resulted in the fasl being loaded not being in the source location. But this "fix" still assumes that the sources are always going to be available in their original location every time a fasl is loaded, which I consider to be a fragile assumption. 

For me, the ideal solution would be: 

 1. First of all, don't have any compile-time or load-time dependencies on these variables at all. As it is now, only chart.lisp in cl-pdf appears to depend on *afm-files-directories* -- couldn't this stuff be deferred to runtime? For cl-typesetting I'm not sure what are the dependencies at compile and load time, but I speculate that they are few. 

 2. Provide an "initialize!" function for use at runtime startup, which is supposed to establish base directory locations for afm/ directory etc. 

Then it would be (as it rightfully should be) the responsibility of any runtime application which is using cl-pdf to set the *-base-directory* variables and call the initialize! function as part of its "restart" function, much the same way as many applications normally have to initialize themselves at startup to find the location of outside resources (e.g. webserver applications have to be set with the location of static files for publishing, etc). 

Before I go any deeper into this direction I just wanted to get any feedback that current users have about this issue. And let me know if it should be opened as an Issue on the github project or stay on this mailing list. 

Best Regards


P.S. Are there plans to bring cl-typesetting to github as well, side-by-side with cl-pdf? 

On Thu, Feb 28, 2013 at 12:28 PM, Marc Battyani <> wrote:
Hi all,

cl-pdf is moving to

Please contact me if want to have push access.


cl-pdf-devel site list

My Best,

Dave Cooper, Genworks Support
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
cl-pdf-devel site list
Marc Battyani | 24 Feb 03:34 2013

cleaning cl-pdf

Hi all,

I just committed a bunch of pending stuff to cl-pdf who really needs some care:

Warning this might break things!
-Committing a lot of accumulated patches and fixes
-Removed salza as people will get it from quicklisp now

Please commit or send me any fixes you might have as well as fixes to this commit and when it's all good I will label it version 3.0 and move it from svn to github


cl-pdf-devel site list