[pdf-devel] GNUpdf and other PDF projects

[Sylvain Beucler]

Hi,

I'd like to start a wiki page to reference other PDF projects, explain
which one we could reuse and which ones we won't/can't (and why).

It also explains part of the "goals and motivation" of the project: a
person on IRC was wondering why we were reimplementing from scratch
rather than improving existing software.

I could point 2 issues, which I essentially gathered from Jose's talks
and articles such as http://www.linux.com/feature/122195

1. Currently, the most(?) advanced free code for reading PDFs is
   libpoppler, itself based on xpdf, which is GPLv2 only (not GPL2+ /
   "or later"). This causes issues in chain, e.g. GNOME software such
   as Evince can't upgrde to GPLv3, and thus this is an incentive not
   to upgrade Gtk to LGPLv3. GNUpdf is GPLv3+.

2. The poppler/xpdf code was not designed as a library from the start
   and is difficult to adapt to other projects than renderers/readers
   - in particuler it may not be convenient to implement PDF
   editors. GNUpdf uses a generic and layered architecture for better
   flexibility, inspired by Adobe's own PDF Library API.

Aside from these secondary goals, the main one remains:

0. Currently, Free PDF is lacking support for the latest features
   (annotations, FDF forms, edition, <please add other '09 issues>)
   - and we're gonna improve it :)


Comparison with existing projects - please comment :)
OK => can reuse code from this project
KO => cannot reuse code from this project

mupdf in particular is intriguing.


  - xpdf: C++, http://www.foolabs.com/xpdf/

    License: KO - GPLv2

    License upgrade?
    - afaik xpdf maintainer doesn't wish to

    PDF Compatibility?


  - libpoppler: http://poppler.freedesktop.org/

    Poppler's goals (from the README) are:
    http://cgit.freedesktop.org/poppler/poppler/tree/README

    - libifying xpdf and avoid code duplication (and the resulting maintenance 
effort)

    - modernizing the code by reusing existing libraries such as
      fontconfig (font matching) and cairo (graphics engine)

    License: KO - GPLv2 with bits of GPLv2+

    License upgrade?  non-xpdf code is GPLv2+ already

    PDF Compatibility: ?


  - mupdf (PDF library) + fitz (vector graphics engine)
    http://ccxvii.net/fitz/ - Fitz and MuPDF
    http://ccxvii.net/darcsweb.cgi?r=fitz - fitz change log
    http://ghostpdf.com/new.html - GhostPDF

    Only for implementing readers?
    What's the project activity?

    License: KO - GPLv2

    License upgrade?
    mupdf switched from AladdinPL to GPL in 2006
      
http://github.com/kjk/mupdf-official-mirror/commit/5f9a26bdcb499513dca4fb2cb63cd4bf47edd122
    so they may switch to GPLv3 too.
    Anybody contacted them already?

    PDF Compatibility: mentions 1.5


  - SumatraPDF - PDF reader, Windows-only but Free Software,
    http://blog.kowalczyk.info/software/sumatrapdf/

    Uses modified mupdf: http://krzysztofkowalczyk.pbwiki.com/mupdf

    License: KO - "Sumatra PDF is distributed under GPLv2 license."
    (no proper license notices)

    PDF Compatibility: mentions 1.6

      "Sumatra has a minimalistic design. Simplicity has a higher
      priority than a lot of features."
      -> incomplete PDF support?


  - GNU GhostScript: -> "In December 2005, Marchesi tried to update
    the Ghostscript PDF interpreter that gv uses, only to find it was
    technically impractical."  -- http://www.linux.com/feature/122195

    Details? Limitations?

    License: KO - GPLv2 (huh?)

    PDF Compatibility: ?


  - iText - Java library, PDF generation, used by pdftk,
    http://www.lowagie.com/iText/

    License: OK - dual-licensed MPL/LGPLv2+, 

    
  - pdftk: command-line PDF manipulation: only tool I know for forms
    and forms data support; also crypt/encrypt, splits, watermarks...
    C++ code based on iText (Java) through GCJ CNI (Compiler Native
    Interface) http://www.accesspdf.com/pdftk/

    License: OK - GPLv2+

    iText is meant for generation, but pdftk is able to filter existing PDFs


  - PDFedit - PDF editor, based on xpdf code
    Supports PDF annotations
    http://pdfedit.petricek.net/index_e.html

    License: KO - additional code GPLv2 only

    stability issues?


  - Evince / Okular - GUIs on top of libpoppler (for the PDF part,
    they also support other formats than PDF)
    http://www.gnome.org/projects/evince/
      "Simply a document viewer"
    http://okular.kde.org/
      "More than a reader"


  - gv, kPDF, Yap - GUIs on top of ghostscript
    http://www.gnu.org/software/gv/
    http://kpdf.kde.org/
    http://www.gnustep.it/marko/GPSText/


  - Skim: despite being mentioned at pdfreaders.org, it uses a
    proprietary PDF library called "PDF Kit", itself part of Quartz
    framework - http://developer.apple.com/Cocoa/pdfkit.html. No
    go. Do *not* confuse it with old PDFKit/PopplerKit from
    http://home.gna.org/gsimageapps/, based on xpdf and popller
    respectively.


  - GNUpdf: general purpose, in progress, C / POSIX

    License: GPLv3+

    (Planned) PDF Compatibility:
      http://gnupdf.org/Goals_and_Motivations
      ISO-32000 (PDF 1.7)
      ISO 19005 (PDF/A)
      ISO 15930 (PDF/X)


  - GNU Juggler: GUI on top of GNUpdf


  - Any others? :)


-- 
Sylvain