Bug 38516

Summary: Closed group basket not able to open pdf file with adobe The root object is missing or invalid
Product: Koha Reporter: Hugo Agud <hagud>
Component: AcquisitionsAssignee: David Cook <dcook>
Status: Passed QA --- QA Contact: Marcel de Rooy <m.de.rooy>
Severity: normal    
Priority: P5 - low CC: arthur.suzuki, dcook, kugler_stefan, m.de.rooy, mathsabypro
Version: unspecified   
Hardware: All   
OS: All   
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: Trivial patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:
Attachments: borken pdf
perl packages from ubuntu 22.04
plack-intranet.log after downloading a pdf
Bug 38516: Use PDF template copy for exporting PDFs
Bug 38516: Use PDF template copy for exporting PDFs
Bug 38516: Use PDF template copy for exporting PDFs
Bug 38516: Use PDF template copy for exporting PDFs
Bug 38516: Use PDF template copy for exporting PDFs

Description Hugo Agud 2024-11-22 11:26:15 UTC
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
Comment 1 David Cook 2024-11-24 22:36:56 UTC
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.
Comment 2 Hugo Agud 2024-11-29 07:15:12 UTC
I am thinking about what is different between you and me, and spanish characteres, and locale of servers, let me check twice
Comment 3 David Cook 2024-12-01 22:29:15 UTC
(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!)
Comment 4 Hugo Agud 2024-12-09 09:12:50 UTC
Created attachment 175288 [details]
perl packages from ubuntu 22.04
Comment 5 Hugo Agud 2024-12-09 09:38:29 UTC
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
Comment 6 Hugo Agud 2024-12-20 11:59:15 UTC
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
Comment 7 David Cook 2024-12-22 23:05:06 UTC
(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?
Comment 8 Hugo Agud 2024-12-23 06:34:55 UTC
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
Comment 9 David Cook 2024-12-24 00:19:30 UTC
(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?
Comment 10 Hugo Agud 2024-12-24 06:12:30 UTC
i am using debĂ­an packsges, i just downgraded those three packages, as Inthough it was the source of the issue
Comment 11 Stefan Kugler 2025-10-20 13:03:11 UTC
Created attachment 188163 [details]
plack-intranet.log after downloading a pdf
Comment 12 Stefan Kugler 2025-10-20 13:03:39 UTC
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.
Comment 13 Mathieu Saby 2025-10-23 10:53:18 UTC
For the record we experience the same issue with Koha 24.11.02
Comment 14 Arthur Suzuki 2025-10-29 15:21:08 UTC
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.
Comment 15 Arthur Suzuki 2025-10-29 15:23:23 UTC
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.
Comment 16 David Cook 2025-10-30 00:43:37 UTC
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.
Comment 17 David Cook 2025-10-30 00:49:53 UTC
(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.
Comment 18 David Cook 2025-10-30 01:10:37 UTC
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...
Comment 19 David Cook 2025-10-30 01:14:36 UTC
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;
Comment 20 David Cook 2025-10-30 01:34:47 UTC
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.
Comment 21 David Cook 2025-10-30 01:42:11 UTC
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!
Comment 22 David Cook 2025-10-30 01:43:40 UTC
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.
Comment 23 David Cook 2025-10-30 01:54:15 UTC
(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...
Comment 24 David Cook 2025-10-30 05:55:39 UTC
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.
Comment 25 Arthur Suzuki 2025-10-30 08:02:41 UTC
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>
Comment 26 Arthur Suzuki 2025-10-30 08:05:07 UTC
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
Comment 27 David Cook 2025-10-30 23:10:28 UTC
(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.
Comment 28 David Cook 2025-10-31 03:37:08 UTC
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!
Comment 29 David Cook 2025-10-31 03:37:41 UTC
Thanks for testing before, Arthur. Can you have another go with the expanded test plan?
Comment 30 Arthur Suzuki 2025-11-03 13:51:53 UTC
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>
Comment 31 Arthur Suzuki 2025-11-03 13:56:35 UTC
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
Comment 32 Marcel de Rooy 2025-11-28 07:42:57 UTC
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>