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.