Fellow developers, I've got a client who needs to print some pocket labels for their books. Sadly, since some of these titles have some funky Unicode characters in the 245$abc, the PDF they generate comes out corrupted and unusable. This is a serious problem for their move forward with Koha. My research on in the list archives shows that this is well-known problem, and is in many ways out of our hands. PDFs don't handle Unicode as natively as we need, and the compromises to make it work are much less encouraging. It seems like this just isn't going to work unless Adobe decides to help. (see http://koha.1045719.n5.nabble.com/Diacriticals-Unicode-and-PDF-s-td3068755.h... more details) This got me thinking about a potential alternative. Perhaps we could offer a 4th Label Creator output option (in addition to PDF, CSV and XML), of HTML. Using similar markup that we use for print holds and overdues, it may be possible to recreate the page on the browser window in a format that anyone can read (and if they can't, their local machine can install the necessary fonts or language packs). There are numerous Print To PDF options for all kinds of browsers and platforms, so the end result could be the same, only without our code having to do the heavy PDF lifting. Does this sound like a feasible plan? Am I missing any subtleties that would make this untenable? Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
2011/1/9 Ian Walls <ian.walls@bywatersolutions.com> <snip>
This got me thinking about a potential alternative. Perhaps we could offer a 4th Label Creator output option (in addition to PDF, CSV and XML), of HTML. Using similar markup that we use for print holds and overdues, it may be possible to recreate the page on the browser window in a format that anyone can read (and if they can't, their local machine can install the necessary fonts or language packs). There are numerous Print To PDF options for all kinds of browsers and platforms, so the end result could be the same, only without our code having to do the heavy PDF lifting.
Does this sound like a feasible plan? Am I missing any subtleties that would make this untenable?
I have already done work on an "html" print option the formatting of which would be controlled by css. You can see my progress here: http://git.koha-community.org/gitweb/?p=wip/koha-chris_n.git;a=shortlog;h=re... The work was begun some months ago and is cold a the moment, so you will have to read through it to figure how it works. It is actually pretty far along. Be warned that in its current state it breaks the pdf printing capability. It is probably within less than 40 hours of completion. My premise for starting this work was exactly that you have mentioned: Browsers display unicode very well. From that point one can do whatever one likes with the output. Kind Regards, Chris
Fellow developers,
I've got a client who needs to print some pocket labels for their books. Sadly, since some of these titles have some funky Unicode characters in the 245$abc, the PDF they generate comes out corrupted and unusable. This is a serious problem for their move forward with Koha.
My research on in the list archives shows that this is well-known problem, and is in many ways out of our hands. PDFs don't handle Unicode as natively as we need, and the compromises to make it work are much less encouraging. It seems like this just isn't going to work unless Adobe decides to help. (see http://koha.1045719.n5.nabble.com/Diacriticals-Unicode-and-PDF-s-td3068755.h... for more details)
This got me thinking about a potential alternative. Perhaps we could offer a 4th Label Creator output option (in addition to PDF, CSV and XML), of HTML. Using similar markup that we use for print holds and overdues, it may be possible to recreate the page on the browser window in a format that anyone can read (and if they can't, their local machine can install the necessary fonts or language packs). There are numerous Print To PDF options for all kinds of browsers and platforms, so the end result could be the same, only without our code having to do the heavy PDF lifting.
Does this sound like a feasible plan? Am I missing any subtleties that would make this untenable? Hi Ian For what it is worth, we made some HTML to PDF work. you can see a result here http://test.koha.nimes.fr/relances_html/ It is based on pisa http://www.xhtml2pdf.com/doc/pisa-en.html and works
Le 09/01/2011 15:56, Ian Walls a écrit : pretty out of the box. It consists in a post process after gather_print_notices.pl. here is the script : http://git.biblibre.com/?p=koha;a=blob;f=misc/cronjobs/printoverdues.sh;h=f7... Hope that helps. -- Henri-Damien LAURENT BibLibre
On 09/01/11 14:56, Ian Walls wrote:
Fellow developers,
This got me thinking about a potential alternative. Perhaps we could offer a 4th Label Creator output option (in addition to PDF, CSV and XML), of HTML. Using similar markup that we use for print holds and overdues, it may be possible to recreate the page on the browser window in a format that anyone can read (and if they can't, their local machine can install the necessary fonts or language packs). There are numerous Print To PDF options for all kinds of browsers and platforms, so the end result could be the same, only without our code having to do the heavy PDF lifting.
I did this for a site to print orders, using Template::Toolkit to generate the document and firefox plugins to generate pdfs and print. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
participants (4)
-
Chris Nighswonger -
Colin Campbell -
Ian Walls -
LAURENT Henri-Damien