In my first tries to create biblio labels, I see that export to PDF creates zero sized PDF files, in both individual/single and batch modes. Coult it be due to non-latin characters (Greek) appearing in the label contents? Export to CSV does produce files with the expected number of rows, albeit with non-usable characters.
Created attachment 132203 [details] XML output
Created attachment 132204 [details] CSV output
Unfortunately I can't uplode the zero-sized PDF as bugzilla objects "The file you are trying to attach is empty, does not exist, or you don't have permission to read it".
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?
(In reply to Manos PETRIDIS from comment #0) > In my first tries to create biblio labels, I see that export to PDF creates > zero sized PDF files, in both individual/single and batch modes. > > Coult it be due to non-latin characters (Greek) appearing in the label > contents? I don't think so. If the font can't print the Greek characters, it should just not print them, but it should still generate a PDF. (I was working out some issues with Chinese characters not printing recently.)
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?
Note: For me this is the case for single and multiple lables so the bug #29994 is different
(In reply to Manos PETRIDIS from comment #4) > 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? Please post a PDF from your BAR type batch.
(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.
(In reply to Chris Nighswonger from comment #9) > There have been many bug reports for labels/cards of late. I suspect a > common regression may be behind them. Agreed although since no one touches the label creator it makes you wonder what it could be... I notice the version says "21.11" but this bug report was raised before 21.11 was actually released... I run a modified 21.11.03 and I don't have label problems...
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...
(In reply to David Cook from comment #10) > (In reply to Chris Nighswonger from comment #9) > > There have been many bug reports for labels/cards of late. I suspect a > > common regression may be behind them. > > Agreed although since no one touches the label creator it makes you wonder > what it could be... > 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.
(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!
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.
(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.
Created attachment 138521 [details] barcode-only PDF export (A4 size) Note that all 9 selected items appear on print.
Created attachment 138522 [details] barcode-only PDF export (roll size) Note that only 3 of 9 selected items appear on print.
(In reply to Manos PETRIDIS from comment #17) > Created attachment 138522 [details] > barcode-only PDF export (roll size) > > Note that only 3 of 9 selected items appear on print. I note that these three labels are the three left-to-right, top-to-bottom diagonal labels in the A4 size PDF. ie. Labels 1, 5, 9 of the A4 appear in the roll size PDF. Yet neither are zero sized PDFs. So there may be two different issues here.
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.
If you can, re-create both of those PDFs with the following line commented out. https://github.com/Koha-Community/Koha/blob/master/labels/label-create-pdf.pl#L102 You can uncomment it afterwards. That line instructs the distiller to compress the resulting PDF. A compressed PDF is not really useful for debugging.
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.
If "bad data" is the only issue, why does the problem manifest itself only in batch label creation? Spine labels are created just fine (attachment 20220804_Spine labels_Tools_Koha.pdf). Apparently batch label creation has different rules in defining what "bad data" is. Furthermore, search (as in /cgi-bin/koha/catalogue/itemsearch.pl for example), has no problem showing greek characters on screen or exporting them as CSV (attachments 20220804_on_screen_results.PNG and 20220804_export_to_CSV.PNG). It could very well be a matter of mis-configuration that needs to be checked, and to this end I've opened a separate bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31180 I wonder however where could the guidelines to proper non-latin-tolerant-encoding be that I could consult, so that I may amend my system's ways. NB. My installation uses a db that was first created back in 2012 by the then current koha version.
Created attachment 138590 [details] Spine label PDF, showing greek characters correctly.
Created attachment 138591 [details] Search results on screen, displaying greek characters correctly.
Created attachment 138592 [details] Search results exported as CSV, displaying greek characters correctly.
(In reply to Manos PETRIDIS from comment #22) > If "bad data" is the only issue, why does the problem manifest itself only > in batch label creation? Spine labels are created just fine (attachment > 20220804_Spine labels_Tools_Koha.pdf). Apparently batch label creation has > different rules in defining what "bad data" is. > I am not stating nor am I sure that "bad data" is the or the only issue or an issue at all. It could be. And I have chased label "bugs" before which were, indeed due to bad data. Data which broke very specific use cases. But I acknowledge that this may not be the case here. > Furthermore, search (as in /cgi-bin/koha/catalogue/itemsearch.pl for > example), has no problem showing greek characters on screen or exporting > them as CSV (attachments 20220804_on_screen_results.PNG and > 20220804_export_to_CSV.PNG). The CSV posted originally does have the issues I noted earlier for me. We are working on different environments and what shows properly in one may not in the other.
(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.
Does the labels module keep an error log so that one may know what happens and try and debug the black box?
(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.
Created attachment 149337 [details] Apache log Apache log, after a restart and an attempt to create pdf labels.
If, for some reason, the Homebranch is NULL, the exported PDF will be 0Kb I had that problem