https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #2 from Manos PETRIDIS <egpetridis@yahoo.com> --- Created attachment 132204 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132204&action=edit CSV output -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #4 from Manos PETRIDIS <egpetridis@yahoo.com> --- Further testing has shown that * when trying to print in a Layout of Print type BAR, a PDF is created. It doesn't contain the full batch, but at least id does contain a barcode. * when trying however to print in Layouts of Print type either ALT or BARBIB, that is when trying to include in the labels something more than just the barcode, the same batch creates a zero-sized PDF file. Any ideas? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 Dietrich <dietrich@teilgedanken.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dietrich@teilgedanken.de --- Comment #6 from Dietrich <dietrich@teilgedanken.de> --- I have the same problem... What would be the next step to debug this further? I did not find any error in the logs... but where would I look for errors? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #7 from Dietrich <dietrich@teilgedanken.de> --- Note: For me this is the case for single and multiple lables so the bug #29994 is different -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #9 from Chris Nighswonger <cnighswonger@foundations.edu> --- (In reply to Dietrich from comment #7)

Note: For me this is the case for single and multiple lables so the bug #29994 is different

There have been many bug reports for labels/cards of late. I suspect a common regression may be behind them. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- I raised the importance since this seems to be an increasingly large problem. Since it doesn't affect my prod systems, I'm not going to fix this urgently. But when it does start to affect my prod systems, then I'll likely look into it urgently. I'm curious if/when it'll affect other vendors... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #13 from David Cook <dcook@prosentient.com.au> --- (In reply to Chris Nighswonger from comment #12)

Furthermore, I am suspecting corrupted underlying data at least in some cases. The may explain why your instance does not reproduce the bug.

I'm going to keep poking around at it.

Much appreciate you looking into it! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #15 from Chris Nighswonger <cnighswonger@foundations.edu> --- (In reply to Dietrich from comment #14)

I'd try to help/fix this - however I know neither pearl nor php (though I know quite some other programming languages). How would I debug the issue... it is always easier to debug if there is some kind of error. But I can't find any. But maybe I'm just looking at the wrong places. If you could help me getting started that would be great.

Please post a PDF from your BAR type batch. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #17 from Manos PETRIDIS <egpetridis@yahoo.com> --- Created attachment 138522 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=138522&action=edit barcode-only PDF export (roll size) Note that only 3 of 9 selected items appear on print. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #19 from Manos PETRIDIS <egpetridis@yahoo.com> --- Allow me to refer you Chris to my message of May 1st: Further testing has shown that * when trying to print in a Layout of Print type BAR, a PDF is created. It doesn't contain the full batch, but at least id does contain a barcode. * when trying however to print in Layouts of Print type either ALT or BARBIB, that is when trying to include in the labels something more than just the barcode, the same batch creates a zero-sized PDF file. I can't upload a zero-sized example, as bugzilla will not accept such files, but the resultant in the latter case files are empty and a reported by the OS as having a size of 0. You are correct in stating that there are two issues here: a. Empty PDF files when printing ALT or BARBIB labels. b. Not all BAR labels are printed in the roll format output. This I only realised today, while prepering the latest examples. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #21 from Chris Nighswonger <cnighswonger@foundations.edu> --- Some random thoughts in no particular order: ALT is a combination of BIB and BAR. We would expect to see at least the BAR labels in an ALT PDF, but we do not. So what is wrong? Maybe bad data. We also do not have any errors/warnings in the log per an earlier post. This seems odd as well and may point to bad data. I notice that the CSV and XML do not play well with the Greek. I use Greek fonts extensively in my work. Notepad++ displays the Greek in both files fine. Vim does not. LibreCalc does not. Perhaps there is an underlying encoding issue here as well. It may or may not be a cause of the topic issue of this bug. The fact that we have only two systems affected seems to point to an underlying data problem as well. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #23 from Manos PETRIDIS <egpetridis@yahoo.com> --- Created attachment 138590 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=138590&action=edit Spine label PDF, showing greek characters correctly. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #25 from Manos PETRIDIS <egpetridis@yahoo.com> --- Created attachment 138592 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=138592&action=edit Search results exported as CSV, displaying greek characters correctly. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal --- Comment #27 from David Cook <dcook@prosentient.com.au> --- (In reply to Chris Nighswonger from comment #21)

The fact that we have only two systems affected seems to point to an underlying data problem as well.

I'm downgrading the severity as there have only been 2 reports over the last 1.5 years. I think that this might be classed as a support issue rather than a bug per se. Since we can't reproduce the problem, you might need to pay someone to go onto your system, and troubleshoot it locally. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #29 from David Cook <dcook@prosentient.com.au> --- (In reply to Manos PETRIDIS from comment #28)

