[Bug 2246] Label printing doesn't work with Unicode characters
http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2246 joe.atzberger@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@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/4e28d69fedf74b... 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.
On 2008/12/2, at 12:05 PM, bugzilla-daemon@pippin.metavore.com wrote:
http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2246
joe.atzberger@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@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
heya, yeah i just hit the same error myself, weird huh.... Labels.pm: ### fontsize, label-print-pdf.pl: Wide character in syswrite at /usr/local/share/ perl/5.8.8 /PDF/Reuse.pm line 977., in a batch set seemingly without any unusual characters
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.
embedding a TTF fontset in every PDF isnt very pretty - but if it works its better than nothing..
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.
Yep, i agree , but I cant see what the better alternative is at this stage either - a rewrite using PDF::API perhaps ?? the PDF spec seems to be quite TTF centric and doesnt really seem to 'do' unicode so well? like i said, its going to take some proof-of-concept testing to even get an 'é' displaying it looks like ;/ Mason.
participants (2)
-
bugzilla-daemon@pippin.metavore.com -
Mason James