Tired. But very happy with how SciFly performed today, and with the interest and enthusiasm it has generated both amongst influential people in CSIRO, and amongst various people who used it today. I made some changes to the 2D barcode scanning code this morning, to make it more robust, and overcome some of the issues that we’d experienced in the first couple of days. Largely, I made the serial port reading code more robust, by making it wait for more data, making a bigger buffer, and giving a longer timeout to receive the barcode data. This, combined with more error tolerant processing of the incoming data, meant that we had absolutely no problems with badges today.

After showcasing SciFly to Alex Zelinsky yesterday, I also managed to get Trevor Bird (our Chief Scientist), Gary Doherty (our head business development manager) and Steve Giugni (our deputy director) use the system, and all were very enthusiastic about the possibilities for commercialisation. Sounds exciting!

I think we did a really good job of evangelising and explaining the technology to a very wide range of people. In fact, I think we’d make reasonable marketers if it came to the crunch!! Over the 3 days, we generated almost 300 tailored flyers, which I think is an excellent result. I also found out this morning that Ross Wilkinson, our Information Engineering Lab Director, is willing to create some funding to install a SciFly installation at CSIRO reception at Marsfield (and hopefully Macquarie Uni too, if I can be convincing enough!), so that would be a great step forward too . I think it’s fair to say that our hard work has paid off, and that we’ve managed to impress a very wide range of people with our work.

Just got home from the energy-sapping task of setting up our CSIRO stand at CeBIT, in the Exhibition Centre at Darling Harbour. As per usual, it was a frustrating task, waiting for the stand being built around us, waiting for power and networking to be hooked up to the stand and so on.

Finally got SciFly setup by 6pm – it’s working with the printer and network connection, although the printer was a bit of hassle. It turns out that it’s very easy to crash HP ColorLaserJet 4600DN and 4650DN printers (and I mean hard lock, requiring a physical power cycle of the printer). These are big, enterprise model printers too (think something that’s about 1 metre tall). All you have to do is send it a valid PostScript level 2 file that has margins specified to bleed to the edge of an A4 page. Voila! Some internal postscript processing error, stack overflow and a hard-lock of the printer. So that took some hunting down to work out what was causing problems. The colour matching is also pretty crap, but it only makes the brochures look a brighter blue than they should, so I guess it’s not terrible.

As per usual, CSIRO hasn’t put any chairs on the stand! Argh!! So I can see another 3 days of tired legs coming up …

Drove home through peak hour tonight, and boy do I feel lucky not to have to do that on a regular basis :-/.

SciFly is a demonstration system for CSIRO’s Myriad
framework for information retrieval and delivery. SciFly’s first public
outing will be at CeBIT May 24-26.

SciFly delivers customised content based on user-selected interests.
In the current system, content is assembled into a dynamically generated
document and printed on-the-spot. Simultaneously a PDF document
is emailed to the user along with a plain text summary in the body
of an email.

This means that users receive relevant information presented in
contextually relevant formats:

• Paper flyer for immediate perusal
• PDF version for retention of information and later reference
• Plain text summary for mobile device access

The current demonstration of SciFly captures user details such
as name, email address and affiliation from a bar coded tag (as
supplied to conference delegates).The user then navigates a touch-screen
menu system to select topics of interest. The topics in this case
are based on the capabilities, projects and application domains
of the CSIRO ICT Centre.

Once all data is collected, SciFly assembles content tailored
to the specific set of interests expressed by the user, dynamically
fits the content to the space constraints of a double sided A4 page,
and adds relevant contact information, web links and higher level
context.

Importantly, SciFly does not just assemble pre-configured content,
but dynamically adjusts the amount and detail of content based on
the range of topics selected.

If while trying to use Java RMI you ever see an error like:

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: scifly.scanner.rmi.SerialPortServer_Stub


Go and check the CLASSPATH that was set from where you started the rmiregistry.exe (ie. the middleware server, as I think of things). Chances are very good that your project classes were not in the classpath for the rmiregistry. That error message is the rmiregistry complaining that it can’t find your class, NOT your client code.

