FinTS 3.0 is actually a remaining of HBCI 2.2, and is meant to be the successor of HBCI that way. The technical details do not deviate that much, so that it can be expected that HBCI open source implementations will integrate FinTS in the future.

For the best discussion about this that I found so far, see this: http://www.ruby-forum.com/topic/177210

There seems to be only two (or two major) open source HBCI implementations: HBCI4Java and AqBanking. Of these two, AqBanking seems to be the preferrable one (yet without respect to Ruby integration). Reasons:

• AqBanking is behind several major HBCI open source applications: AqFinance, QBankManager, GnuCash, KMyMoney, AqBanking-CLI (source), while HBCI4Java is behind Hibiscus (source).
• AqBanking is in active development as of 2010-08, while HBCI4Java’s latest version is from mid 2009.
• AqBanking offers HBCI, OFX and PayPal in the open source version, while HBCI4Java offers HBCI (source).
• Both are cross-platform compatible for Linux, Mac OS X and Windows.
• AqBanking is twice as popular as HBCI4Java (40,000 vs. 18,000 Google search results).

Also, the integration into Ruby is simpler. One can either use exec() with the command line client coming with AqBanking as the simplest solution, or use the Ruby C bindings with the AqBnaking library, which is written in C (see here). With HBCI4Java, one could either use Ruby Java bindings (like they do in the POI project), port the application to JRuby, or a rather solution using the GUI tool Hibiscus and XML-RPC (example), which is however quite clumsy when it should be used on a server (as it’s a GUI tool).

Result: I recommend to use AqBanking with CLI based or Ruby extension based integration.

Task

I had to run existing ActionScript code on a headless Linux server and decided to do it by running an AIR application with the Xvfb virtual X server, as reasoned for in my article “How to run ActionScript in headless mode (on Linux without X server)?“.

Problem

I did not think that running an AIR application on a headless server would be that large a problem. Here is why it is:

• The normal Adobe AIR 1.5 runtime installer is a GUI-based installer, no RPM oder DEB packages are available.
• The normal process of installing an AIR application is also a GUI-based process, so not apt for a Linux headless server.
• AIR applications itself are GUI-based, always needing an X server. See more on that in this article already linked above.

Discussion

In theory, installing the AIR 1.5 runtime and the AIR application would be possible via VNC or some Xvfb hacking to enable a remote desktop. In practice, I searched for a better solution.

There are two options; first, the headless installation of Adobe AIR 1.5 Runtime if you grab the version you get after applying to distribute AIR. Second, Adobe AIR 2.0 (in beta as of 2010-05-10) offers installation packages for various Linux systems. You can download Adobe AIR 2 Runtime beta Linux packages from Adobe labs. This enables headless installation with ease. The exception is if you are on a 64bit Linux system, in which case you need to follow along the well-done article “Install Adobe AIR 2 on 64-bit Linux distributions” from Adobe.

However, this approach faces another problem: AIR applications normally come in .air files, and these files cannot be installed on a headless server with a AIR Runtime – normally. The only exception is when using a special installer made available by Adobe after successfully applying for a AIR Runtime redistribution licence [source]. You can apply to distribute AIR (as already linked above). The bad thing is that, at least currently (2010-05-10), a redistribution installer is not available for Linux, and it is not allowed to modify another redistribution installer for that purpose; see the Adobe AIR Runtime distribution FAQ on “Can I distribute the Adobe AIR Runtime on an operating system if a version specific to that OS is not provided?“. So the “Adobe AIR Application Installer -silent file.air” option is not possible on Linux. (If you try that with the standard AIR installer, it says “install failed (see log)”, but even after enabling AIR logging, the log stays empty.)

The solution that I found is to deploy not the .air file but the .swf file and application .xml file that are generated during development in the bin/ output folder. These can be launched with the Adobe debug launcher (the adl command). And adl comes within the Adobe AIR SDK, which is installed by just unpacking, very apt for a headless server. Note: you do not need to install the Flex SDK also if you just want to run an AIR application this way.

