[Koha-bugs] [Bug 2246] Label printing doesn't work with Unicode characters

bugzilla-daemon at pippin.metavore.com bugzilla-daemon at pippin.metavore.com
Tue Dec 2 00:05:56 CET 2008


http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2246


joe.atzberger at liblime.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Label printing doesn't work |Label printing doesn't work
                   |with Hindi characters       |with Unicode characters




------- Comment #9 from joe.atzberger at liblime.com  2008-12-01 15:05 -------
I disagree with Mason's assessment.  PDF generation fails when I have added
even one title with one (combining) diacritical character like: "The séance". 
The error in the log is: 

label-print-pdf.pl: Wide character in syswrite at
/usr/local/share/perl/5.8.8/PDF/Reuse.pm line 968, <DATA> line 228., 
referer:
http://staff-atz.dev.kohalibrary.com/cgi-bin/koha/labels/label-manager.pl?op=add&batch_id=5&itemnumber=733

As far as I can tell, LATIN SMALL LETTER E WITH ACUTE should be available in
any decent font.  The more descriptive post from the patch author on Unicode in
PDF::Reuse is here:

http://groups.google.com/group/PDF-Reuse/browse_thread/thread/4e28d69fedf74b74

He summarizes: "It seems that the only way to access characters outside the
MacRoman/WinAnsi encodings supported by PDF's built-in fonts is to embed
a TrueType font.  (I'm happy to be corrected if this conclusion in
wrong).  I've implemented font embedding by grafting Font::TTF and
Text::PDF::TTFont0 onto the PDF::Reuse API."

I'm not sure that is a correct conclusion on his part (perhaps CMAP or a
/name_object would work).  The conditions for making PDF::Reuse work even under
this new version would be:
(1) require PDF::Reuse 0.35,
(2) Add two dependencies to Koha,
(3) Require ANY font being targeted to be installed on the server,
(4) Build an admin interface for selecting target fonts to be embedded, so
label scripts can reference them by filepath, 
(5) Add data structure to remember which batches need which fonts, and
(6) Refactor code to use prTTFFont.

In the end, the TTFont would be embedded in each PDF generated, meaning a set
of barcodes might increase in filesize by several orders of magnitude.  

In my opinion, PDF::Reuse has a rather severe Unicode workaround, it does not
have compatibility.  Maybe that's Adobe's fault and not the module's, but right
now I'm not sure this path is the right one.




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.



More information about the Koha-bugs mailing list