Skip to content

Conversation

@TheLastProject
Copy link
Member

  • Add new barcodeencoding field to database
  • Read barcode encoding from pkpass file
  • On default, use zxing's GuessEncoding function in StringUtils (this should not use UTF-8 unless needed)
  • Allow manually forcing ISO-8859-1 or UTF-8

TODO:

  • Fix Catima import/export
  • Test test test test test
  • Re-read the code over and over, this feels like a mess, may contain bugs :(
  • Do another release without this fix

- Add new barcodeencoding field to database
- Read barcode encoding from pkpass file
- On default, use zxing's GuessEncoding function in StringUtils (this
  should not use UTF-8 unless needed)
- Allow manually forcing ISO-8859-1 or UTF-8
@TheLastProject
Copy link
Member Author

TheLastProject commented Nov 2, 2025

@joserebelo Before I finish this, I have a question for the Gadgetbridge side of this:

The plan is to add a new barcodeEncoding field, which defaults to auto (null) if it is not set, unless a pkpass file explicitly sets it. When it is set to "auto", Catima will ask zxing to guess if it should use UTF-8 or not.

What would be the best behaviour for the ContentProvider update?

  1. I'm planning to bump the minor version, as adding a new field is not incompatible
  2. For the barcodeEncoding field in the ContentProvider, should it return null, just like it does in the database, or should it return the "guessed" encoding that Catima would use to display, so Gadgetbridge doesn't have to guess (but technically has "incorrect" data, as it's null in the database)?

Edit: With regards to 2, I think it makes most sense for the ContentProvider to give the simplest usable data to draw a card, instead of the exactly correct info. If full export-import compat is desired, the exporter seems more sensible to use anyway. So, barcodeEncoding would give whatever Catima would be using, guessed or not, but never null.

@joserebelo
Copy link
Contributor

joserebelo commented Nov 24, 2025

@TheLastProject apologies for the delay, I was away and just now catching up no a few notifications.

  1. A minor version bump would be the expectation for a new field.
  2. I believe it would indeed make sense for the field to contain the guessed value. The fact that we currently expose the database is an implementation detail that greatly simplified the implementation at the time, but I think the content provider should serve as a higher level interface, and indeed provide usable data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Cyrillic and other characters support in QR code from pkpass files

2 participants