Slashdot Mirror

While I realize this is supposed to be an amusing turn of phrase, there are actually quite a few tools out there. A few that I like are:

PDFBox - OSS Library for modifying PDFs on the fly.
FOP - Use XSL-FO to design printable page layouts in XML, then use FOP to transform them to PDF documents.
Foxit Tools - Alternative to the overpriced Adobe products.
OpenOffice - The built-in support for PDFs is absolutely wonderful. I rarely give out DOC files anymore.
FPDF - PHP PDF generation tools.
iText - A great library for your own custom PDF generation.

Those are just a few. The PDF format itself is actually not too bad. (When Adobe isn't breaking it with needless revisions, that is.) It's biggest strength is that the psuedo-text nature of the format allows one to diagnose the internals of a file pretty easily. Its greatest weakness is that things like text fields are needlessly convoluted. At the end of the day, though, it's a pretty good format.

No, this is common practice, because it often just makes sense. Maintaining a set of common components means that when you do reuse a piece, you can maintain it once, and release the updated component to all of the affected software. So if you have 30 different customer applications that all use the same iText based report generators, you only have to fix a bug in one place, or add a new feature (like a new type of chart) in one place, and you can release the update for all 30 applications (and satisfy your 30 maintenance contracts). I have a set of my own components and FOSS components (like iText), that I reuse for various common features, and I'm sure the big companies (CA for example) do the same.

I think a lot of people would notice, because quite a few middleware, reporting tools and websites use iText to generate PDF's. Some examples are Adobe's (formerly Macromedia's) Coldfusion, Google Calendar and JasperReports. End users may not know it, but it wouldn't surprise me if most PDF's out there are generated with tools not sold by Adobe (not only iText, but also e.g. pdflatex and things like that).

Granted, I'm not talking about Command and Control systems, but the DoD has been using OS Software for years now. I know because they are using iText to produce billions of PDF documents. I have been mailing with DoD developers regularly in the past (and neither I, nor my product is American). It's not as if they have changed their mind about OSS overnight. The remarkable thing is that they are now coming out with a policy about OSS, and that they are considering to use it on a larger scale. (Yes, we're talking about Operating Systems now!)

It's clearly FUD. There is absolutely no ground for such a lawsuite. Everybody can write a PDF engine and distribute it for free.
The proof? Adobe is shipping a product (MacroMedia's Cold Fusion Server) with my F/OSS library iText to produce PDF from Cold Fusion pages. I never heard anybody at Adobe complain because I wrote a free PDF engine.
As a PDF specialist I know that the big money isn't in the conversion from Word to PDF. PDF is a lot more than text documents. The Acrobat product family is used for completely different reasons than a product like MS Word or a free library like iText.

Hello all,
my name is Bruno Lowagie and it was a pleasant surprise to see that the PDF that is created when you click on the print icon in Google Calendar is generated by iText: see http://www.lowagie.com/iText/
That's my own little Java-PDF library! This is GREAT!!!

package ConsoleApplication1;
 
import com.lowagie.text.pdf.*;
import com.lowagie.text.DocumentException;
 
import jp.ujihara.java.util.HashMap;
import jp.ujihara.java.util.Iterator;
import java.io.IOException;
import java.io.FileOutputStream;
 
public class Program
{
    public static void main(String[] args) throws com.lowagie.text.DocumentException
    {
        try
        {
            PdfReader reader = new PdfReader("c:\\temp\\input.pdf");
            PdfDictionary acro = (PdfDictionary)PdfReader.getPdfObject(reader.getCa talog().get(PdfName.ACROFORM));
            acro.remove(new PdfName("XFA"));
            PdfStamper stp = new PdfStamper(reader, new FileOutputStream("c:\\temp\\output.pdf"));
            AcroFields af = stp.getAcroFields();
            HashMap f = af.getFields();
            for (Iterator it = f.keySet().iterator(); it.hasNext();) {
                String name = (String)it.next();
                System.out.println("Field is " + name);
            }
            stp.close();
            System.out.println("File closed.");
        }
        catch (IOException e)
        {
            System.out.print("Exception caught!");
        }
    }
}

You missed iText.
You can write PDF syntax by using some Java methods (http://itextdocs.lowagie.com/tutorial/directconte nt/index.html), or translate operations on a java.awt.Graphics2D object to PDF operators and operands automatically (http://itextdocs.lowagie.com/tutorial/directconte nt/graphics2D/).

You missed iText.
You can write PDF syntax by using some Java methods (http://itextdocs.lowagie.com/tutorial/directconte nt/index.html), or translate operations on a java.awt.Graphics2D object to PDF operators and operands automatically (http://itextdocs.lowagie.com/tutorial/directconte nt/graphics2D/).

Everybody knows Adobe as the inventor of PDF, but unfortunately the company was nowhere on the servermarket. MacroMedia on the other hand has a more than interesting server product: Cold Fusion. The combination of both technologies looks very promising to me.
But wait a minute! Weren't you able to produce PDF documents with Cold Fusion? Of course you were: ColdFusion MX 7.0 is shipped with the iText.jar (iText, a free Java-PDF library, hosted on SourceForge, originally developped by yours truly).
And now comes the funny part: due to some regulations I don't fully understand, MM can't use any Adobe technology (or vice versa) till the end of the year. This means that the new company Adobe Systems will be shipping iText in their products for PDF generation.
The company that invented PDF, shipping my F/OS library hosted at SourceForge! What a weird way things work out some times.

Hrm...I thought you meant that you were copying-and-pasting code. In my experience, abused like crazy in scripting.

But you meant you were copy-pasting URLs to find PHP libraries?

BTW -

generating PDF's
http://www.lowagie.com/iText/

dynamic graphics
http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec. html

menus
huh? If you have a cms like http://opencms.org/, which you should use anyway - you got menus.

DB interfaces
http://hibernate.org/

I'm currently building a variety of petroleum engineering tools in Java. Here are the libraries I've found most useful:

JFreeChart - for all your plotting needs. Robust, quick, and fairly bug free. Not perfect, but hackable.

iText - a free Java PDF library. My preferred method for creating reports, especially since a lot of my output needs to be e-mailed or submitted to the government, not printed out.

JAMA - a Java Matrix package. The fact that this library has a working singular value decomposition has saved me bunches of time programming a boring and tricky algorithm. I guess it has other stuff, too.

I did something similar with the iText libraries for java. Generate PDF's to your heart's content-- place text and images into the page, flatten it, and *pop* out comes your document.

iText does the trick.

Add iText to the mix. It is a Java library capable of doing almost anything. The only down side is it is slower than native C libraries out there. If speed is a real issue, you could compile your iText Java classes using GCJ and convert them into native code. I'm thinking doing so will seed up your application. I haven't tried converting it to native code, has anyone?

iText is an open-source Java PDF library that works pretty well and is fairly simple to use.

Also, JFreeReport is an open-source Java reporting library that makes it easy to generate reports in various formats - PDF, HTML, CSV, Excel, plain text.

I'm no Adobe fan, but I've been working on PDF format for a few years and I found it great.

First, the filesize is ridiculous.

If you're comparing to plain text, yes. Otherwise, PDF have a built-in format that allows the producer to compress the PDF's streams (ie text and images) with a LZW algorithm.

They are in a closed format

These are java libraries for creating and editing PDFs :

pj[Open Source, GPL]
Big Faceless[Commercial w/ Evaluation]
retepPDF[Open Source, LGPL]
Java Pdf Library[Open Source, LGPL]
PDFGo[commercial]
rugPDF0.20[Open Source, LGPL]

By the way the closed format has an open specification : http://partners.adobe.com/asn/developer/acrosdk/do cs/PDFRef.pdf

I use some of the ones other users kindly mentioned, in addition to a wonderful Java PDF library called iText

It's nice to be able to produce the things from a Java Servlet dynamically.

We have found that Java and the J2EE work great for web apps that also need to have these types of reporting functions. Check out iText - a JAVA-PDF Library for the api that will make a pdf from your data.

Have a look at iText for generating pdf in a Java environment. It isn't going to give you the 'drag and drop' report building, but it seems to be one of the most capable pdf libraries for Java.