By deploying the compiler output directly, we also get around the process of creating the and signing .air installation file. In case you need to do that anyway:

• First try out the FlexBuilder integrated wizard along the Adobe instructions “Creating your first Flex AIR application in Flash Builder or Flex Builder: Package, sign, and run your AIR application“.
• If that fails and you are given a strange error code, have a look at the ADT error messages.
• If that didn’t help either, follow instead the Adobe instructions “Creating your first AIR application with the Flex SDK: Create the AIR installation file“. That finally worked for me.

The last problem is that running an AIR application on a headless server needs an X server in any case. We want to use the Xvfb virtual X server, as already reasoned for in my article “How to run ActionScript in headless mode (on Linux without X server)?“. Brett Adam designed and shared a simple Xvfb wrapper for running an AIR application with Xvfb. It turned out however that the program xvfb-run, coming with Xvfb at least in the Ubuntu 9.10 package, does exactly the same job and offers also more options; so we stick with that.

Solution

Here is a combined list of instructions how to get all this to work, according to the decisions outlined in the discussion section:

1. Download the Adobe AIR SDK to your server. Download the Adobe AIR SDK manually and upload to your server, or better use:

   wget http://airdownload.adobe.com/air/lin/download/latest/AdobeAIRSDK.tbz2;

2. Install Xvfb. On Ubuntu systems, install the packages xvfb and xauth for that.
3. Install the Adobe AIR SDK on your server:

   mkdir /usr/local/share/applications/air-sdk-1.5;
   cd /usr/local/share/applications/air-sdk-1.5;
   tar xjvf AdobeAIRSDK.tbz2;
   ln -s /usr/local/share/applications/adobe-air-sdk-1.5/bin/adl /usr/local/bin/;
   ln -s /usr/local/share/applications/adobe-air-sdk-1.5/bin/adt /usr/local/bin/;

4. Upload your AIR application to your server (just the .swf and .xml file in you project’s bin/ folder).
5. Launch you application with xvfb-run:

   xvfb-run -e log.txt --auth-file Xauth --server-num=99 adl Application-app.xml

6. If you need to run your applications with arguments, do it like this:

   xvfb-run -e log.txt --auth-file Xauth --server-num=99 adl Application-app.xml -- --arg val

7. If you need to keep Xvfb running (e.g. because you need to start the AIR application many times and want to get rid of the 3s delay to start Xvfb every time to improve performance), here is a technique for that. It is re-using xvfb-run, letting it run a command that never returns, and then lets other applications connect to the started X server:

   xvfb-run -e log.txt --auth-file Xauth --server-num=99 sleep 1000d &;
   DISPLAY=:99 XAUTHORITY=Xauth adl Application-app.xml -- --arg val

Layout means, using the “float:” attribute to position whole columns and large elements that will contain text etc..

First rule: use the “clear: both;” CSS attribute only after all content in the HTML source. Because it affects not just the floating happening in the current div, but enforces positioning below all elements that have a “float:” CSS attribute (i.e. below the one reaching most into the document). If no text follows, this is no harm, and is used to extend the height of the floating divs to the height of the ones with the “float:” attribute.

As you cannot use any “clear:” attribute within the document, you need another means to stop positioning elements from left to right and again position them below each other. The good thing is, this is done automatically: block level elements like divs that contain no explicit width setting (other than 100%) use up 100% of the available space, not allowing other elements to be to their left of right. Only if giving them also a “float:” attribute, their width is just as wide as their content. So in the following example, you have two columns:

<div style="float:left; height: 100px;">column 1 (as wide as its content)</div>
<div>column 2 (as wide as space is available)</div>
<div>also in column 2, not a column 3</div>

Now how do you position more than two elements next to each other? By setting the “float:” attribute on them also. A “float:” attribute only means to allow one other block-level elements on either the right side (for “float:left;”) or the left side (for “float:right;”). If that floating block-level elements does not consume all the available space, the “float:” attribute setting does not (!) cause to fill the remaining space with other block-level elements. For that to happen, for one more block level element on the side, the floating elements must allow to be floated, too, by repeating the “float:” attribute setting. So you can create three columns like this:

