Bug 36819 - Default layout data prints squished barcodes
Summary: Default layout data prints squished barcodes
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Label/patron card printing (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Caroline Cyr La Rose
QA Contact: Lucas Gass (lukeg)
URL:
Keywords:
Depends on: 10762
Blocks:
  Show dependency treegraph
 
Reported: 2024-05-08 20:42 UTC by Caroline Cyr La Rose
Modified: 2024-10-03 21:34 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
This fixes the default label layouts value for the barcode width (Cataloging > Tools > Label creator > Manage > Layouts > choose a layout). It was incorrectly set to 0.080000 when it should have been 0.800000 - this was resulting is squished barcodes when printing. Note: For existing 23.11 installations, this updates the correct value for the barcode width (field scale_width) to 0.800000 IF it is 0.080000. If it is any other value, no change is made.
Version(s) released in:
24.05.00,23.11.07
Circulation function:


Attachments
Bug 36819: Default layout data prints squished barcodes (1.60 KB, patch)
2024-05-08 21:06 UTC, Caroline Cyr La Rose
Details | Diff | Splinter Review
Bug 36819: Default layout data prints squished barcodes (1.65 KB, patch)
2024-05-14 04:08 UTC, David Nind
Details | Diff | Splinter Review
Bug 36819: Default layout data prints squished barcodes (1.65 KB, patch)
2024-05-14 19:57 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review
Bug 36819: Default layout data prints squished barcodes (1.70 KB, patch)
2024-05-14 19:57 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review
Bug 36819: (follow-up) Updatedatabase to correct wrong value (1.37 KB, patch)
2024-05-21 13:40 UTC, Caroline Cyr La Rose
Details | Diff | Splinter Review
Bug 36819: (follow-up) Updatedatabase to correct wrong value (1.44 KB, patch)
2024-05-21 15:18 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review
Bug 36819: (QA follow-up) Improve update output (1.34 KB, patch)
2024-05-21 15:18 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Caroline Cyr La Rose 2024-05-08 20:42:03 UTC
When using the default layouts, the barcodes print all squished. If you open the layout and save, then it's ok.

To recreate:
**On a fresh db**
1. Go to Cataloging > Label creator
2. Click New > Label batch
3. Enter the following barcodes in the text field (or enter your own, I'm providing this for easy copy-paste)

39999000010114
39999000010138
39999000010152
39999000011333
39999000002331
39999000002355

4. Click Add items
5. Click Export full batch
6. Choose the following
   - Template: Avery 5160 | 1 x 2-5/8
   - Layout: Label test
7. Click Export
8. Click Download as PDF
9. Open the PDF
   --> Note the squished barcodes
10. Click Close
11. Click Manage > Layouts
12. Click Edit next to Label test
13. Delete the values in Barcode width and Barcode leength
14. Click Save
(Optional: reopen Label test, note the values came back anyway)
15. Click Manage > Label batches
16. Click Edit next to the label batch 1
17. Repeat steps 5 to 9
    --> Note the barcodes now look OK
Comment 1 Caroline Cyr La Rose 2024-05-08 20:48:34 UTC
I tried to look at the db data before and after the change, and I don't see a difference. I thought maybe it was NULL and after it was filled with the correct values, but the values are already there...

Layout 17 before step 13

MariaDB [koha_kohadev]> select * from creator_layouts where layout_id = 17 \G;
*************************** 1. row ***************************
    layout_id: 17
 barcode_type: CODE39
  start_label: 1
printing_type: BIBBAR
  layout_name: Label Test
     guidebox: 0
oblique_title: 1
         font: TR
    font_size: 3
  scale_width: 0.080000
 scale_height: 0.010000
        units: POINT
callnum_split: 0
 text_justify: L
format_string: title, author, isbn, issn, itemtype, barcode, itemcallnumber
   layout_xml: <opt></opt>
      creator: Labels
1 row in set (0.001 sec)

Layout 17 after step 14

MariaDB [koha_kohadev]> select * from creator_layouts where layout_id = 17 \G;
*************************** 1. row ***************************
    layout_id: 17
 barcode_type: CODE39
  start_label: 1
printing_type: BIBBAR
  layout_name: Label Test
     guidebox: 0
oblique_title: 1
         font: TR
    font_size: 3
  scale_width: 0.800000
 scale_height: 0.010000
        units: POINT
callnum_split: 0
 text_justify: L
format_string: title, author, isbn, issn, itemtype, barcode, itemcallnumber
   layout_xml: <opt></opt>
      creator: Labels
1 row in set (0.000 sec)
Comment 2 Caroline Cyr La Rose 2024-05-08 20:51:20 UTC
Oh I see it *facepalm*

Before : 0.080000
After  : 0.800000
Comment 3 Caroline Cyr La Rose 2024-05-08 21:06:31 UTC
Created attachment 166443 [details] [review]
Bug 36819: Default layout data prints squished barcodes

This patch changes the default layout data for the barcode
width.

To test:
**On a fresh db**
1. Go to Cataloging > Label creator
2. Click New > Label batch
3. Enter the following barcodes in the text field (or enter your own)

39999000010114
39999000010138
39999000010152
39999000011333
39999000002331
39999000002355

4. Click Add items
5. Click Export full batch
6. Choose the following
   - Template: Avery 5160 | 1 x 2-5/8
   - Layout: Label test
7. Click Export
8. Click Download as PDF
9. Open the PDF
   --> Note the squished barcodes
10. Apply patch and reset_all
11. Redo steps 1 to 9
    --> Note the barcodes now look OK
Comment 4 David Nind 2024-05-14 04:08:41 UTC
Created attachment 166667 [details] [review]
Bug 36819: Default layout data prints squished barcodes

This patch changes the default layout data for the barcode
width.

To test:
**On a fresh db**
1. Go to Cataloging > Label creator
2. Click New > Label batch
3. Enter the following barcodes in the text field (or enter your own)

39999000010114
39999000010138
39999000010152
39999000011333
39999000002331
39999000002355

4. Click Add items
5. Click Export full batch
6. Choose the following
   - Template: Avery 5160 | 1 x 2-5/8
   - Layout: Label test
7. Click Export
8. Click Download as PDF
9. Open the PDF
   --> Note the squished barcodes
10. Apply patch and reset_all
11. Redo steps 1 to 9
    --> Note the barcodes now look OK

Signed-off-by: David Nind <david@davidnind.com>
Comment 5 Lucas Gass (lukeg) 2024-05-14 19:57:03 UTC
Created attachment 166734 [details] [review]
Bug 36819: Default layout data prints squished barcodes

This patch changes the default layout data for the barcode
width.

To test:
**On a fresh db**
1. Go to Cataloging > Label creator
2. Click New > Label batch
3. Enter the following barcodes in the text field (or enter your own)

39999000010114
39999000010138
39999000010152
39999000011333
39999000002331
39999000002355

4. Click Add items
5. Click Export full batch
6. Choose the following
   - Template: Avery 5160 | 1 x 2-5/8
   - Layout: Label test
7. Click Export
8. Click Download as PDF
9. Open the PDF
   --> Note the squished barcodes
10. Apply patch and reset_all
11. Redo steps 1 to 9
    --> Note the barcodes now look OK

Signed-off-by: David Nind <david@davidnind.com>
Comment 6 Lucas Gass (lukeg) 2024-05-14 19:57:48 UTC
Created attachment 166735 [details] [review]
Bug 36819: Default layout data prints squished barcodes

This patch changes the default layout data for the barcode
width.

To test:
**On a fresh db**
1. Go to Cataloging > Label creator
2. Click New > Label batch
3. Enter the following barcodes in the text field (or enter your own)

39999000010114
39999000010138
39999000010152
39999000011333
39999000002331
39999000002355

4. Click Add items
5. Click Export full batch
6. Choose the following
   - Template: Avery 5160 | 1 x 2-5/8
   - Layout: Label test
7. Click Export
8. Click Download as PDF
9. Open the PDF
   --> Note the squished barcodes
10. Apply patch and reset_all
11. Redo steps 1 to 9
    --> Note the barcodes now look OK

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Comment 7 Katrin Fischer 2024-05-17 07:58:45 UTC
Did we figure out why this change became necessary? Should we have a note for existing installations or even a database update?
Comment 8 Katrin Fischer 2024-05-17 08:37:50 UTC
Pushed for 24.05!

Well done everyone, thank you!
Comment 9 Caroline Cyr La Rose 2024-05-17 13:12:34 UTC
(In reply to Katrin Fischer from comment #7)
> Did we figure out why this change became necessary? Should we have a note
> for existing installations or even a database update?

The existing updatedb was correct. It was only for new installations that there was a problem. Is there a way to discriminate the ones that are ok and the ones that were installed since the bug.
Comment 10 Katrin Fischer 2024-05-17 18:46:14 UTC
Thx Caroline. I think maybe we can do without an additional update then as we can not really be sure if the value is 'original' or has been changed?
Comment 11 Caroline Cyr La Rose 2024-05-17 19:44:34 UTC
(In reply to Katrin Fischer from comment #10)
> Thx Caroline. I think maybe we can do without an additional update then as
> we can not really be sure if the value is 'original' or has been changed?

Can we do "IF value = 0.080000 THEN change value to 0.800000" ?
Comment 12 Katrin Fischer 2024-05-20 19:42:04 UTC
We can do something like:

UPDATE creator_layouts SET scale_width = 0.800000 WHERE scale_width = 0.080000;

We cannot really tell if it's an unchanged sample one... but maybe that's a very low risk here.
Comment 13 Chris Nighswonger 2024-05-20 19:44:27 UTC
(In reply to Katrin Fischer from comment #12)
> We can do something like:
> 
> UPDATE creator_layouts SET scale_width = 0.800000 WHERE scale_width =
> 0.080000;
> 
> We cannot really tell if it's an unchanged sample one... but maybe that's a
> very low risk here.

Just catching up here.

This really should not have been pushed without the constraint Katrin proposes. the time we think it won't matter, it will. That's just how things roll unfortunately.
Comment 14 Katrin Fischer 2024-05-20 19:50:49 UTC
We haven't released with the first patch yet, so there is still time for the database update, but the problem started earlier with bug 10762.
Comment 15 Katrin Fischer 2024-05-20 19:51:14 UTC
Also: Hi Chris N.! *waves*
Comment 16 Chris Nighswonger 2024-05-20 20:23:20 UTC
(In reply to Katrin Fischer from comment #15)
> Also: Hi Chris N.! *waves*

Hey Katrin! *waves back*
Comment 17 Caroline Cyr La Rose 2024-05-21 13:40:38 UTC
Created attachment 166974 [details] [review]
Bug 36819: (follow-up) Updatedatabase to correct wrong value

This patch adds an update to correct the value of scale_width to
0.800000 IF it is 0.080000. It should not change the value if it
is anything else than 0.080000.
Comment 18 Martin Renvoize (ashimema) 2024-05-21 15:18:09 UTC
Created attachment 166982 [details] [review]
Bug 36819: (follow-up) Updatedatabase to correct wrong value

This patch adds an update to correct the value of scale_width to
0.800000 IF it is 0.080000. It should not change the value if it
is anything else than 0.080000.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 19 Martin Renvoize (ashimema) 2024-05-21 15:18:12 UTC
Created attachment 166983 [details] [review]
Bug 36819: (QA follow-up) Improve update output
Comment 20 Katrin Fischer 2024-05-22 13:35:14 UTC
Hm, seeing this, I'll try to see if I can understand/fix:

 FAIL	installer/data/mysql/atomicupdate/bug_36819.pl
   FAIL	  valid
		syntax error
		installer/data/mysql/atomicupdate/bug_36819.pl had compilation errors.
Comment 21 Katrin Fischer 2024-05-22 14:20:07 UTC
Pushed for 24.05!

Well done everyone, thank you!
Comment 22 Caroline Cyr La Rose 2024-05-22 14:48:25 UTC
(In reply to Katrin Fischer from comment #20)
> Hm, seeing this, I'll try to see if I can understand/fix:
> 
>  FAIL	installer/data/mysql/atomicupdate/bug_36819.pl
>    FAIL	  valid
> 		syntax error
> 		installer/data/mysql/atomicupdate/bug_36819.pl had compilation errors.

Did you figure it out / fix it?
Comment 23 Katrin Fischer 2024-05-22 14:49:23 UTC
Yes, I did - it was a stray semicolon in the follow-up. Fixed and pushed.
Comment 24 Caroline Cyr La Rose 2024-05-22 14:49:49 UTC
For release maintainers, this came about in 23.11. Before that, the scale_width doesn't exist.
Comment 25 Fridolin Somers 2024-05-29 12:53:58 UTC
Looks like 'additional_work_needed' is obsolete
Comment 26 Fridolin Somers 2024-05-29 12:54:43 UTC
I prefer looks at this in next release 23.11.07
Comment 27 Caroline Cyr La Rose 2024-06-25 15:07:06 UTC
(In reply to Fridolin Somers from comment #25)
> Looks like 'additional_work_needed' is obsolete

I think so too. I don't see what else is missing. I removed the keyword.
Comment 28 Fridolin Somers 2024-07-19 09:05:06 UTC
Pushed to 23.11.x for 23.11.07
Comment 29 David Nind 2024-07-22 03:12:05 UTC
I've added a release note, even though it was pushed to 24.05.

I've also changed the status to "Needs documenting", as this is a fix for an enhancement in 23.11.00 that was not back ported to any earlier releases.
Comment 30 Wainui Witika-Park 2024-09-12 06:18:16 UTC
Not backporting to 23.05.x unless requested
Comment 31 Caroline Cyr La Rose 2024-10-03 21:34:26 UTC
This is a bug fix, no documentation needed.