I tried reproducing using the test plan with the "main" and 23.11 branches, but it works fine for me. I do see the error when using the attached broken PDF though. -- I'm not super familiar with PDF markup, but looking at the broken and working files using notepad... the first 370 lines leading up to the first %%EOF are identical... and then the rest varies, which is probably related to the differing contents. Looking at the broken file, I can see that it doesn't actually follow the test plan given in the "Description". -- Without a way to reproduce, we can't really take this one any further. I am thinking about what is different between you and me, and spanish characteres, and locale of servers, let me check twice (In reply to Hugo Agud from comment #2) > I am thinking about what is different between you and me, and spanish > characteres, and locale of servers, let me check twice I'd suggest trying to reproduce it using koha-testing-docker. (I thought that I'd suggested that before on here, but it looks like I forgot to!) Created attachment 175288 [details]
perl packages from ubuntu 22.04
These are the packages comparisson PDF::API2 2.033 cs 2.044 PDF::Table (v0.9.3 ) 0.10.1 vs 1.003 Text::PDF (0.29 ) vs 2.02 Good morning, I have done a downgrade of the packages PDF::API2 2.033 cs 2.044 PDF::Table (v0.9.3 ) 0.10.1 vs 1.003 Text::PDF (0.29 ) vs 2.02 and now closed basket works fine (In reply to Hugo Agud from comment #5) > These are the packages comparisson > > PDF::API2 2.033 cs 2.044 > PDF::Table (v0.9.3 ) 0.10.1 vs 1.003 > Text::PDF (0.29 ) vs 2.02 (In reply to Hugo Agud from comment #6) > Good morning, I have done a downgrade of the packages > > PDF::API2 2.033 cs 2.044 > PDF::Table (v0.9.3 ) 0.10.1 vs 1.003 > Text::PDF (0.29 ) vs 2.02 > > and now closed basket works fine These numbers don't seem to correspond to your image or to Ubuntu 22.04? AS I have tested on D12 and ubuntu2204 perhapts thar figures belongs to D12, however downgrade ubuntu 22.04 and D12 to those version numbers, the issue has gone (In reply to Hugo Agud from comment #8) > AS I have tested on D12 and ubuntu2204 perhapts thar figures belongs to D12, > however downgrade ubuntu 22.04 and D12 to those version numbers, the issue > has gone Ok, but that suggests then that there is a potential problem for other people in the future. Unless you're not using Debian packages and you're using all your modules from CPAN? i am using debĂan packsges, i just downgraded those three packages, as Inthough it was the source of the issue Created attachment 188163 [details]
plack-intranet.log after downloading a pdf
Comment on attachment 188163 [details]
plack-intranet.log after downloading a pdf
Same here, I can open a pdf with Chrome/FF, but not using Adobe Reader.
System:
Description: Ubuntu 24.04.3 LTS
Koha:
Koha-Version: 25.05.04.000
PDF::API2 (2 ) 2.045
PDF::FromHTML (0.31 ) 0.33
PDF::Reuse (0.36 ) 0.39
PDF::Reuse::Barcode (0.05 ) 0.07
PDF::Table (v0.9.3 ) 1.005
Text::PDF (0.29 ) 0.31
There are some warnings in plack-intranet.log, see attachment.
For the record we experience the same issue with Koha 24.11.02 Hello, I think we've found what is the actual reason of this bug : https://github.com/ssimms/pdfapi2/issues/86 Koha uses PDF files located in the sources at this location: koha-tmpl/intranet-tmpl/prog/pdf/*.pdf It uses these files as templates to generate PDFs, and the fact that the templates are not writable in the first place creates the problem. Also depending on your installation it may work or not, by default I couldn't reproduce the issue on KTD because the user and group are both "koha". On some other installation user is "koha" and group would be something else, without any write permissions on the files. If that's the case, you can try giving the write permissions to the group, it may solves your issue. Test plan in KTD : - change the owner of the pdf files in koha-tmpl/intranet-tmpl/prog/pdf/ to "root" - try to open the pdf generated by a basket group in acrobat reader - there should be an error - change the owner back to "koha" - make a new pdf - no problem I will try to propose a patch to change the mode of these files and make them writable by the group to fit all kind of installations. so, in the end, it's not due to Perl modules version. maybe solved in a future version of Perl::API2 (2.048), didn't try. we should consider updating this lib. So... let's see... ls -lh /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/pdf/*.pdf -rw-r--r-- 1 kohadev-koha kohadev-koha 9.1K Oct 29 04:43 koha-tmpl/intranet-tmpl/prog/pdf/layout1page.pdf -rw-r--r-- 1 kohadev-koha kohadev-koha 24K Jun 28 2024 koha-tmpl/intranet-tmpl/prog/pdf/layout2pagesde.pdf -rw-r--r-- 1 kohadev-koha kohadev-koha 25K Jun 28 2024 koha-tmpl/intranet-tmpl/prog/pdf/layout2pages.pdf -rw-r--r-- 1 kohadev-koha kohadev-koha 24K Jun 28 2024 koha-tmpl/intranet-tmpl/prog/pdf/layout3pagesfr.pdf -rw-r--r-- 1 kohadev-koha kohadev-koha 27K Jun 28 2024 koha-tmpl/intranet-tmpl/prog/pdf/layout3pages.pdf ls -lh /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pdf/*.pdf -rw-r--r-- 1 root root 9.1K Aug 2 00:05 /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pdf/layout1page.pdf -rw-r--r-- 1 root root 24K Aug 2 00:05 /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pdf/layout2pagesde.pdf -rw-r--r-- 1 root root 25K Aug 2 00:05 /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pdf/layout2pages.pdf -rw-r--r-- 1 root root 24K Aug 2 00:05 /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pdf/layout3pagesfr.pdf -rw-r--r-- 1 root root 27K Aug 2 00:05 /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pdf/layout3pages.pdf In KTD, I'm able to "Export as PDF" from /cgi-bin/koha/acqui/basketgroup.pl?booksellerid=1&closed=1 and I can open in Adobe Acrobat on Windows. In a production Koha, I'm able to "Export as PDF" from /cgi-bin/koha/acqui/basketgroup.pl?booksellerid=2&closed=1 BUT I get the error "There was an error opening this document. The root object is missing or invalid." when I try to open in Adobe Acrobat on Windows. -- Thanks for checking, people. In hindsight, it looks like I just tried KTD and didn't try a real deployed Koha. (In reply to Arthur Suzuki from comment #14) > I will try to propose a patch to change the mode of these files and make > them writable by the group to fit all kind of installations. I don't think that would be a good idea. We don't want the web server having write access to these source files. As the kohadev-koha user, I just tried the following code: #!/usr/bin/perl use Modern::Perl; use PDF::API2; my $pdf_template = '/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pdf/layout2pagesde.pdf'; my $pdf = PDF::API2->open($pdf_template); print $pdf->stringify; It creates a PDF which I can open in Adobe Acrobat and /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pdf/layout2pagesde.pdf has the following permissions and ownership: -rw-r--r-- 1 root root 24K Aug 2 00:05 /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pdf/layout2pagesde.pdf -- This implies that it's something we do between ->open and ->stringify which is causing a problem... Ok here's a minimal example which reproduces the problem. It appears that the call $pdf->openpage($_) alone is enough to corrupt the output:
use Modern::Perl;
use PDF::API2;
use constant mm => 25.4 / 72;
my $pdf_template = '/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/pdf/layout2pagesde.pdf';
my $pdf = PDF::API2->open($pdf_template);
#printfooters($pdf);
for ( 1 .. $pdf->pages ) {
my $page = $pdf->openpage($_);
}
print $pdf->stringify;
In my mind, the way to get around this issue is to open the template, take a copy, and work off the copy. I'm going to attach a little proof-of-concept that works for the KTD OrderPdfFormat default of "English 3-page". I'm happy for someone else to then copy that change to the other ".pm" files for the other formats. Created attachment 188618 [details] [review] Bug 38516: Use PDF template copy for exporting PDFs Due to a bug in PDF::API2 or related libraries, you cannot export a PDF if you do not have write permission on the PDF template. We bypass this problem by taking a string copy of the PDF template and working on that instead. Test plan: 0. DO NOT APPLY THE PATCH YET 1. chmod 444 /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/pdf/*.pdf 2. Create a basket with a vendor 3. Add an order to the basket 4. Close basket (and attach the basket to a new basket group with the same name) 5. Go to "Closed" tab and click "Export as PDF" 6. Note that you get an error when you try to open it in Adobe or some other PDF program 7. Apply the patch and restart koha (e.g. koha-plack --restart kohadev) 8. Try to "Export as PDF" again 9. Note that this time there is no warning and your PDF opens just fine 10. Celebrate! Please test this out and let me know what you think. We still need to update these files in Koha/pdfformat: layout1page.pm layout2pagesde.pm layout2pages.pm layout3pagesfr.pm More than happy for someone else to do that, as I've got lots of other things to do, and hopefully it should be clear from my patch what needs to be done. (In reply to Arthur Suzuki from comment #15) > so, in the end, it's not due to Perl modules version. > maybe solved in a future version of Perl::API2 (2.048), didn't try. > we should consider updating this lib. I don't see any real difference in the change logs or the source code, so I doubt this would make a difference, but it was a good thought. It could still be true that it fixes something. It's not clear what exactly fails due to that write permission issue... An alternative to my patch here would be to read the string in using File::Slurp (or something like it) and use "from_string()" from there. Created attachment 188620 [details] [review] Bug 38516: Use PDF template copy for exporting PDFs Due to a bug in PDF::API2 or related libraries, you cannot export a PDF if you do not have write permission on the PDF template. We bypass this problem by taking a string copy of the PDF template and working on that instead. Test plan: 0. DO NOT APPLY THE PATCH YET 1. chmod 444 /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/pdf/*.pdf 2. Create a basket with a vendor 3. Add an order to the basket 4. Close basket (and attach the basket to a new basket group with the same name) 5. Go to "Closed" tab and click "Export as PDF" 6. Note that you get an error when you try to open it in Adobe or some other PDF program 7. Apply the patch and restart koha (e.g. koha-plack --restart kohadev) 8. Try to "Export as PDF" again 9. Note that this time there is no warning and your PDF opens just fine 10. Celebrate! Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com> Hello David, Just tried it on my KTD, everything is now working as it should even without the write permission on the layout files. Signing off your patch then, thanks! Best, Arthur (In reply to Arthur Suzuki from comment #26) > Hello David, > Just tried it on my KTD, everything is now working as it should even without > the write permission on the layout files. > Signing off your patch then, thanks! > Best, > Arthur Thanks, Arthur. I appreciate that, but it's not a complete fix yet, so not quite ready for Sign Off. The same fix needs to be applied to the other files for the other PDF formats: - layout1page.pm - layout2pagesde.pm - layout2pages.pm - layout3pagesfr.pm I was hoping you might actually copy the fix over to those files ;). But I can probably make time to do it today. Created attachment 188732 [details] [review] Bug 38516: Use PDF template copy for exporting PDFs Due to a bug in PDF::API2 or related libraries, you cannot export a PDF if you do not have write permission on the PDF template. We bypass this problem by taking a string copy of the PDF template and working on that instead. Test plan: 0. DO NOT APPLY THE PATCH YET 1. chmod 444 /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/pdf/*.pdf 2. Create a basket with a vendor 3. Add an order to the basket 4. Close basket (and attach the basket to a new basket group with the same name) 5. Go to "Closed" tab and click "Export as PDF" 6. Note that you get an error when you try to open it in Adobe or some other PDF program 7. Apply the patch and restart koha (e.g. koha-plack --restart kohadev) 8. Try to "Export as PDF" again 9. Note that this time there is no warning and your PDF opens just fine 10. Repeat the "Export as PDF" process for every option of the system preference "OrderPdfFormat". Every option should work without errors. 11. Celebrate! Thanks for testing before, Arthur. Can you have another go with the expanded test plan? Created attachment 188930 [details] [review] Bug 38516: Use PDF template copy for exporting PDFs Due to a bug in PDF::API2 or related libraries, you cannot export a PDF if you do not have write permission on the PDF template. We bypass this problem by taking a string copy of the PDF template and working on that instead. Test plan: 0. DO NOT APPLY THE PATCH YET 1. chmod 444 /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/pdf/*.pdf 2. Create a basket with a vendor 3. Add an order to the basket 4. Close basket (and attach the basket to a new basket group with the same name) 5. Go to "Closed" tab and click "Export as PDF" 6. Note that you get an error when you try to open it in Adobe or some other PDF program 7. Apply the patch and restart koha (e.g. koha-plack --restart kohadev) 8. Try to "Export as PDF" again 9. Note that this time there is no warning and your PDF opens just fine 10. Repeat the "Export as PDF" process for every option of the system preference "OrderPdfFormat". Every option should work without errors. 11. Celebrate! Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com> Hi David, sorry for missing the note about doing the same thing on all templates. I've read your messages a bit too quickly and went straight to testing, didn't see it had to be done on all templates... sry for that... Nevertheless, I've tried again with all possible values for "OrderPdfFormat" and permissions = 444, everything seems to work fine with Adobe Acrobat installed in wine! Couldn't try on a windows machine but since that works on wine it should work as well on Windows. Thanks a lot! Arthur Created attachment 190005 [details] [review] Bug 38516: Use PDF template copy for exporting PDFs Due to a bug in PDF::API2 or related libraries, you cannot export a PDF if you do not have write permission on the PDF template. We bypass this problem by taking a string copy of the PDF template and working on that instead. Test plan: 0. DO NOT APPLY THE PATCH YET 1. chmod 444 /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/pdf/*.pdf 2. Create a basket with a vendor 3. Add an order to the basket 4. Close basket (and attach the basket to a new basket group with the same name) 5. Go to "Closed" tab and click "Export as PDF" 6. Note that you get an error when you try to open it in Adobe or some other PDF program 7. Apply the patch and restart koha (e.g. koha-plack --restart kohadev) 8. Try to "Export as PDF" again 9. Note that this time there is no warning and your PDF opens just fine 10. Repeat the "Export as PDF" process for every option of the system preference "OrderPdfFormat". Every option should work without errors. 11. Celebrate! Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> |
Created attachment 174925 [details] borken pdf We have realizaed from Koha 23.11 and 24.05 adobe is not able to open the pdf, it can be opened via broswer visor, or other pdf reader, but not with Adobe It has been tested wit debian and ubuntu (both SO) I get the error The root object is missing or invalid Test plan 1. Go to acquisition 2. Go to a vender with closed group basket 3. Try to export pdf file 4. Download locally 5. Open with Adobe