[OPEN-ILS-GENERAL] Spine Label Printers?

[Joe Atzberger]

On Thu, Jan 21, 2010 at 1:46 PM, Jason Etheridge <jason at esilibrary.com>wrote:

> On Thu, Jan 21, 2010 at 1:29 PM, Joe Atzberger
> <jatzberger at esilibrary.com> wrote:
> > I'm not sure about your library's situation, but if they are going to
> print
> > in large volumes, you should also consider a laser printer.
>
> Printing to "sheet labels" is currently a weak area with Evergreen.
> Right now what you do is define a "form" in Windows and some
> character-based dimensions in the staff client, and the client will
> send a form feed after each label to advance to the next form.  If the
> printer can be made aware of the sheet's layout (i.e. 3 labels by 10
> labels) and handle the form feeds for us, then we're golden, but
> though I thought I saw an example of that once, I may have saw the HP
> Universal Printer driver instead with its print N number of pages per
> sheet feature, which would only be good for 16 labels or so.
>
> Of course, batch printing is more amenable to other processes, however
> cumbersome.  One site is using Evergreen to print to a PDF file, which
> they then upload to a web page which munges it into a layout suitable
> for sheet printing.  Similarly, the spine label preview can be
> copy/pasted into other applications, and it's even possible to match
> the format needed for OCLC's LabelMe program.
>
> You could also get at the data directly through reporting or API calls
> and use another application to do the printing.
>
> I'd love to hear how folks are handling this.  Would love even more to
> see resources put toward improving the situation. :)
>
> Joe, does Koha have any code that would be worth leveraging for this?
>

Not really.   For PDF's, the pitfall is Unicode.  There is no OSS perl
module encapsulation for producing well-formatted PDFs that include Unicode
characters.  The only suitable solution is embedding fonts, which makes the
documents produced huge, or having knowledge of the exact fonts on the
target user's system, or stripping the data.  This is a problem with PDF as
a medium, and not just any given system's implementation of it.

But what else besides PDF is a universal enough format for cross-platform
printing?

For Indian, Korean or Lithuanian Koha users, barcodes were best printed from
an Excel or OpenOffice spreadsheet using data imported from a CSV report.
 This is, incidentally, the same approach that was used when I was at
INFOhio w/ SirsiDynix Unicorn for a few million labels.

I really like the idea of pushing data to 3rd party printers, like Kinkos or
OCLC.  Maybe one of those companies would like to sponsor such a feature.
 It seems much more achievable to have a well-defined target with certain
tolerances than to target "any printer, any driver, any OS, only bare bones
fonts, any acrobat reader".

--Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20100121/861e5a6c/attachment-0001.htm