<div style="float:left; height: 100px;">column 1 (as wide as its content)</div>
<div style="float:left;">column 2 (as wide as its content)</div>
<div>column 3 (as wide as possible)</div>

But not like this:

<div style="float:left; height: 100px;">column 1 (as wide as its content)</div>
<div width="100px;">column 2 (as wide as its content)</div>
<div>column 3 (as wide as possible)</div>

Because float elements are out of the normal element flow, a “height:100%” setting does not make them as heigh as their parent. If you want to achieve that effect anyway (e.g. to extend the background of side columns to the height of the content column), you need to use the “nested divs” layout of CSS Zen Garden, which goes like this (for three columns):

<div id="level1_leftrightcenter">
  <div id="level2_left" style="float:left;">left column content</div>
    <div id="level2_rightcenter">
      <div id="level3_right" style="float:right;">right column content</div>
      <div id="level3_center">
        <div id="level4_center">center column content</div>
      </div>

    <br style="clear:both;" />
 </div>

Note that the content column is the only one without a “float:” setting. This is to ensure that its width is as wide as possible (resulting in a variable width layout), instead of being as wide as its content (as when applying the “float:” attribute). Note also that all content of the center column is in another “level4_center” div; if there would be direct text content or more than one block element in the “level3_center” div, text could appear below the “level3_right” div due to floating, but this way it will always be to its left, as the “level4_center” div starts left of the “level3_right” div and, as a block level element, has a rectangular shape.

Also note that the values of the “float:” and “clear:” attributes are badly named:

• “float:left;” actually means “this element is on the left side, allowing to be floated on the right side”, which is counterintuitive
• “float:right;” for “allow to be floated on the right side” would be better.
• “clear:left;” means: “clear the effect of any float:left setting for this and following elements”. It would have been better to name this “floating:right;” (to allow only to be a floating element on the right side) resp. “floating:none;” (the equivalent of “clear:both;”).

Also, it would be better to have the “clear:” attribute only apply to floating within the containing block, not to the whole document.

In a nutshell: printing to PDF

Be sure that your cups-pdf pseudo printer is set up correctly. No guarantees!

1. Choose to print with Java (“Paketmarken mit Java”).
2. Choose the printer “PDF” in the top left.
3. If you want, do a test print.
4. Click to print the postage (“Portodruck”).
5. Open and print the generated PDF file from ~/PDF/.

In a nutshell: printing to a physical printer

Be sure that your physical printer is set up correctly. No guarantees!

1. Choose to print with Java (“Paketmarken mit Java”).
2. Choose your physical prnter in the top left.
3. If you want, do a test print.
4. Click to print the postage (“Portodruck”).

In more detail

Basically, when createing postage labels for packages, the INTERNETMARKE website redirects you to https://internetmarke.deutschepost.de/internetmarke/print.do and offers two options how to print them:

1. Printing with Adobe Reader, after downloading a PDF.
2. A web-startable Java application.

Note that the “Print” (German: “Drucken”) link at the very bottom
right of the Java app’s window just sets prints the
window itself, not the PDF document for the package label. So it’s no option here.

In more detail: printing with Adobe Reader

First of all, you need an active Internet connection, and JavaScript enabled in Adobe Reader to use this solution.

With Adobe Reader, there is the problem that it’s impossible to choose the printer. When pressing “test print”, a print is issued on one of the system’s printers, but without showing a print dialog, a method to choose the printer, or giving a hint what way the target printer is determined. The target printer is neither the system’s standard printer (also restarting Adobe Reader does not help to make it accept a changed standard printer) nor the printer last used in the Adobe Reader print dialog.

So it might be possible to hit the correct printer for printing the postage label, but because you cannot choose a printer yourself, it seems to be impossible to redirect the print output to a file. Because, you neither get a “redirect to file” option in a print dialog, nor can you choose the cups-pdf pseudo printer.

