XMLWorker Documentation ( itextdoc )

As promised after the release of iText and XMLWorker, there would be a release of itextdoc. Our project to parse our own documentation for the XMLWorker with the XMLWorker.

The itextdoc maven plugin is now available from Maven Central. To use it in your build cycle of a project add

<plugin>
   <groupId>com.itextpdf.maven</groupId>
   <artifactId>itextdoc</artifactId>
   <version>0.1.0</version>
   <executions>
    <execution>
      <phase>package</phase>
      <goals>
         <goal>create</goal>
      </goals>
      <inherited>false</inherited>
    </execution> 
   </executions>
</plugin>

What does it do and how can you use it?

itextdoc transforms html to PDF with iText and XMLWorker. Optionally you can transform the html to a styled website but that’s still under construction.

By default the plugin looks for a folder itextdoc under the src folder. Easily configure another folder by adding a configuration to the executuion.

<configuration>
  <flatsite>true</flatsite> // enable generation of a site
  <site>true</site> // enable generation of a javascript driven site
  <src>src/doc</src> // change default source directory
  </configuration>

Currently only a doc.xml file is accepted as the xml file wherein you define the different html files (or one) and your CSS file.

The result is something like this. The initial documentation for itext doc, not styled with custom css.

To create a website use the site and flatsite configuration parameters. But the site generation is not yet fully functioning.

Where to request features and report bugs?

At sourceforge features, bugs.

Other links
check for latest version
Ohloh
iText

Note: don’t forget iText, XMLWorker are AGPL.

itext-questions

Mailinglist mails on itext-questions

Sometimes we receive things like:

Dear all,
Fedora packagers have one big problem. The code is licensing on AGPL for
all this project?

regards

By Gossling, they have only 1 big problem, they are lucky !

How do we react to that… saying yes it’s AGPL. And saying they are lucky to have only one problem. The problem isn’t even explained.

Do I care that Fedora packagers have problem? no not really. I even wonder why the hell they want to package iText® in a linux distro. It’s a Java library, application deployers/developers add it to their lib folder or application server library folder, (or even add it through OSGI now). I’ve never used in linux distro embeded java libraries. I add them myself (preferably with maven) then I know what has been added.

iText® XLMWorker 0.9.2

Today we have released 0.9.2 of the XMLWorker!

Get it here

Note: We have not yet added this project to maven central.

Some of the changes taken from commit messages:

  1. * Body -> now uses nonewlineparagraph
    * xml.parser…. takes namespaces into account. tag <ns:atag> now submitted as ‘atag’ with namespace ‘ns’
  1. Rowspan fix when determining and comparing the width of cell with its predeseccors. Rowspan is now checked not only for the current column, but for the following columns as well.
  1. * Table / TableData / TableRowElement – revised Table after receiving IndexOutOfBounds – table should now keep working even with inner non table tags. e.g. a <p> in <table>, they will all be taken as caption for the table though. – Table code adapted to allow page-break-before on <table> – didn’t test what happens when it’s on <td>’s yet. | Note: Emiel should revise my changes here
    * XMLWorkerHelper – removed deprecated methods
    * this commit also adds some javadoc
  1. * pom: add osgi data
    * xmlworker-html: allow parsing snippets with no root tag
    * page-break-before can add Chunk element to currentContent list -> stackKeeping processors should check for other then the expected elements (like in OrderUnoderedList ) – probably need to check that in Table tag processor too ) —
  1. the dummy tag processor should really be a dummy. Now it is, it does not call code from AbstractTagProcessor
%d bloggers like this: