A World Of Documents

The W3C’s SVG working group has somewhat silently updated the SVG Print Working Draft last month. SVGP adds elements to embed multiple pages in a single SVG 1.2 file plus it adds color handling to match the additional requirements for printing. The draft seems a lot clearer and more useful now. It has been split into two parts (Primer and Language).

As I hinted in an earlier post, I feel that SVG Print may already be coming too late (although it has been in development for more 4 years now). Mars looks more interesting (a spec update is coming up, I heard). The packaging of binary resources (images, fonts etc.) in a ZIP file is very efficient and versatile while this is sort of an unsolved problem in SVG Print. The Primer hints at the use of Multiplex MIME (RFC 3391) which is possibly more difficult to handle than a ZIP archive. Over all SVG Print gives me the impression that it’s not much more than a research project by Canon’s research labs. Not that Adobe’s Mars is much more than that right now. In that regard, Microsoft’s XPS has probably evolved further. Too bad, Mars is still my favourite approach if I had to choose an alternative to PDF.

It didn’t suffice that Adobe Acrobat 7 used and expected a PDF/A namespace from an old specification draft (http://www.aiim.org/pdfa/ns/id.html). Now, it turns out that the official ISO document (ISO 19005-1:2005) had to be corrected, too. The document uses “http://www.aiim.org/pdfa/ns/id” as the PDF/A namespace. After a problem report today from a client trying out Acrobat 8 on a supposedly PDF/A-compliant file generated by Apache FOP, I found out that the PDF/A committee has published a corrigendum in which they are correcting the PDF/A namespace to “http://www.aiim.org/pdfa/ns/id/” (note the trailing slash). Furthermore, I think there’s an additional problem with metadata handling since the “Subject” is not mapped to dc:subject anymore, but to dc:description["x-default"]. Looks like I just got some more work to do…

After a long time idling and switching caretakers more than once, JEuclid seems to have resurfaced from the half-dead. Max Berger and a few others are making the MathML implementation (written in Java and licensed under the Apache License v2.0) leap forward. That effort includes a new FOP extension for MathML based on the old one FOP has in its example folder. Good news not only for the DocBook community. Kudos to Max & Co.!

Want to try it out in 2 minutes? Create a little math expression in OpenOffice 2.x, save it in ODF or MathML format. Then just start JEuclid’s MathViewer application using WebStart and open that file.

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+)