Bug 2499 - Improvement on text wrapping algorithm needed
Summary: Improvement on text wrapping algorithm needed
Status: Patch doesn't apply
Alias: None
Product: Koha
Classification: Unclassified
Component: Label/patron card printing (show other bugs)
Version: master
Hardware: PC All
: P5 - low enhancement (vote)
Assignee: wajasu
QA Contact:
Depends on:
Reported: 2008-08-09 07:36 UTC by Chris Cormack
Modified: 2016-12-01 21:59 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:

0001-Bug-2499 add support for text wrapping using proportional font metrics (5.83 KB, patch)
2013-03-06 00:47 UTC, wajasu
Details | Diff | Splinter Review
0002-Bug-2499-remove-arbitrary-line-limit-for-label-text (6.50 KB, patch)
2013-03-06 05:19 UTC, wajasu
Details | Diff | Splinter Review
0001-Bug-2499-add-support-for-text-wrapping-using-proportional (5.78 KB, patch)
2013-03-06 05:28 UTC, wajasu
Details | Diff | Splinter Review
0002-Bug-2499-remove-arbitrary-line-limit-for-label-text (6.45 KB, patch)
2013-03-06 05:29 UTC, wajasu
Details | Diff | Splinter Review
example barcode with extra info the title (9.52 KB, image/png)
2013-03-06 14:02 UTC, wajasu
Signed-off-by: Joy Nelson <joy@bywatersolutions.com> (6.50 KB, patch)
2013-10-21 00:09 UTC, Joy Nelson
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:51:52 UTC

---- Reported by chris.nighswonger@liblime.com 2008-08-09 07:36:14 ----

Currently the title field is truncated after wrapping beyond 2 lines. This should be corrected so that the truncation point is determined by the remaining lines on the label less the remaining lines needed for other fields.

---- Additional Comments From cnighswonger@foundations.edu 2009-07-28 17:19:51 ----

Reassigning to self in a different namespace... ;-)

---- Additional Comments From cnighswonger@foundations.edu 2010-02-05 02:44:50 ----

*** http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3454 has been marked as a duplicate of this bug. ***

---- Additional Comments From cnighswonger@foundations.edu 2010-02-05 03:21:00 ----

Changing this to an enhancement as there are other ways of dealing with the rare instances when the current algorithm does not work as desired.

--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:51 UTC  ---

This bug was previously known as _bug_ 2499 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2499

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was chris.nighswonger@liblime.com.
CC member omlecka@gmail.com does not have an account here

Comment 1 MJ Ray (software.coop) 2013-01-09 14:38:46 UTC
Does this apply to the label creator despite the summer 2009 changes?
Comment 2 Chris Nighswonger 2013-01-09 15:07:13 UTC
(In reply to comment #1)
> Does this apply to the label creator despite the summer 2009 changes?

As far as I know this still applies.
Comment 3 wajasu 2013-03-05 01:52:31 UTC
I did write a sub-routine in C4/Labels/Labels.pm that used StrWidth for each individual character of the specified font/fontsize, such that if it was going to get truncated, it would scan back to the prior space and wrap to the next line.  Typically, the title being the culprit.  I did get a word or two extra in the first line.

I did not add behavior to throw way the second line, if there are more lines to be written.  I suppose this would also need to content with varying line height based on the fontsize, because folks might be dropping to a smaller fontsize (10 is about 4 lines, 6 might get you more).

But my labels are usually:
itemcallnumber, author, title (possible2 lines) in a BIBBAR printstyle.
font Times Roman, fontsize 10.

A title like:
Salty librarians, and savvy cataloguers,
dusty books :

Salty librarians, and savvy cataloguers,dusty
books :

with my proportional wrap.

Let me know and I'll work on sending a patch.
Comment 4 Chris Nighswonger 2013-03-05 02:10:26 UTC
I'm not sure what approach you've taken, but here is the problem code:


 433             eval{$Text::Wrap::columns = $self->{'text_wrap_cols'};};
 434             my @line = split(/\n/ ,wrap('', '', $field_data));
 435             # If this is a title field, limit to two lines; all others limit to one... FIXME: this is rather arbitrary
 436             if ($field->{'code'} eq 'title' && scalar(@line) >= 2) {
 437                 while (scalar(@line) > 2) {
 438                     pop @line;
 439                 }
 440             } else {
 441                 while (scalar(@line) > 1) {
 442                     pop @line;
 443                 }
 444             }
 445             push(@label_lines, @line);
 446         }

As it is it is, well, rather arbitrary.

A little while later we do something much more intelligent to figure line width in the justification routine:

 450             my $string_width = C4::Creators::PDF->StrWidth($line, $font, $self->{'font_size'});

Something similar could be done to replace the arbitrary method back at lines 433-446.
Comment 5 wajasu 2013-03-06 00:47:29 UTC Comment hidden (obsolete)
Comment 6 wajasu 2013-03-06 05:19:50 UTC Comment hidden (obsolete)
Comment 7 wajasu 2013-03-06 05:28:56 UTC
Created attachment 15900 [details] [review]
Comment 8 wajasu 2013-03-06 05:29:54 UTC
Created attachment 15901 [details] [review]
Comment 9 wajasu 2013-03-06 14:02:22 UTC
Created attachment 15908 [details]
example barcode with extra info the title

smaller fonts get you more lines
Comment 10 Joy Nelson 2013-10-21 00:09:53 UTC
Created attachment 22142 [details] [review]
Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
Comment 11 Katrin Fischer 2013-12-26 14:18:31 UTC
Hi Joy, it looks like you only signed off on the first patch - could you take another look at this?
Comment 12 David Cook 2014-03-26 06:56:06 UTC
*pinging Joy*

I've been thinking about sending in a patch for wrapping the call number, but I should probably wait until this is sorted out first.
Comment 13 David Cook 2014-03-31 03:48:16 UTC
Actually, a quick glance at this code makes me think that we're adding "more" arbitrary numbers into the label printer... 

I would need to take a further look but I think it would be an idea to look at Chris Nighswonger's idea of using C4::Creators::PDF->StrWidth which uses PDF::Reuse's prStrWidth method for calculating string width.