From 13f1426bf564a91c6cdbfb6e6aa8522efdd549f3 Mon Sep 17 00:00:00 2001 From: Denis Ledoux Date: Thu, 3 Mar 2016 10:59:40 +0100 Subject: [PATCH] [FIX] report: UPC-A barcodes drawing It looks like reportlab doesn't handle well UPC-A barcodes. As UPC-A barcodes became EAN13 barcodes when adding a `0` to the beginning of the barcode, and the render is the same, we ask reportlab a EAN13 barcode type when a UPC-A barcode is asked, making sure to add the `0` automatically first. From Wikipedia: ``` The EAN was developed as a superset of UPC, adding an extra digit to the beginning of every UPC number. [...] the original rules for UPC are treated as a '0' if read as EAN-13. A UPC barcode XXXXXXXXXXXX therefore is the EAN-13 barcode 0XXXXXXXXXXXX. It is possible to prefix a UPC barcode with a 0; they become EAN-13 rather than UPC-A. This does not change the check digit. All point-of-sale systems can now understand both equally. ``` opw-670560 --- addons/report/controllers/main.py | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/addons/report/controllers/main.py b/addons/report/controllers/main.py index 56236990316..ba8016f6ea1 100644 --- a/addons/report/controllers/main.py +++ b/addons/report/controllers/main.py @@ -85,6 +85,10 @@ class ReportController(Controller): :param humanreadable: Accepted values: 0 (default) or 1. 1 will insert the readable value at the bottom of the output image """ + if type == 'UPCA' and len(value) in (11, 12, 13): + type = 'EAN13' + if len(value) in (11, 12): + value = '0%s' % value try: width, height, humanreadable = int(width), int(height), bool(humanreadable) barcode = createBarcodeDrawing(