If you're considering creating PDFs then PDF::API2 is definately worth a look at.

pdflib_pl.pm (which was mentioned) isn't slow, as it's a thin XS layer over C code. PDFLib.pm is an OO layer over that, and is fast too (as it's a fairly thin but intuitive layer).

But do beware of the license, which will require purchasing for commercial public web work, despite the fact that you have the source code (it's not "open source").

slightly awkward due to production of files etc

We use LaTeX extensively, producing automated documents from templates that are printed to a postscript printer. The results are very professional. Not as easy to create as a Word document perhaps, but the results and versatility are worth your initial pain.

Via standard PS and LaTeX tools, you can easily convert a LaTeX document into PDF as well, or even plain text.

All right, I was looking for a problem with LaTeX, which happens to be a system that I admire greatly. The files I meant are partly the .aux, .log etc but also having to create a .tex file to process. It is not as nice as keeping it all in memory and there is a bit of cleanup involved too.

All said LaTeX may well be the way I go although I will of course take a good look at all ideas offered here.

I understand your concern, having a bunch of files lying around is not quite as elegant.

However such a 'problem' is ripe for abstraction into a module. Create some methods to create, store and fetch pdf files, and hide all that LaTeX magic externally.

Even better, make the file generation work for you. The .dvi file that LaTeX generates can be used again and again. Do some simple date checks of your source file against that of the .dvi file and you effectively have an efficient cache.

We use such a thing here in a billing system. Statements are generated and stored on the disk. The .tex, .txt and .ps files are all stored. When someone wants to reprint or reshow the statement, it fetches the appropriate .txt or .ps file. If it doesn't exist, it regenerates them from the .tex file.

In that way, whenever we are short on disk space (or if we want to minimize the amount of files we are moving from machine to machine during a hardware upgrade :-), we just nuke everything but the .tex files, and everything still works, if more slowly.

Not very Perl related; but when I use LaTeX the fonts always come out looking very, uh, LaTeXish. What am I doing wrong?

 - ask

-- 
ask bjoern hansen, http://ask.netcetera.dk/   !try; do();

If this sounds like what you need, try RTF::Document, found at http://search.cpan.org/doc/RRWO/RTF-Document-0.64/Document.pm.

Or here's a code sample of a basic rtf if you prefer to RYO.

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset
+0 Arial;}{\f1\fnil\fcharset2 Symbol;}}
\viewkind4\uc1\pard\b\f0\fs28 Edwards School\b0\fs40\par
\fs20 Grade Report\par
\par
Blah - Blah\par
\pard{\pntext\f1\'B7\tab}{\*\pn\pnlvlblt\pnf1\pnindent0{\pntxtb\'B7}}\
+fi-720\li720 yaketty\par
{\pntext\f1\'B7\tab}scmaketty\par
{\pntext\f1\'B7\tab}placketty\par
}
[download]

-Jerry
http://www.mtsol.net
"In my line of work, I don't invent many wheels. I just custom fit wheels already in place."

The problem with RTF is certain parts of it are open to interpretation by the client that opens them. Widow and Orphan control being just one aspect, font control being another. This means that you can't absolutely 100% guarantee the look of the output. PDF doesn't suffer from that problem, luckily, however you are right that in general you can't edit a PDF.

However have you also considered using XSL FO? You could use a system() callout to create the PDF's, either to Apache's FOP, or to PassiveTeX, and the results are very nice, and XSL FO is reasonably easy to work with.

Finally another option is to use HTMLDoc which also produces really nice results.

Thank you all for your comments on my post.

In my particular situation I wanted to create PDFs from data in a database, so editing the resulted PDFs is not an issue. The idea of creating rich text files though is a good one and I'll probably use it for other parts of the system.

The three main options seem to be produce PDFs directly from the code, produce .tex files and process them with LaTeX, or turn html inte PDFs using something like htmldoc.

I think that what I will do is produce PDFs by translating HTML. The logic for this is that I have to create the HTML anyway for when I display data on the web browser so it seems silly not to simply use the same layouts on the paper. If there is then a situation where doing this is innapropriate then churning out tex files seems a good bet - it very nicely separates the logic and the layout.

Finally I will produce PDFs directly from the code in only very rare situations, for example where I need the greatest control over where text or graphics appears on the page. This will be so specialised that t will be worth the effort of cooking up the code.

My situation is probably quite unique in that I need to produce may different types of paper output and so cannot invest too much time on each one. If I was just producing a single output, say a bill or a certificate then much more time could be justified.

Thank you again for all your input.

What kind of files are we talking here? When we say "pretty" do we mean, organized and readable? Because it might be that good ol' print formats would be what you're looking for. However, I would assume that the responces that everyone is giving mean otherwise.