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.