This took me a little while to work out, so I thought I’d preserve it here, for when I forget again …

I’ve reaquainted myself with Java’s RMI features today, after realising that I’m going to have to run my SciFly application across 3 JVMs. Initially, I thought about using the XMLBlaster middleware that I have used in the past. XMLBlaster is an XML based publish/subscribe middleware that, in conjunction with Castor, allows objects to be serialised into XML and passed across a network. The nice thing about XMLBlaster is that it also has bindings for Python, Perl and other languages, which made it possible for me to use it as the glue between a realtime Java map-based GUI and a Python based simulator.

Anyway, getting back on track, I decided to refresh my experience with Java’s native RMI, which I must confess I haven’t even touched for at least 2 years. Anyway, after dusting off the cobwebs, I was impressed that the whole thing “just worked”! Start up the rmiregistry, and run your code: no stuffing around with configuration files etc. Admittedly, its functionality is limited, but if all you’d like to pass around are primitives and serializable objects like Strings, it’s the simplest and easiest choice. And, of course, it’s natively available with J2SE, so no need for extra JAR files.

The other thing I was impressed about was how neatly the rmic compiler is integrated into IntelliJ: 1 little check-box, and all my RMI stub compilation is silently taken care of. That’s much better than the other IDEs I have used in the past! A colleague tried the same with Eclipse, but apparently it needs an extra plugin to do RMI stub compilation. Bah humbug. Another (small) reason to prefer IntelliJ over Eclipse. And while I’m on an IntelliJ rave, let me again say that the CVS integration is second to none. I’ve never seen or used a nicer tool for resolving CVS conflicts and managing a CVS workspace. It makes working with a second-rate version control system absolutely bareable

Why is it so hard to print a PDF file in Java? Given that Java and PDFs normally play so well together (they are both, after all, pin-up software of code abd document portability respectively), I just assumed that it would be a very straight-forward thing to do. Certainly there are lots of available tools to create, edit, and read PDFs in Java (iText, JasperReports and others), but printing support seems to be sadly lacking.

I’ve looked at the javax.print API, but the conclusion conclusion I’ve reached after experimentating with my own code, is that it doesn’t support printing PDFs at all. Almost all the posts I’ve read on the web/discussion forums/mailing lists seem to concur with this fact. What a disappointment!

Several posts suggest using an external call to Acrobat, but my installed version (6.0) doesn’t seem to support the command line switches that are mentioned in a few places on the web.

As some context, I produce my PDF file using Apache FOP: starting with a simple XML file of my own flavour, I use an XSLT stylesheet to create a valid XHTML file. I then use another XSLT stylesheet to generate an XSL:FO file from the XHTML. Finally, I use FOP to generate my PDF file from the XSL:FO file. As cumbersome as it sounds, this is all working just fine. I can view and print my PDFs perfectly in Acrobat and Acrobat Reader.

The XSL Formatting Objects spec seems like a huge behemouth in terms of a standard (the entire XSL standard itself, of which XSL:FO is a part, probably weighs about as much as our car!). For my current project, however, I need the ability to control all sorts of typesetting features like leading, padding, font sizes, margins and borders, hyphenation of words and so on. The layout specification abilities of XSL:FO and FOP are largely up to this task, although FOP lacks a number of very useful parts of the XSL:FO spec in its current incarnation (0.20.5). I also use the intermediate formats for other reasons (e.g. the XHTML for web viewing, and to produce plain text output to send via email)

In the absence of java PDF printing support, I’ve currently settled on using XPDF’s pdftops tool (making an external Runtime.exec call) to convert my PDF to PostScript, and then printing the postscript file using the javax.print APIs.

This works OK, but not perfectly (I have some issues with page margins when converting to postscript), and I feel like there MUST be a better way. I have tried using FOP to produce PostScript from the XSL:FO files, but this doesn’t seem to work for my data (it just processes for ever without creating any useful output).

Anyway, be warned: printing PDFs in Java is much more of a headache than it should be!