A World Of Documents

Barcode4J 2.0 alpha 1 is now released. In the release notes I’m asking for feedback on the new functionality. I hope I’ll get a lot of good feedback (positive or negative) so I can soon do a final 2.0 release.

Thunderhead has kindly sponsored an implementation of the DataMatrix barcode symbology (ISO/IEC 16022:2000(E)) for Barcode4J. This is now the second 2D symbology I was able to add to the codebase. Although it’s not a complete implementation of the spec, all the important features are implemented. The restrictions (such as lack of structured append and ECI functionality) will be documented in detail on the Barcode4J website.

Since the specification is quite complex, it could be that there may still be a bug hidden somewhere, so I’d be very grateful for some feedback. The Barcode4J release is almost ready. Stay tuned!

Finally, a FOP release after the redesign without a beta tag! The most important changes since 0.92 beta besides a lot of bugfixing and stabilization work:

• Added support for the use of Open Type fonts.
• Support for the rgb-icc() function and for a proprietary cmyk() function (for device CMYK colors only through the PDF renderer so far).
• Enabled Copy/Paste from PDF content in Acrobat Reader for text using embedded TrueType fonts.
• Added support for PDF/A-1b and PDF/X-3:2003. (Note: this may still be a bit incomplete.)
• The Java2DRenderer (and therefore the print and bitmap renderers) is now offering the same quality as the PDF and PS renderers.
• Automatic support for all fonts available to the Java2D subsystem for all Java2D-descendant renderers (TIFF, PNG, print, AWT).

PDF has been around for some time and is widely used. Lately, with buying Macromedia, Adobe’s strategy towards PDF changes more and more, and IMO not in a good direction. The “open” standard is gradually closed down as Adobe adds features that forces you to buy their software. Anyway, 2007 is going to be interesting for the PDF world:

Microsoft popped up with their XPS which is similar to PDF but based on XML. That’s generally a good idea, but I don’t like Microsoft imposing their “interesting” XML-style on us (see WordML). Furthermore, they’ve reinvented the wheel by defining a completely new graphical XML language instead of leveraging existing standards.

Adobe answered with Mars, an “XML-friendly implementation of PDF syntax”. Without going into much detail with either standard, I prefer the Adobe approach because Mars is based on the standards SVG, PNG and JPEG. They’ve added only the stuff needed to make a round-trip from and to PDF.

Right now, I wish we had an answer coming from the real open community, something like OpenDocument, but for paged media. But throwing in yet another proposal won’t help much, I assume. We’ll have to see what happens and encourage Adobe to keep Mars as open as possible (for example by giving it to the W3C as a better alternative to SVG Print).

When I found out today, that Apache Harmony now publishes snapshot binaries for Windows, I just had to download one immediately and run Apache FOP under that VM. And guess what, the simple “readme.fo” example from FOP ran just fine. My second attempt with “images.fo”, however, didn’t work (problems with ImageIO and color profiles). Anyway, this means I shall keep an eye on compatibility with Apache Harmony while developing from now on.

One little thing I had to change in FOP to get a little problem was to replace the “UnicodeBig” encoding with “UTF-16BE” in FontFileReader.java (reads TTF files), as “UnicodeBig” doesn’t seem to be available, yet.

Now, I’ll have to set up Harmony for debugging in Eclipse. That, unfortunately, doesn’t seem to work just like that.

Today, I’ve uploaded a new barcode type for Barcode4J: the Royal Mail Customer Barcode (CBC). It’s a kind of “four-state” barcode. There are others like that, for example the Australian variant which uses Reed Solomon error correction instead of a simple checksum like Royal Mail. It should be easy to implement the Australian variant by just handling the checksum differently.

Next on the list for Barcode4J is finishing the DataMatrix implementation I’ve started a while ago. Looks like I can get enough new features together to release Barcode4J 2.0 by the end of the year.

Today, I was curious about the start times of .NET binaries created from Java sources using IKVM. I took the opportunity to add IKVM compilation (kvmc) to Barcode4J’s build.

If I create a shell script that runs Barcode4J’s command-line (PDF417 barcodes as EPS files) interface 20 times, I get the following times:

• IKVM 0.30: 15 seconds
• Sun JDK 1.5.0_08: 8 seconds

So, how does it look like if I do the loop in Java code and create 500 barcodes in one call?

• IKVM 0.30: 1900ms (first 500), 1400ms (second 500 and subsequent)
• Sun JDK 1.4.2_10: 1800ms (first 500), 1550ms (second 500 and subsequent)
• Sun JDK 1.5.0_08: 1800ms (first 500), 1550ms (second 500 and subsequent)
• Sun JDK 6.0beta: 1700ms (first 500), 1400ms (second 500 and subsequent)

Looks like JVM startup time isn’t so bad compared to .NET. But I don’t know how much overhead IKVM brings into the picture.

(I’ve taken all timings multiple times and have rounded the averages to 50ms. Operating System: WinXP SP2, .NET Framework 2.0. Machine: Custom-built AMD Athlon 64 3200+)

Yeah, I know. I hope I’ll have something worth reading from time to time. We’ll see…

This is the weblog of Jeremias Märki.