On Mon, Sep 28, 2009 at 11:50 PM, Joe Atzberger
<ohiocore@gmail.com> wrote:
The problem is not really with Koha, it is with the PDF format.
Very definitely so.
....
In my opinion, development time might be better spent on piping the data into an external known good UNICODE-capable print tool or something like Open Office.
I agree that this should be at least given some consideration. However, if we go that way, we would simply be "requiring" another piece of software for the end user rather than "requiring" fonts. (In the final analysis there will always be a minimum level of required packages in order to run Koha.)
Generating PDFs out of (FOSS) perl just didn't seem to be a viable answer.
Maybe.
I would be interested to see any counter-examples with FOSS perl producing compact, cross-platform PDFs with some UTF-8 data like Chinese, or Lithuanian... that don't require specific fonts.
The problem is a bit more fundamental than FOSS code. In order to properly display fonts in a PDF, there are only two options: either 1. embed the font in the PDF stream or 2. require the reader to have installed the correct fonts on their system.
If we have issues with requiring the installation of fonts, then we must take option 1 if we are going to produce our own PDFs. If we opt to pipe to another app, then we must require the installtion of those apps on the creator's system. And we are still bound by the above two options as they are fundamental to the PDF standard. The "another app" will have to either embed or require.
Actually, the "other app" wouldn't have to produce PDFs at all, since those are just a midpoint to printing actual barcode labels. For example, if we import CSV data into an Open Office spreadsheet, then it's just a question of page formatting and printing. This is the approach we used at INFOhio (using a custom SirsiDynix Unicorn report and an Excel spreadsheet with some VB I wrote). It was not particularly elegant, but it was good enough to print a couple million barcodes.
Another approach would be to integrate with some widely available 3rd party print shop, like Kinko's. I.E., figuring out what API was available for specifying (or pre-specifying) label stock and layout, and then just pushing CSV data. We wouldn't necessarily need a PDF to just mail-order the barcodes printed commercially. (A similar approach might be expanded to cover printing of patron ID cards.)
But otherwise, yes, you are right, punting to another application for PDF-generation doesn't resolve the problems all PDFs would have on the client side.
--Joe