Does somebody know if there is a Common Lisp PDF generation library
somewhere ?
If not, are there anybody interested to work with me on such a project ?
Marc
PS: Here is what a pdf file looks like:
--------------- cut here and save as hello-world.pdf -----------------
%PDF-1.3
1 0 obj
<< /Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
>>
endobj
2 0 obj
<< /Type /Outlines
/Count 0
>>
endobj
3 0 obj
<< /Type /Pages
/Kids [ 4 0 R]
/Count 1
>>
endobj
4 0 obj
<< /Type /Page
/Parent 3 0 R
/MediaBox [ 0 0 612 792]
/Contents 5 0 R
/Resources << /ProcSet 6 0 R
/Font << /F1 7 0 R >>
>>
>>
endobj
5 0 obj
<< /Length 73 >>
stream
BT
/F1 24 Tf
100 100 Td
( Hello World) Tj
ET
endstream
endobj
6 0 obj
[ /PDF /Text ]
endobj
7 0 obj
<< /Type /Font
/Subtype /Type1
/Name /F1
/BaseFont /Helvetica
/Encoding /MacRomanEncoding
>>
endobj
xref
0 8
0000000000 65535 f
0000000009 00000 n
0000000074 00000 n
0000000120 00000 n
0000000179 00000 n
0000000364 00000 n
0000000466 00000 n
0000000496 00000 n
trailer
<< /Size 8
/Root 1 0 R
>>
startxref
625
%%EOF
"Marc Battyani" <·············@fractalconcept.com> writes:
> Does somebody know if there is a Common Lisp PDF generation library
> somewhere ?
>
> If not, are there anybody interested to work with me on such a project ?
That does sound like a good idea. Have you seen PLisp?
<http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/io/plisp/0.html>
It might be a good place to start. I've played with it a little, and
it seems really slick.
Of course, it might be too PostScript-y, I don't know. I keep meaning
to read the PDF documents ... I've read a couple summaries of "what's
PDF?" for PostScript programmers :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" <···@famine.OCF.Berkeley.EDU> wrote
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > Does somebody know if there is a Common Lisp PDF generation library
> > somewhere ?
> >
> > If not, are there anybody interested to work with me on such a project ?
>
> That does sound like a good idea. Have you seen PLisp?
>
<http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/io/p
lisp/0.html>
> It might be a good place to start. I've played with it a little, and
> it seems really slick.
I've also used it in the past, but PDF is only a description language, not a
programming language like Postscript.
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Thomas F. Burdick" <···@famine.OCF.Berkeley.EDU> wrote
> > "Marc Battyani" <·············@fractalconcept.com> writes:
> >
> > > Does somebody know if there is a Common Lisp PDF generation library
> > > somewhere ?
> > >
> > > If not, are there anybody interested to work with me on such a project ?
> >
> > That does sound like a good idea. Have you seen PLisp?
> >
> <http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/io/p
> lisp/0.html>
> > It might be a good place to start. I've played with it a little, and
> > it seems really slick.
>
> I've also used it in the past, but PDF is only a description language, not a
> programming language like Postscript.
Right, but if *I* were going to write a library for PDF, I'd want it
to be kind of PostScript-y. The library could take care of the
distillation part. This would probably make it a bit slower, but if
you cared about performance, you could limit your usage to the
descriptive parts of the interface.
But, like I said, I need to read up some more on PDF, so I might be
mistaken about this being a workable solution.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article
<··················································@lp.airnews.net>,
"Marc Battyani" <·············@fractalconcept.com> wrote:
> Does somebody know if there is a Common Lisp PDF generation library
> somewhere ?
There's a library for Gwydion Dylan at:
ftp://berlin.ccc.de/pub/gd/contributions/pdf.tar.gz
You might be able to get ideas from that, or just translate it :-)
-- Bruce
"Bruce Hoult" <·····@hoult.org> wrote
> "Marc Battyani" <·············@fractalconcept.com> wrote:
>
> > Does somebody know if there is a Common Lisp PDF generation library
> > somewhere ?
>
> There's a library for Gwydion Dylan at:
>
> ftp://berlin.ccc.de/pub/gd/contributions/pdf.tar.gz
>
> You might be able to get ideas from that, or just translate it :-)
Cool!
I hope Dylan is understandable by a Common Lisper. ;-)
Marc
In article
<··················································@lp.airnews.net>,
"Marc Battyani" <·············@fractalconcept.com> wrote:
> "Bruce Hoult" <·····@hoult.org> wrote
> > "Marc Battyani" <·············@fractalconcept.com> wrote:
> >
> > > Does somebody know if there is a Common Lisp PDF generation library
> > > somewhere ?
> >
> > There's a library for Gwydion Dylan at:
> >
> > ftp://berlin.ccc.de/pub/gd/contributions/pdf.tar.gz
> >
> > You might be able to get ideas from that, or just translate it :-)
>
> Cool!
> I hope Dylan is understandable by a Common Lisper. ;-)
Maybe you'll let us know either way?
-- Bruce
"Bruce Hoult" <·····@hoult.org> wrote
·····················@news.paradise.net.nz...
> In article
> <··················································@lp.airnews.net>,
> "Marc Battyani" <·············@fractalconcept.com> wrote:
>
> > "Bruce Hoult" <·····@hoult.org> wrote
> > > "Marc Battyani" <·············@fractalconcept.com> wrote:
> > >
> > > > Does somebody know if there is a Common Lisp PDF generation library
> > > > somewhere ?
> > >
> > > There's a library for Gwydion Dylan at:
> > >
> > > ftp://berlin.ccc.de/pub/gd/contributions/pdf.tar.gz
> > >
> > > You might be able to get ideas from that, or just translate it :-)
> >
> > Cool!
> > I hope Dylan is understandable by a Common Lisper. ;-)
>
> Maybe you'll let us know either way?
I looked at it. I was the first time I really looked at Dylan and my first
impression is that it is the closest things to CL I have seen. Looks closer
to CL than scheme. Ok It's just a quick look. but I found the concepts to be
similar to the CL ones.
The question is : Good but it what cases would I need Dylan rather than
Common Lisp ? In other words for what kind of applications could Dylan be
better suited than Lisp ?
Marc
PS can you do macros with that syntax ?
In article
<··················································@lp.airnews.net>,
"Marc Battyani" <·············@fractalconcept.com> wrote:
> I looked at it. I was the first time I really looked at Dylan and my
> first impression is that it is the closest things to CL I have seen.
> Looks closer to CL than scheme.
Other than the obvious one of the syntax, the base language is a little
closer to Scheme (e.g. it's a "Lisp-1", you don't have special
variables) but the collection classes and object system and condition
system and so forth are more like CL.
> The question is : Good but it what cases would I need Dylan rather than
> Common Lisp ? In other words for what kind of applications could Dylan be
> better suited than Lisp ?
Dylan tries to allow you to get a little "closer to the metal" when you
*want* to, without forcing you to all the time like C does. It's
intended for applications where you don't need the compiler at runtime
and where once you've figured out what you want you're prepared to sign
away some dynamism in return for more performance. Given equally good
compilers, Dylan should run a little faster than CL. Unfortunately, the
compilers aren't yet quite as good as, say, CMUCL, especially Gwydion
Dylan which was originally also CMU project but compiles through C
rather than directly to machine code. Still, Gwydion Dylan runs on a
lot more platforms than CMUCL, and on X86 the speed is much the same.
In theory Dylan allows building smaller executables for delivery. This
is decidedly *not* realized yet with Gwydion, where HelloWorld is
currently over 1.5 MB. That hasn't been a priority yet, but will
probably become one this year. Functional Developer manages about 17 KB
(with shared libraries).
> PS can you do macros with that syntax ?
Yes. And all that syntax *is* macros. If you don't like the syntax of
"if" or "define class" then you can make your own! (please don't)
Dylan macros are a kind of simple pattern-matching functional language
rather than procedural like CLs. Not as powerful, obviously, but good
enough to implement a close analogue of CL's LOOP macro (the Dylan "for"
statement), and the "meta" parser macros have been ported to Dylan. I'm
told you couldn't do "series" in Dylan -- I actually downloaded the CL
source once but it was soooo huge that I didn't really seriously try to
see how it worked and so don't know whether the claim is true. Oh well.
Dylan macros *are* Turing-complete, of course, and while you can't do
arithmetic or loops you can do recursion and token-string processing and
set up "constant" computations that will be evaluated at compile-time.
If you want to get into those sort of tricks then it's sure a heck of a
lot easier than to abuse C++ templates for the same purpose.
-- Bruce
"Marc Battyani" <·············@fractalconcept.com> writes:
> Does somebody know if there is a Common Lisp PDF generation library
> somewhere ?
>
> If not, are there anybody interested to work with me on such a project ?
A couple of months ago I played with PDF generation in CL. It was
fairly easy to generate a basic low-level generation framework, that
allows one to generate the hello-world.pdf file you included in your
posting with the following code-fragment:
---- cut ----
(in-package :pdf)
(in-pdf-syntax)
(defun write-hello-world (filename)
(with-open-file (stream filename :direction :output)
(with-pdf-file (stream)
(with-pdf-output (stream)
(make-label 'root
(make-dictionary #/Type #/Catalog
#/Pages (make-reference 'pages)
#/Outlines (make-reference 'outlines)))
(make-label 'outlines
(make-dictionary #/Type #/Outlines
#/Count 0))
(make-label 'pages
(make-dictionary #/Type #/Pages
#/Kids (vector (make-reference 'page1))
#/Count 1))
(make-label 'page1
(make-dictionary #/Type #/Page
#/Parent (make-reference 'pages)
#/MediaBox #(0 0 612 792)
#/Contents (make-reference 'page1-stream)
#/Resources
(make-dictionary
#/ProcSet (make-reference 'procset)
#/Font (make-dictionary
#/F1 (make-reference 'font1)))))
(with-pdf-stream (page-stream page1-stream)
(with-pdf-output (page-stream)
(pdf-begintext)
(pdf-selectfont #/F1 24)
(pdf-nextlineto 100 100)
(pdf-show " Hello World")
(pdf-endtext)))
(make-label 'procset #(#/PDF #/Text))
(make-label 'font1
(make-dictionary #/Type #/Font
#/Subtype #/Type1
#/Name #/F1
#/BaseFont #/Helvetica
#/Encoding #/MacRomanEncoding)))
;; Trailer Dictionary
(make-dictionary #/Root (make-reference 'root)))))
---- cut ----
As you can see, I mapped various PDF data types to the obvious CL
data-types, i.e.:
- Booleans to T and NIL
- Integers to integers and reals to reals (all non-integer CL reals
supported, coerced to single-floats for output)
- Strings to strings
- Names _not_ to symbols, see below
- Arrays to vectors
- The null object to the symbol NULL
Names are not symbols, because they are case-sensitive, don't have
packages, and don't need the general heavy-weight machinery of
symbols. So instead I invented my own interned strings, with a
PS-like reader-syntax #/PDF is equivalent to /PDF in PDF.
Dictionaries are their own objects, which currently use hash-tables
internally (though they might as well use alists or plists), because
that frees up lists to be interpreted as normal sequences of PDF
objects.
Streams are mapped to their own data-type, which can use thunks to do
delayed generation of their contents, and there's all kind of
automagic generation of size, etc., which would also allow transparent
encoding of contents with filters, etc.
Labeling in the PDF (numeric) sense is derived automatically from the
symbolic labeling at write-out time.
Operator invocations are also represented as a distinct data-type.
Those records are created by PDF operator functions, which are defined
by a simple macro, e.g.
;; Text-Showing Operators (5.3.2)
(define-pdf-operator pdf-show (string) "Tj")
(define-pdf-operator pdf-shownextline (string) "'")
(define-pdf-operator pdf-shownextline* (wordspace charspace string) "\"")
(define-pdf-operator pdf-show* (array) "TJ")
;; Type 3 Font Operators (5.5.4)
(define-pdf-operator pdf-setcharwidth (widthx widthy) "d0")
(define-pdf-operator pdf-setcachedevice (widthx widthy llx lly urx ury) "d1")
Starting from there, you can of course layer additional macros and
functions on top, e.g. code that automatically keeps track of
referenced fonts, and generates respective Resource entries, collects
pages, etc. I also did a bit of AFM parsing code (though its encoding
handling is fairly hackish), in order to do basic left leaded
paragraph layout.
Executive summary:
- Generating PDF itself is fairly easy to do, and meshes fairly well
with CL.
- The PostScript programming-language constructs that are missing in
PDF aren't really missed, since you've got all of CL to make up for
that, and in todays world, it makes sense to do the layouting stuff
on your 2 GHz P4, instead of your printer's 66MHz i960.
- Writing a decent layout-engine is still hard, and this will be
needed to generate more than trivial PDF files.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@pmsf.de> wrote
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > Does somebody know if there is a Common Lisp PDF generation library
> > somewhere ?
> >
> > If not, are there anybody interested to work with me on such a project ?
>
> A couple of months ago I played with PDF generation in CL. It was
> fairly easy to generate a basic low-level generation framework, that
> allows one to generate the hello-world.pdf file you included in your
> posting with the following code-fragment:
[snip...]
Thanks Pierre, interesting but too late... ;-)
I wrote it this WE.
From the explanations you gave, I think I have it more packaged. ie
with-page, etc. macros. The document internals are hidden. The user don't
have to know anything about dictionnaries, catalog, roots and so on. He just
puts a with-page in a with-document and that's it.
> - Writing a decent layout-engine is still hard, and this will be
> needed to generate more than trivial PDF files.
Sure. In the announcement post, I described several small sub projects to go
in that direction.
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Pierre R. Mai" <····@pmsf.de> wrote
> > "Marc Battyani" <·············@fractalconcept.com> writes:
> >
> > > Does somebody know if there is a Common Lisp PDF generation library
> > > somewhere ?
> > >
> > > If not, are there anybody interested to work with me on such a project ?
> >
> > A couple of months ago I played with PDF generation in CL. It was
> > fairly easy to generate a basic low-level generation framework, that
> > allows one to generate the hello-world.pdf file you included in your
> > posting with the following code-fragment:
>
> [snip...]
>
> Thanks Pierre, interesting but too late... ;-)
> I wrote it this WE.
Yes, I was kind of busy at the end of last week, so only caught up
with news on sunday...
> From the explanations you gave, I think I have it more packaged. ie
> with-page, etc. macros. The document internals are hidden. The user don't
> have to know anything about dictionnaries, catalog, roots and so on. He just
> puts a with-page in a with-document and that's it.
Yes, the explanations I gave were of the low-level substrate. As I
said in my posting, you can layer more high-level functions and macros
on top of that, and I've done that, too, e.g. I also have a with-page
macro, resource collecting, etc.
That said, I think you'll also want to have a clean and complete
low-level interface, since many of the more interesting features of
PDF are hard to abstract away without taking into account application-
specific information. So your users will probably want to write their
own higher-level macros, and for that will want to rely on a clean
low-level interface, that doesn't make them worry about the
lowest-level details of PDF...
As an example, there are lots of ways in which one can arrange page
objects into pages nodes, and some applications will want to take
advantage of the ability to create balanced trees, while many others
can just live with a single linear pages node...
Not that the interface I came up with while playing with PDF is as
clean or well-thought out as I'd want it to be...
I've now taken a quick look at your released code, and another
difference seems to be that I've tried to decouple the internal
representation of PDF and the externalization (writing it out) more,
so that you can have a complete representation of a PDF document in
core, which can be inspected and manipulated. Coupled with a parser,
this would make PDF manipulation possible, too. OTOH this will
probably make my approach a bit slower...
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Marc Battyani wrote:
>
> "Pierre R. Mai" <····@pmsf.de> wrote
> > - Writing a decent layout-engine is still hard, and this will be
> > needed to generate more than trivial PDF files.
>
> Sure. In the announcement post, I described several small sub projects to go
> in that direction.
The document construction tool we built atop Cells (a Garnet workalike)
offers wysiwyg imaging to screen/printer via metafiles. The constraint
mechanism makes layout pretty easy, and works like Pierre's approach: a
dynamic structure in core which maps to visual components and
subcomponents, traversed at image-time to output a page via OS drawing
API.
Sounds like a fit for generating PDF layouts. The imaging GF can
dispatch on the output stream, so we just need methods that speak PDF
instead of OS graphics API.
--
kenny tilton
clinisys, inc
----------------------------------
"Catch a wave."
- Brian Wilson