Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

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

wants to merge 3 commits into from
+84 −5

Conversation

Bernhard-Krop
Copy link
Contributor

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.

@Bernhard-Krop
* UPC-E barcodes are now working with UPC-E codes as well (before, we…
4f1bb66 
…re only working with UPC-A codes, which were converted into UPC-E codes).

* * Parity digit and checksum digit can be omitted. A proper barcode will always be created, except the checksum digit is provided and differs from the calculated checksum digit.
* * * If omitted, the parity digit defaults to 0.
* * * If omitted, the checksum digit will be calculated.
@Bernhard-Krop Bernhard-Krop mentioned this pull request Jul 4, 2022
Open
@casperbakker
Copy link
Member

@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
Copy link
Contributor Author

Bernhard-Krop commented Sep 1, 2022 •
edited
Loading

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@Bernhard-Krop @casperbakker