---- 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
Does this apply to the label creator despite the summer 2009 changes?
(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.
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 : became: Salty librarians, and savvy cataloguers,dusty books : with my proportional wrap. Let me know and I'll work on sending a patch.
I'm not sure what approach you've taken, but here is the problem code: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=C4/Labels/Label.pm;h=760bacfed998674f9b6544bae7a25b0f9d4aa811;hb=HEAD#l433 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.
Created attachment 15898 [details] [review] 0001-Bug-2499 add support for text wrapping using proportional font metrics Currently when labels are printed and the text would render past the bounding label definition, the number of chars that can be written per row is based off of a fixed size for a character in that font. This change performs text wrapping based on each character's character width metric contained in the specified font. Once truncation is detected, it scans back and breaks on a space, and continues with the next words on subsequent lines. It will allow more characters or words from a 'title' to be written per line when possible. 0001-Bug-2499-add-support-for-text-wrapping-using-proportional font metrics is an improvement, and deals with horizontal aspects, cramming more characters per line when wrapping. The original bug comment wants us to calculate the number of lines one can write vertically so we dont arbitrarily cut off after 2, but use what we can without overlaying a barcode or such. To test this patch: -With a working BIBBAR based label, use itemcallnumber,author,title as well. -With a test biblio, create a batch, and export it as a PDF. -Edit that biblio, and make the title longer (add 4 3 letter words) so that it would wrap to another line, but seems to have space to fit the words it wrapped. -APPLY PATCH -Export batch as a PDF. -Confirm that more words fit per line. To fulfill the original bug description: - perform calculations to determin the number of lines we can write without overlaying the barcode or running past the bottom of the label. - maintain this rows_to_write counter and stop writing lines accordingly, I got this patch in because it should not break anyones existing labels.
Created attachment 15899 [details] [review] 0002-Bug-2499-remove-arbitrary-line-limit-for-label-text 0002-Bug-2499-remove-arbitrary-line-limit-for-label-text Removes the restriction for the amount of lines that may be printed in a label. Testing: (we are testing vertical layout calculation here ) We want to see of many lines from wrapping or from many fields will print if the font size lets them, without overlay in barcode or extending beyond the label edge. - print a working label exported to PDF that employs a barcode. - edit the layout to use larger font_sizes and repeat the export to ensure the text won't overlay the barcode - edit the layout/template to add author, author, author in the list to get even more rows. repeat the export to check if overlay. - edit the layout/template to use smaller fonts (10..5) to see the effects. - also test other label types. spine labels/splitting, just in case. - possibly test other export types (xml/csv), though i don't believe they apply. Note: Since I am not getting the character font height metric from the font, I relied on the existing line_spacer calculation, which is just the font_size. 10pt font = 10, 8pt font = 8.
Created attachment 15900 [details] [review] 0001-Bug-2499-add-support-for-text-wrapping-using-proportional
Created attachment 15901 [details] [review] 0002-Bug-2499-remove-arbitrary-line-limit-for-label-text
Created attachment 15908 [details] example barcode with extra info the title smaller fonts get you more lines
Created attachment 22142 [details] [review] Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
Hi Joy, it looks like you only signed off on the first patch - could you take another look at this?
*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.
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.