Bug 14149 - Labels: Make barcode width and height scaling editable
Summary: Labels: Make barcode width and height scaling editable
Status: RESOLVED DUPLICATE of bug 10762
Alias: None
Product: Koha
Classification: Unclassified
Component: Label/patron card printing (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Chris Nighswonger
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-05 13:15 UTC by Chris Nighswonger
Modified: 2022-10-03 15:59 UTC (History)
4 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Nighswonger 2015-05-05 13:15:35 UTC
Provide an extension of Bug 14107 to apply to barcodes on label layouts as well.
Comment 1 Marc Véron 2015-05-05 20:47:12 UTC
Hi Chris,
I'm sorry but it is not as easy as with the patron cards.

Reason: 
Patron cards store the layout values as xml in the table creator_layouts in field layout_xml, while labels store their values in separate columns.

This is commented in line 41 of :
# FIXME: all layouts should be stored in xml format to greatly simplify handling -chris_n

To expose scaling for editing it would be necessary to first move store the values in the xml field. For exsting installations the values of defined labels would have to be transferred to xml as well and after that the obsolete columns could be removed.

We would then have the same situation as with patron cards and could implement the scaling editing following the same pattern.

Link to schema:
http://schema.koha-community.org/tables/creator_layouts.html
Comment 2 Chris Nighswonger 2015-05-05 23:53:35 UTC
(In reply to Marc Véron from comment #1)

> This is commented in line 41 of :
> # FIXME: all layouts should be stored in xml format to greatly simplify
> handling -chris_n
> 

WOW! Its been a long time since I added that note, but I do remember that appearing to be a much easier method.

Thanks for looking.
Comment 3 Theodoros Theodoropoulos 2015-10-01 09:58:46 UTC
This proposed addition to have the user define the size of the barcode is very useful indeed!

But until then, with the current situation, we realized that the hardcoded relative values in Label.pm were very conservative for 'normal'-sized labels

For our needs, we found out that a default value of 20% of the label height and 90% of the label width (compared to the original values of 10% and 80% respectably) produce taller barcodes that are easier to read.


In case it helps anyone, the relevant patch to achieve this is:
--- ./src/C4/Labels/Label.pm   2015-10-01 10:35:54.414837999 +0300
+++ ./src/C4/Labels/Label.pm.orig      2015-10-01 10:34:38.470837999 +0300
@@ -282,8 +282,8 @@
     my $self = shift;
     my $barcode_llx = $self->{'llx'} + $self->{'left_text_margin'};     # this places the bottom left of the barcode the left text margin distance to right of the left edge of the label ($llx)
     my $barcode_lly = $self->{'lly'} + $self->{'top_text_margin'};      # this places the bottom left of the barcode the top text margin distance above the bottom of the label ($lly)
-    my $barcode_width = 0.8 * $self->{'width'};                         # this scales the barcode width to 80% of the label width
-    my $barcode_y_scale_factor = 0.01 * $self->{'height'};              # this scales the barcode height to 10% of the label height
+    my $barcode_width = 0.9 * $self->{'width'};                         # this scales the barcode width to 90% of the label width
+    my $barcode_y_scale_factor = 0.02 * $self->{'height'};              # this scales the barcode height to 20% of the label height
     return 0, 0, 0, $barcode_llx, $barcode_lly, $barcode_width, $barcode_y_scale_factor;
 }

(Needless to say again that the best approach would be to make it selectable by the user in the template screen!)
Comment 4 Caroline Cyr La Rose 2022-10-03 15:59:49 UTC

*** This bug has been marked as a duplicate of bug 10762 ***