[Bug 42943] New: Spine labels not formatting correctly
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 Bug ID: 42943 Summary: Spine labels not formatting correctly Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: PC OS: Windows Status: NEW Severity: major Priority: P5 - low Component: Label/patron card printing Assignee: chris.nighswonger@veritassuperaitsolutions.com Reporter: sarah.harvey1@health.nsw.gov.au QA Contact: testopia@bugs.koha-community.org Target Milestone: --- Created attachment 201228 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201228&action=edit Example of pdf generated to print labels. Call number running long instead of splitting. Since the recent update to Version 25.11, our spine labels are not splitting the call number, see attached file. I have fiddled with settings but cannot get the issue to resolve. Settings are back as to before, I can only attach one file here, will see if I can attach another with the settings once submitted. I note a previous bug where the issue was that the call numbers where nlm, where if lcc was selected, the call number would split. We use DDC. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 sarah.harvey1@health.nsw.gov.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sarah.harvey1@health.nsw.go | |v.au --- Comment #1 from sarah.harvey1@health.nsw.gov.au --- Created attachment 201229 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201229&action=edit Screenshots of current label settings. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #2 from David Cook <dcook@prosentient.com.au> --- Hi Sarah, This is more of a local support issue for your vendor (ie me) rather than a bug for the Koha community. I'll follow up with you by email. That said, I'll leave this report open, since it might be that there is a bug in Koha that needs to be fixed. Chat soon! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- I don't think that this is a regression. I think that it's a longstanding issue with Koha. I'm going to double-check some older versions, but I think this might just need a fix in general. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |enhancement Version|25.11 |Main Assignee|chris.nighswonger@veritassu |dcook@prosentient.com.au |peraitsolutions.com | Summary|Spine labels not formatting |Call number fields should |correctly |wrap like non-call number | |fields -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- About 12 years ago, I wrote a local customisation to wrap the call number fields (ie itemcallnumber 050a 050b 082a 952o 995k) in the same way that Koha wraps the non-call number fields (ie using Text::Wrap). Koha does employ a number of call number splitting routines like LCC, Generic, RegEx, but... it is possible for these routines to return numbers that are wider than the label. For example: "610.73089915 YAT 2026" As Sarah points out, with the spine labels she's using, that Dewey number overflows the label. While removing a different outdated local customization, I must've accidentally removed this one too - hence Sarah's report. I'm fixing it locally, but I think it would be useful for the rest of the world too, so after I fix it locally, I'm going to submit a patch here too. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- Created attachment 201625 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201625&action=edit Before the patch (callnumber overflows label) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- Created attachment 201626 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201626&action=edit After the patch (callnumber wrapped within label) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #201229|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #201228|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- Created attachment 201627 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201627&action=edit Bug 42943: wrap long call number fields on labels This change uses Text::Wrap to wrap long call number fields on labels in the same way that other non-call number fields get wrapped. Test plan: __BEFORE APPLYING PATCH__ 1. Create item with long call number 1a. In KTD, log into the staff interface 1b. Click "Search catalog" on the top nav 1c. Type in "test" and hit the search button at the end of the input box 1d. Click on Gairm 1e. Click "Edit" next to the item at the bottom of the screen 1f. Input "610.73089915 YAT 2026" into "o - Full call number" and click "Save changes" 2. Create label layout 2a. From the home page, go to "Cataloging" 2b. Click "Label creator" 2c. Click "New" then choose "Label layout" 2d. Fill in the following fields: Layout name: SPINE Choose barcode type: Code 39 Choose layout type: Only the bibliographic data is printed List fields: itemcallnumber, homebranch Draw guide boxes: <checked> Split call numbers: <checked> Font size: 9 Barcode width: 0.8000 Barcode height: 0.0100 Oblique title: <checked> 2e. Click Save 3. Create label template 3a. From "Label creator" page, click "New" then choose "Label template" 3b. Fill in the following fields: Template code: Standard Raeco 12603 Template description: Spine labels 11x12 Units: SI Centimeters Page height: 29.6 Page width: 21.1 Label width: 1.9 Label height: 2.4 Top page margin: 0.4 Left page margin: 0.1 Top text margin: 0.4 Left text margin: 0.3 Number of columns: 11 Number of rows: 12 3c. Click "Save" 4. Create label batch 4a. From the "Label creator" page, click "New" then choose "Label batch" 4b. Choose "Enter by barode" 4c. In the "Add by barcode(s) or itemnumbers(s):" box, paste the following: 39999000001310 39999000001310 39999000001310 39999000001310 39999000001310 39999000001310 4d. Click "Add item(s) 5. Export label batch 5a. Click "Export full batch" For "Select a template to be applied", choose "Standard Raeco 12603" For "Select a layout to be applied", choose "SPINE" 5b. Click "Export" 5c. Click "Download as PDF" 6. Note that the call numbers overrun the edge of the guideboxes 7. Apply the patch 8. restart_all 9. Click "Download as PDF" again 10. Note that the call numbers are now wrapped to fit within the guideboxes -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- Created attachment 201628 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201628&action=edit Bug 42943: Add unit test Patch from commit 63eae35 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Will the splitting rules still be applied or could that interfere with those? I imagine some libraries might prefer the spitting done correctly over the wrapping. Maybe a checkbox like for the splitting could be useful. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #9)
Will the splitting rules still be applied or could that interfere with those? I imagine some libraries might prefer the spitting done correctly over the wrapping. Maybe a checkbox like for the splitting could be useful.
The splitting rules happen before this. If the splitting rules split the lines so they're within the bounds of the label, then this will do nothing. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #10)
(In reply to Katrin Fischer from comment #9)
Will the splitting rules still be applied or could that interfere with those? I imagine some libraries might prefer the spitting done correctly over the wrapping. Maybe a checkbox like for the splitting could be useful.
The splitting rules happen before this. If the splitting rules split the lines so they're within the bounds of the label, then this will do nothing.
This is really just a sanity check/safety measure to make sure the text can't overflow the label. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@openfifth.c | |o.uk --- Comment #12 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- This makes a lot of sense to me.. my only slight worry is how does it affect other fields and the overall useful space one can use for a label.. C4/Labels/Label.pm:460-469 — unbounded wrapped-line count can push subsequent label fields off the label. $text_lly (the vertical cursor) is initialized once before the LABEL_FIELDS loop and decremented for every rendered line across all fields on the label — it's never reset per field. The sibling non-callnumber branch a few lines below caps output to 2 lines (title) or 1 line (everything else) for exactly this reason. The new callnumber branch has no such cap: if a call number is split into N parts and each part wraps into M lines, that's N×M lines consuming vertical space meant for later fields (e.g. barcode, homebranch). This doesn't corrupt data or crash anything, but it trades the reported bug (horizontal overrun) for a potentially worse one (fields overlapping/pushed off the label) on longer or multi-part call numbers. Worth capping wrapped call-number lines to some reasonable max (e.g. 3-4), consistent with the pattern used just below. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #201627|0 |1 is obsolete| | Attachment #201628|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #13 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201638 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201638&action=edit Bug 42943: Wrap long call number fields on labels This change uses Text::Wrap to wrap long call number fields on labels in the same way that other non-call number fields get wrapped. Test plan: __BEFORE APPLYING PATCH__ 1. Create item with long call number 1a. In KTD, log into the staff interface 1b. Click "Search catalog" on the top nav 1c. Type in "test" and hit the search button at the end of the input box 1d. Click on Gairm 1e. Click "Edit" next to the item at the bottom of the screen 1f. Input "610.73089915 YAT 2026" into "o - Full call number" and click "Save changes" 2. Create label layout 2a. From the home page, go to "Cataloging" 2b. Click "Label creator" 2c. Click "New" then choose "Label layout" 2d. Fill in the following fields: Layout name: SPINE Choose barcode type: Code 39 Choose layout type: Only the bibliographic data is printed List fields: itemcallnumber, homebranch Draw guide boxes: <checked> Split call numbers: <checked> Font size: 9 Barcode width: 0.8000 Barcode height: 0.0100 Oblique title: <checked> 2e. Click Save 3. Create label template 3a. From "Label creator" page, click "New" then choose "Label template" 3b. Fill in the following fields: Template code: Standard Raeco 12603 Template description: Spine labels 11x12 Units: SI Centimeters Page height: 29.6 Page width: 21.1 Label width: 1.9 Label height: 2.4 Top page margin: 0.4 Left page margin: 0.1 Top text margin: 0.4 Left text margin: 0.3 Number of columns: 11 Number of rows: 12 3c. Click "Save" 4. Create label batch 4a. From the "Label creator" page, click "New" then choose "Label batch" 4b. Choose "Enter by barode" 4c. In the "Add by barcode(s) or itemnumbers(s):" box, paste the following: 39999000001310 39999000001310 39999000001310 39999000001310 39999000001310 39999000001310 4d. Click "Add item(s) 5. Export label batch 5a. Click "Export full batch" For "Select a template to be applied", choose "Standard Raeco 12603" For "Select a layout to be applied", choose "SPINE" 5b. Click "Export" 5c. Click "Download as PDF" 6. Note that the call numbers overrun the edge of the guideboxes 7. Apply the patch 8. restart_all 9. Click "Download as PDF" again 10. Note that the call numbers are now wrapped to fit within the guideboxes Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #14 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201639 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201639&action=edit Bug 42943: Add unit test Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #15 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201640 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201640&action=edit Bug 42943: (follow-up) Add tests for callnum_split and short call numbers Adds two subtests to lock in behaviour that isn't currently covered: - when callnum_split is disabled, the call number is not split and is truncated to a single line, exercising the pre-existing non-wrapping fallback path rather than the new Text::Wrap logic. - a call number shorter than text_wrap_cols is left on a single, unwrapped line, confirming the new wrapping code is a no-op for the common case where wrapping isn't actually needed. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #16 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201641 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201641&action=edit Bug 42943: (follow-up) Cap wrapped call number lines to avoid label overrun $text_lly is a single running counter shared across every field drawn on a label, decremented once per rendered line - it is never reset between fields. The non-callnumber branch already caps its output (2 lines for title, 1 line otherwise) to protect that shared budget, but the new callnumber wrapping had no such cap: a call number that splits into several parts, each of which then wraps into several more lines, could consume far more vertical space than before and push subsequent fields (barcode, homebranch, etc.) off the bottom of the label. This caps the wrapped callnumber output at 8 lines - comfortably above the 5 lines produced by the scenario in the original bug report, but bounded rather than unlimited. The exact ceiling is a judgement call open to discussion; a follow-up could instead derive it from the label's actual remaining height, font size and line spacing, but that would need to account for the shared budget across all fields on the label, which the current code does not attempt for any field. Test plan: prove t/db_dependent/Labels/t_Label.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #17 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- I'm not really sure about that last follow-up.. would appreciate your thoughts David -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #18 from David Cook <dcook@prosentient.com.au> --- (In reply to Martin Renvoize (ashimema) from comment #12)
This makes a lot of sense to me.. my only slight worry is how does it affect other fields and the overall useful space one can use for a label..
C4/Labels/Label.pm:460-469 — unbounded wrapped-line count can push subsequent label fields off the label. $text_lly (the vertical cursor) is initialized once before the LABEL_FIELDS loop and decremented for every rendered line across all fields on the label — it's never reset per field. The sibling non-callnumber branch a few lines below caps output to 2 lines (title) or 1 line (everything else) for exactly this reason. The new callnumber branch has no such cap: if a call number is split into N parts and each part wraps into M lines, that's N×M lines consuming vertical space meant for later fields (e.g. barcode, homebranch). This doesn't corrupt data or crash anything, but it trades the reported bug (horizontal overrun) for a potentially worse one (fields overlapping/pushed off the label) on longer or multi-part call numbers. Worth capping wrapped call-number lines to some reasonable max (e.g. 3-4), consistent with the pattern used just below.
Is that what Claude says? ;) I've had the code in prod for 12 years and it's been all right but fair enough - overflowing vertically is a valid concern. But I think it's probably a separate bug rather than a follow-up. Having arbitrary limits to 1-2 lines for non-callnumber fields and X for callnumbers wouldn't necessarily prevent that vertical/y axis overflow. I suppose we could check the difference between the text_lly across all the lines, factor in label height, and a few other variables and then we'd know whether or not we have a vertical overflow. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- Thanks for the unit tests and tackling this one, Martin. Much appreciated! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m QA Contact|testopia@bugs.koha-communit |lucas@bywatersolutions.com |y.org | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #20 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- David, thanks for working on these patches. This is long overdue in Koha. I have two concerns: 1. I don't think we should change behavior and wrap call numbers unless librarians explicitly choose to do so, so I think wrapping should be an option in layouts, turned off by default to not change behavior. 2. I think some would like to have the option to wrap when they do not choose to "Split call numbers". -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #21 from David Cook <dcook@prosentient.com.au> --- (In reply to Lucas Gass (lukeg) from comment #20)
David, thanks for working on these patches. This is long overdue in Koha. I have two concerns:
1. I don't think we should change behavior and wrap call numbers unless librarians explicitly choose to do so, so I think wrapping should be an option in layouts, turned off by default to not change behavior.
I'll reiterate that wrapping will never happen unless the text flows over the boundary of the label. But ok.
2. I think some would like to have the option to wrap when they do not choose to "Split call numbers".
That is an interesting thought. -- I think it's unlikely that I'll work on this one any further, as really I was just trying to upstream a customization we've had for the last 12 years. Think I'll put my energy to other things. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #22 from Lisette Scheer <lisette@bywatersolutions.com> --- (In reply to David Cook from comment #21)
(In reply to Lucas Gass (lukeg) from comment #20)
David, thanks for working on these patches. This is long overdue in Koha. I have two concerns:
1. I don't think we should change behavior and wrap call numbers unless librarians explicitly choose to do so, so I think wrapping should be an option in layouts, turned off by default to not change behavior.
I'll reiterate that wrapping will never happen unless the text flows over the boundary of the label.
But ok.
Lucas and I were discussing this because in cases where a long string gets right to the edge, it might wrap but for the user make little to no difference if it doesn't wrap and instead like one character is cut off. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42943 --- Comment #23 from David Cook <dcook@prosentient.com.au> --- (In reply to Lisette Scheer from comment #22)
Lucas and I were discussing this because in cases where a long string gets right to the edge, it might wrap but for the user make little to no difference if it doesn't wrap and instead like one character is cut off.
I'll admit that I have been curious about that scenario as well. It would be interesting to test for that edge case I think. At this point, it's not clear if it'll wrap or if it'll be cut off (like back in the day when we used typewriters to make spine labels and you might have the number trail over the edge and you just sucked it up as it was mostly clear it was a 6). -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org