In more details: printing with the Java application

Using the Java application requires an active Internet connection.

Clicking to do a test print (“Testdruck”) in the Java application opens a print dialog, lets you choose a printer (also a cups-pdf pseudo printer and a redirect to file option), and prints fine.

Clicking to do the real print (“Portodruck”) however does not open any print dialog. Instead, it prints to the printer that is currently selected in the Java application’s combo box. If that printer is not set up correctly, the label will be counted as printed, but not be actually outputted. In that case, it is not possible to print it again. The design idea behind this “feature” is probably to programmatically disable the “redirect to file” printing option, to reduce the risk of multiple copies being made.

In more detail: printing to PDF with the Java application

To be able to send package stamps via e-mail (for others to send a
package to you, for example), you need to be able to create a file from
the package stamp print. The working options are:

1. Print directly to a working file
   pseudo printer (cups-pdf).
2. Print to a physical printer, and then reprint the job to a working file pseudo printer. This has the advantage that it is secured against the case that the pseudo printer does not work.

If you want to use the first alternative, you need to make sure that your pseudo printer is set up correctly, at least once before doing the first package stamp print. If it is not set up correctly, it might fail printing, and even the CUPS “print again” feature might not work; your stamp is lost, then.

To check if it is set up correctly: In the Java application, do a test print (to
the cups-pdf printer, which is named “PDF”, and without “redirect to file”). Then see if a PDF
appears in ~/PDF/. Rename the test print, as the real print would
else overwrite it. Then you can do the real print, having selected the cups-pdf
printer in the select box of the Java app.

If you want to use the second alternative: You can also use the CUPS management interface at http://localhost:631/jobs/
for re-printing failed jobs. With that, you can only move active jobs
from one printer to another. So, restart the job (so that
it gets active again) and then move it. You can of course re-print several times until you hit a working pseudo printer setup.

In more detail: securing against failed package label prints

Start the tool system-config-printer, go to “Server -> Settings … -> Advanced …” and activate “Preserve job files (allow reprinting)”. This should make it possible to reprint the package stamps in case the print failed. You can then re-print the failed job by showing the printer queue in system-config-printer, enabling “View -> Show finished jobs”, right-clicking a job and select “print again”.

However, note that only printer jobs appear in this list where you did not select “redirect to file” in the printer dialog. So in case you want to repeat printing to file, you need a file pseudo-printer like cups-pdf, instead of a redirection.

The command is the same as when burning CDs with limited speed, just that you need to use DVD speed factors instead of CD speed factors. Not all factors work; you can see what will work in the line “Starting to write CD/DVD at speed   4.0 in dummy SAO mode for single session.” shown just before starting to burn in dummy mode.

With the Panasonic DVR-K05 burner for example, speeds 2 and 4 do work, and 4 is the maximum supported. If you specify an unsupported speed factor, it is corrected to its nearest lower working equivalent.
To specify your desired speed, use commands like:

• wodim speed=2 -v -dao /path/to/image.iso;
• wodim speed=4 -v -dao /path/to/image.iso;

If you do so, wodim will burn with that speed right from the start. But it might be that, when specifying speed=4, wodim will start buring with speed=2 and accelerate later, just as it does when not specifying any speed value.

The tool is called “”vehicleclient”, “dealertool” and “mobile.de Fahrzeugverwaltung”.

The install package you download is called “vehicleclient.exe”, size is 60 MB.
vehicleclient.exe fails to install via “wine vehicleclient.exe”, complaing that you need at least 600MB of space on your disk, while there is much more than this on both the home and root partition.

1. Therefore, install at Windows (probably in a VirtualBox virtual machine). Do not start the program after the installation – it does not hurt, but does not help either.
2. Then, copy all the files it installed into some c:\Program Files\ subdir to a directory on your Linux machine, say, /opt/MobileVehicleClient/.
3. Go into that directory and first start the program (necessary only once) with:
   HOMEDRIVE=/home/<username> java -jar dealertool-updater.jar
