Bug 12990 - add overflow option to label creator
Summary: add overflow option to label creator
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Label/patron card printing (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Chris Nighswonger
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-24 18:57 UTC by Nicole C. Engard
Modified: 2014-09-24 19:35 UTC (History)
0 users

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
labels (29.52 KB, image/jpeg)
2014-09-24 18:57 UTC, Nicole C. Engard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2014-09-24 18:57:22 UTC
Created attachment 31860 [details]
labels

Maybe have an option in the template to put overflow onto the next line? If the logic knows enough to cut off information when it gets to the end of the column in the PDF exporter, I'd think adding a newline character might not be that big of a deal. As you can see in the attached screen shot, the way the system works now, valuable information can get cut off. That $n field should say The Final Season [Season 5, Part 1].
Comment 1 Chris Nighswonger 2014-09-24 19:35:53 UTC
(In reply to Nicole C. Engard from comment #0)
> Created attachment 31860 [details]
> labels
> 
> Maybe have an option in the template to put overflow onto the next line? If
> the logic knows enough to cut off information when it gets to the end of the
> column in the PDF exporter, I'd think adding a newline character might not
> be that big of a deal.

This is not as simple as it may seem with the way things are written atm. The code which does the wrapping arbitrarily limits the title field to two lines and all other fields (ie. the aforementioned $n) to one line.[1] There is a comment in there which notes the need to fix this, but it will take reworking the label logic to fix it right. Every field to be printed on a given label will have to be examined to see how long it is and how it will interact with the other fields on the label if it overflows the line. Then some sort of weighting would have to be designated in order to allow the logic to determine the importance of the content of one field over another when conflicts arose as to just what actually gets placed on the label so that the entire label content does not overflow the label itself.

At least that is what it looked like when the code was written. Perhaps there is an easier way.

[1] http://tinyurl.com/kml7zu4