> On Mon, Sep 28, 2009 at 11:50 PM, Joe Atzberger <ohioc...@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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
