Adding ability to print UPC-E barcodes with UPC-E codes as input

[Bernhard-Krop]

Like I mentioned in issue "UPC-E encoding completely wrong information", UPC-E barcodes could only be generated with UPC-A codes as input. This pull request adds the ability to generate UPC-E barcodes with UPC-E codes as input.

[casperbakker]

@Bernhard-Krop I think there should be a better way to split the UPC-A and UPC-E barcode types, what do you think? It seems to be too much intertwined in the code. If these are so different, maybe split the type definitions?

[Bernhard-Krop]

@casperbakker Yes, it was kind of confusing at first.

The problem is not, that the codes are too intertwined. UPC-A, UPC-E, EAN-8 and EAN-13 are created the same way, just having different lengths. So yes, they are intertwined because they are basically the same. The problem was, that UPC-E barcodes did only allow UPC-A codes as input; not UPC-E codes (barcode: the printed image; code: the input string). I've added the ability (using UPC-E codes to create UPC-E barcodes) without removing the old ability (using UPC-A codes to create UPC-E barcodes). By doing that, I've also added the ability to create UPC-A barcodes using UPC-E codes.

I see two solutions:

• I can try to refactor the code to be more readable.
• Or I remove the old ability (using UPC-A codes to create UPC-E barcodes) and new ability (using UPC-E codes to create UPC-A barcodes). This would simplify the code, but would also be a backwards incompatable change. Users will have to ensure the provided code is of the same barcode type as the barcode they want.
  • Doing the second solution, I could also provide a static method to convert UPC-A code to UPC-E code and vice versa.

Which one would you prefer?