4. After 1-2 minutes, the program will hang and use all CPU load. Close it, it does not hurt anymore now.
5. Then, here is how to start the program regularly. Go into your installation directory and call:
   HOMEDRIVE=/home/<username> java -jar dealertool.jar
   This will (on KDE 4.3) even create a task bar icon.

The version of Java used was 1.6:

• Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
• Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)

1. If you want, create a folder for the JAR library in your plugin. You could also place the JAR files at the root of the plugin, but of you also have source attachments, this would clutter that directory quite a lot.
2. Right click on the target directory in Eclipse Package Explorer and select “Import …”, then “General > File System”. Do not select “General > Archive File”, as this would unpack the JAR file when importing. Then select your JAR file and import it.
3. Right click on the JAR file and select “Build Path > Add to Build Path”.
   Right click on the JAR file and select “Build Path > Configure Build Path …”, and there “Order and Export”. In that list, create a tick in the line for your JAR file. Without it, it is not contributed to dependent Java projects; this is a Java mechanis, we’ll have to deal with the Eclipse RCP mechanisms additionally now.
4. Open the build.properties file of the project that now contains the JAR file, with the Build Properties Editor of Eclipse. That is, double-click that file in the Eclipse Package Explorer. In the “Binary Build” section, create a tick for your JAR file, and in the “Source Build” section, create a tick for its source attachment, if any.
5. Now, the Eclipse-specific stuff. Or better, OSGi specific. Open the MANIFEST.MF file of the project that now contains the JAR file, with the Plug-in Manifest Editor of Eclipse. That is, double-click that file in the Eclipse Package Explorer. Here, in the “Classpath” section, click “Add” and add your JAR file. And in the “Runtime” section, click “Add” and add the packages exported by your class file. The latter step is not necessary in the rare case that your JAR file contributes classes to packages that are already exported (as happens with PrivilegedAccessor, contributing to the junit.extensions of JUnit).
6. Open the MANIFEST.MF file of the project that shall import the JAR file, with the Plug-in Manifest Editor of Eclipse. In the “Dependencies” tab, in “Required Plug-ins”, add the plug-in that holds the JAR.
7. Now you’re able to use classes from the JAR file in import statements.

On the Agfa snapscan e20:

• Time scanning an A4 page in 600dpi gray, without quality scan: 94s.
• Time scanning an A4 page in 600dpi gray, with quality scan: 94s.
• Also, it was impossible to eye-detect any differences in the scanned test image.

Perhaps a speed and quality difference is there if scanning with lower resolution than the maximum.

Scale the image to bigger size; the type of interpolation used (no, linear, cubic, Lanczos3) might affect the result, but the effects are not really heavy and yet to be determined more exactly.

Apply maximum contrast and adjust brightness to your needs
if diagonal borders now have many “stairs” of 1px height, this is what you want.

This procedure shows that a low-resolution grayscale image contains more information than a higher-resolution black-and-white image, as the latter can be constructed from the former. Therefore, master files for archiving documents should better use the grayscale images.

Calculation: one pixel with 256 shades contains the brightness information of a 16×16pixel array of black and white pixels (as each black one can be thought to make the array’s shade one step darker). If borders can be determined by interpolation well enough, a grayscale image contains the information of a black and white image with 16 times higher dpi resolution. Compared to this, it takes 8 bit per pixel, while the equivalent black and white image takes 256 bits for the same area (256 black and white pixel), so has 32 times higher file size.

The goal is here: the better the image is to the 300dpi image conversion of an imagined PDF file of the scanned book, the better. That is: white being kist every pixel white, the same with single-color areas, fonts should have anti-aliasing, no JPG compression of letters etc.. Whatever brings the file nearer to that goal goes into the “master files”, all other steps the lead to information loss relative to the above goal goes in additional files.