Does the labels module keep an error log so that one may know what happens and try and debug the black box?

It isn't a black box. The only error log there is would be the web server error log. You're probably going to need to get a support vendor to help you out with your particular database with this one since you haven't been able to give us a way to reproduce this on other systems. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 José Anjos <joseanjos@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joseanjos@gmail.com --- Comment #31 from José Anjos <joseanjos@gmail.com> --- If, for some reason, the Homebranch is NULL, the exported PDF will be 0Kb I had that problem -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #32 from Chris Nighswonger <chris.nighswonger@veritassuperaitsolutions.com> --- Some empirical results from re-testing this on current main in koha-testing-docker, exercising the same code path label-create-pdf.pl uses (Compress -> Mbox -> create_label -> per-line Font/FontSize/Text -> End): 1) Greek data renders fine on current main: a BIBBAR label with a Greek 245\$a produces a ~22KB PDF with the configured TTF embedded, on both PDF::Reuse 0.39 and 0.43. So neither the non-latin data nor the PDF::Reuse version explains this by itself. 2) Comment 31 reproduces, with a concrete mechanism. _get_label_item() (C4/Labels/Label.pm:91) selects with an INNER join on i.homebranch=br.branchcode. An item whose homebranch is NULL returns no row at all, so every bib field downstream is empty and the text lines are silently skipped -- my test BIBBAR export collapsed to exactly the barcode-only output, with no warning anywhere. The same applies to any item that fails the other join conditions (orphaned biblioitem links etc.) -- i.e. precisely the "corrupted underlying data" theory from comment 12, now with a mechanism. 3) The zero-byte part has a structural amplifier: label-create-pdf.pl prints the CGI attachment header (line 55) before any PDF work. Anything that dies between the header and \$pdf->End() streams a zero-byte download to the browser while the actual error lands only in the plack log. On current main my NULL-homebranch test degrades silently rather than dying, but on older versions (this report spans 21.11-22.11) the same missing-row data hitting version-specific code (e.g. Koha::Biblios->find(undef) behavior) could die and produce exactly the 0-byte file reported here. Suggested path: change the join in _get_label_item() to a LEFT JOIN on branches (with a warn when bib data is missing), which would make labels for such items render instead of silently losing text. I can work up a patch along those lines once my current in-flight label/patroncard bugs clear the queue, if that seems sensible. (Tested with AI assistance in koha-testing-docker.) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 --- Comment #34 from Chris Nighswonger <chris.nighswonger@veritassuperaitsolutions.com> --- Created attachment 202626 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202626&action=edit Bug 28806: Fix silent label content loss for items with NULL homebranch _get_label_item() selected item, biblioitem, biblio, and branch data with implicit INNER joins, including i.homebranch = br.branchcode. An item whose homebranch is NULL (or references a deleted branch) returns no row at all, so every downstream field is empty and draw_label_text() silently skips all text lines: a BIBBAR/BIB/ALT label collapses to barcode-only output with nothing in the logs. Where version-specific code then dies on missing data, label-create-pdf.pl has already printed the CGI attachment header, so the browser receives the zero-byte PDF reported here and in several related bug reports. Convert the branches join to a LEFT JOIN, using explicit JOIN syntax for the other tables, and log a warning (rather than proceed on an empty hashref) when no row is found at all. Verified in koha-testing-docker against the label-create-pdf.pl code path: before, a BIBBAR export for a NULL-homebranch item produced barcode-only output (1343 bytes); after, the full label renders (22570 bytes, text + barcode). Output for items with valid homebranch is byte-identical before and after. Behavior is independent of PDF::Reuse version (tested 0.39 and 0.43). Test plan: 1) Create an item and NULL its homebranch: UPDATE items SET homebranch = NULL WHERE itemnumber = <n>; 2) Add the item to a label batch with a BIBBAR layout and export PDF -- without this patch the label contains only the barcode -- with this patch title/author/etc. render as expected 3) Export a batch of normal items before and after -- output is unchanged 4) prove t/db_dependent/Labels/ t/db_dependent/Patroncards/ t/Creators.t -- all tests pass AI Assistance: Claude Fable 5 (Anthropic) identified the mechanism while re-testing this bug's reports in koha-testing-docker (reproduced the NULL-homebranch data loss and the zero-byte failure mode), implemented the fix, and verified before/after behavior. Human author directed the investigation, confirmed the data-corruption theory from the bug discussion, and reviewed the change. Assisted-by: Claude Fable 5 (Anthropic) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 Chris Nighswonger <chris.nighswonger@veritassuperaitsolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.