PDF 
Author Message
 PDF

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



Tue, 13 Jul 2004 06:39:41 GMT  
 PDF

Quote:

> 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/cod...>
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!       |                        
    /       /      `-----------------------'                        
   (   -.  |                              
   |     ) |                              
  (`-.  '--.)                              
   `. )----'                              



Tue, 13 Jul 2004 07:39:18 GMT  
 PDF
In article

Quote:

> 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



Tue, 13 Jul 2004 08:03:03 GMT  
 PDF


Quote:

> > 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



Wed, 14 Jul 2004 00:51:47 GMT  
 PDF


Quote:

> > 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/cod...
lisp/0.html>

Quote:
> 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



Wed, 14 Jul 2004 00:52:28 GMT  
 PDF

Quote:



> > > 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/cod...
> 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!       |                        
    /       /      `-----------------------'                        
   (   -.  |                              
   |     ) |                              
  (`-.  '--.)                              
   `. )----'                              



Wed, 14 Jul 2004 05:34:29 GMT  
 PDF
In article

Quote:



> > > 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



Wed, 14 Jul 2004 06:01:52 GMT  
 PDF

Quote:

> 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.

--

 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



Fri, 16 Jul 2004 08:00:23 GMT  
 PDF


Quote:

> > 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.

Quote:
> - 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



Sat, 17 Jul 2004 04:24:05 GMT  
 PDF



Quote:
> In article




> > > > 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 ?



Sat, 17 Jul 2004 05:04:02 GMT  
 PDF
In article

Quote:

> 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.

Quote:
> 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).

Quote:
> 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



Sat, 17 Jul 2004 13:55:08 GMT  
 PDF

Quote:


> > - 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



Sat, 17 Jul 2004 16:51:05 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. Search some String in PDF with PDF.OCX

2. Appendix.pdf - Appendix.pdf (0/6)

3. extract info from pdf doc,PDF to XML, HTML

4. CL-PDF the Common Lisp PDF Library 0.2

5. CL-PDF: need beta testers for cl-pdf 1.0

6. CL-PDF 0.45 (The Common Lisp PDF Library)

7. CL-PDF 0.41 (The Common Lisp PDF Library)

8. CL-PDF (Common Lisp PDF library) beta test

9. CL-PDF 0.3 (The Common Lisp PDF Library)

10. Acrobat 3.0 PDF Version of Tcl/Tk 8.0 Quick Reference - refbase.pdf (1/1)

11. Acrobat 3.0 PDF Version of Tcl/Tk 8.0 Quick Reference - refbase.pdf (0/1)

12. How to search in a PDF help file? Re: How to use F1 to lauch my own help file(.pdf) in an application

 

 
Powered by phpBB® Forum Software