You don’t have to record how you’ve created the master files, and creating these can also include manual, file-specific steps. But it’s a good idea to have all work based on the master files (like scaling, JPG conversion, PDF creation) done by scripts. As this will be repeated with various settings, while the master files won’t be recreated. This interface definition also allows to re-create derived works after you’ve done some further fine-tuning to the master files. This procedure makes it possible to start with a quick&dirty solution (relatively rough master files), and incrementally add to this, as time permits.

1. Print and cut out two stripes of thick paper and tape them to the scanner, to use as horizontal and vertical end stops for designating the origin (0,0) on the scanner glas.
2. Define the scanner window to be the exact page size, or double page size for A5 books, which makes automated page extraction from the files possible.
   1. DIN A5 page at 600 dpi: 3507×4960px
   2. DIN A4 page or 2 DIN A5 pages at 600dpi: 4960×7015px, 210×297mm
3. Find the devicename: scanimage -L
4. scan:

   scanimage \
     --device-name=snapscan:libusb:001:012 \
     --format=tiff \
     --high-quality=yes \
     --resolution 600dpi \
     --mode Color \
     -t 0 -l 0 -x 210 -y 297 \
     --batch=%02d.tif --batch-prompt --batch-start 1

   (This command applied both to A4 and A5, for A5 we’ll partition the images lateron.)

5. Remove halftone rasters, by applying Gaussian blur, but only to the parts that actually consist of images, and saving the images as PNG (compression level 2).
6. Automatic page extraction from the files. This is necessary if you scanned two A5 pages at once on a A4 sheet. (However, the scanimage command could be changed for this, also).
   1. separating pages into files:

      for file in *.png ; do
        convert -crop 2480x1754+0+0 $file ${file/.png/.1.png};
        convert -crop 2480x1754+0+1754 $file ${file/.png/.2.png};
      done;

      Note that the GIMP preview and view for the PNG images created with the second command will be empty, but that’s a GIMP problem as kuickshow shows the images correctly.

   2. rotating the pages (90° right, if in landscape format):

      for file in *.png ; do
        mv $file ${file/.png/.orig.png};
        convert -rotate "90>" ${file/.png/.orig.png} $file;
      done;

7. adjust brightness and contrast for white and black to become white and black (this will reduce file size dramatically)
8. scale to 300dpi
9. save as PNGs with maximum compression level (9 in GIMP, -quality 105 for ImageMagick)
10. the above PNG files are the master files you archive (therefore we use lossless compression); you can now add further optimizations to copies of them, for specific presentation variants (PDF for scree or print usage, e.g.)
11. optimization for small file size, near-optimal printing and optimal screen reading
    1. in areas with text and few-color drawings, get the colors reduced by image processing, to reduce file size
    2. save as PNG with 16 or 32 colors (optimized palette) for pages where you have few colors (i.e. just the text and drawings, no photos)
    3. delete fuzzy borders:

       convert -page A4 -density 28x28 \
         -border 100x100 -bordercolor white page.*.sw.png buch.pdf

    4. for low-quality originals (e.g. inkjet printouts), screen readability is better when it’s greyscale instead of black and white, and to compensate for bigger file size, less resolution. Printability is, of course, better in black and white mode in higher resolution, but this can be constructed from the grayscale mode by scaling and applying a threshold. Therefore, the master images should be grayscale in these cases.
    5. PNG file size of grayscale scans can be reduced by 90% by applying higher contrast, so that letters become mostly black and paper mostly white. Contrast should be around 80-90 (of 128), so thet gray pixels still preserve the antialiasing information.
    6. PNG File size for 300dpi grayscale A4 text page scans (without images) is approx. 4.5 MiB before all optimizations, and 0.9 MiB after applying high contrast. This is acceptable for master files, and gives a very good basis for optimizing in various directions, as much information is contained.
    7. So the best settings to scan low-quality black and white originals are: 300dpi grayscale, no high-quality scanning. This is both time-efficient and includes all the information that is there to be captured.
12. conversion to PDF
    1. for file in *.png; do convert $file ${file/.png/.pdf}; done;
    2. pdftk page.*.pdf cat output book.pdf;