Bug 7062 - Titles on labels not truncating
Summary: Titles on labels not truncating
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Label/patron card printing (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Chris Nighswonger
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-19 11:53 UTC by Nicole C. Engard
Modified: 2019-04-28 22:50 UTC (History)
5 users (show)

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


Attachments
one example of a broken label (19.65 KB, image/png)
2011-10-19 11:53 UTC, Nicole C. Engard
Details
label set up (50.25 KB, image/png)
2011-10-19 11:53 UTC, Nicole C. Engard
Details
label sheet (5.96 KB, application/pdf)
2011-10-19 17:21 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 2011-10-19 11:53:12 UTC
Created attachment 5973 [details]
one example of a broken label

After upgrading from 3.4.x to master there are some label inconsistencies.  In the previous version, the title printed on the label as only ONE line and the title truncated at the end of the line. Now, despite having the same values in the template, the title goes to two or three lines, however long the title actually is in the database field. As a result, the library name that is the first line of the barcode is being cut off.
Comment 1 Nicole C. Engard 2011-10-19 11:53:26 UTC
Created attachment 5974 [details]
label set up
Comment 2 Nicole C. Engard 2011-10-19 17:21:54 UTC
Created attachment 5987 [details]
label sheet
Comment 3 Chris Nighswonger 2011-10-19 18:06:26 UTC
For reference: this bug is due to the text wrap code not taking into account proportionally spaced fonts and various font sizes. The code should use C4::Creators::PDF->StrWidth to determine the actual width of the title line and split it accordingly.

It will also be necessary to accommodate for the varying line height caused by increasing font sizes. It is possible that one could select a font size so large that there is no way to get the title on the label *and* include other information as well.

It would probably be good to include some discussion of font-size versus label-size in the manual along with some suggestions for basic sanity checks (ie. Don't use font sizes above X points on labels with dimensions Y by Z... or some such.)

FWIW, this same problem will occur in any publishing software as your font size becomes large in proportion to your text box size.

Hopefully these comments will help in case someone gets to this before I do.

For now, setting the font size down to around 6 points should help with the examples included in this bug.
Comment 4 Chris Nighswonger 2011-10-19 18:07:04 UTC
Here is the section of underlying code for reference:

http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=C4/Labels/Label.pm;h=930e0f6ef407134c4046eb3156e641a23eb255d4;hb=HEAD#l432
Comment 5 Ian Walls 2011-10-21 11:54:09 UTC
Was there any difference between the implementation of C4::Labels::PDF->StrWdith and C4::Creators::PDF->StrWidth?  I see that it was change in commit 4a675bca, and if the return value there is somehow different, that may account for the discrepancy.
Comment 6 Chris Nighswonger 2011-10-22 17:45:15 UTC
(In reply to comment #5)
> Was there any difference between the implementation of
> C4::Labels::PDF->StrWdith and C4::Creators::PDF->StrWidth?  I see that it was
> change in commit 4a675bca, and if the return value there is somehow different,
> that may account for the discrepancy.

No difference. This problem has existed all along for the reasons described in comment #3.
Comment 7 Nicole C. Engard 2011-11-11 16:46:51 UTC
And update here, if you change the label from using 'title' to looking at '245a' instead it doesn't have this problem.

Nicole
Comment 8 wajasu 2013-03-06 05:42:05 UTC
I added proportional font support in bug 2499.

I added support to draw unlimited lines.

I did code some support to truncate a line if the internal text_wrap_cols == 0.

But I didn't have any external way for that to be configured, so if someone wants to enhance the list of fields, they might come up with some modifier  like:

itemcallnumber,author,[title]

such that if the list has any bracketed, that could signal the code to truncate instead of wrap.

Then later in the code we could set text_wrap_cols to 0, instead of calculating it from other settings.

OR

itemcallnumber,author,title[TI]

grab modifiers in brackets:
T = truncate
I = italic

but then we have:
"090a" and friends, and  'I Am a text string' support.

OR

we add a column to a layout/template/profile table.

Maybe this should be dependent on bug 2499.
Comment 9 Marc Véron 2016-02-10 13:58:29 UTC
Still valid?