Skip to content

Add barcode encoding support - #2716

Merged
TheLastProject merged 1 commit into
mainfrom
feature/barcodeEncoding
Dec 25, 2025
Merged

TheLastProject merged 1 commit into
mainfrom
feature/barcodeEncoding

Conversation

@TheLastProject

@TheLastProject TheLastProject commented Sep 26, 2025

Copy link
Copy Markdown
Member

Add barcode encoding support

  • Add new barcodeencoding field to database
  • Read barcode encoding from pkpass file
  • Add barcodeencoding to import/export
  • Add barcodeencoding to share URI
  • 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:

  • Implement in content provider (likely separate to this MR)
  • 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

@TheLastProject

TheLastProject commented Nov 2, 2025

Copy link
Copy Markdown
Member Author

@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

joserebelo commented Nov 24, 2025

Copy link
Copy Markdown
Contributor

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

@TheLastProject
TheLastProject force-pushed the feature/barcodeEncoding branch from 5014a20 to cc176bb Compare December 21, 2025 16:10
@TheLastProject

Copy link
Copy Markdown
Member Author

Thanks for the info @joserebelo. I agree that would be better. Now for me to figure out how I'd go about that, giving it seems to currently directly return a database cursor (and I'm not sure how to override a field in a cursor) 😅

I may have to release a v1 which does it "wrong" or just doesn't expose it just to be able to get this bug fixed, but let's hope I figure something out soon (tips very welcome!)

@joserebelo

Copy link
Copy Markdown
Contributor

@TheLastProject I don't yet have a lot of experience with this, but we might be able to use a CursorWrapper to override specific columns.

I would not block these changes on the ContentProvider - maybe just omit the column from it for now, yes.

@TheLastProject
TheLastProject force-pushed the feature/barcodeEncoding branch 4 times, most recently from 0fd9fa5 to 73d873f Compare December 25, 2025 14:43
- Add new barcodeencoding field to database
- Read barcode encoding from pkpass file
- Add barcodeencoding to import/export
- Add barcodeencoding to share URI
- 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
TheLastProject force-pushed the feature/barcodeEncoding branch from 73d873f to 0c61abf Compare December 25, 2025 15:08
@TheLastProject
TheLastProject marked this pull request as ready for review December 25, 2025 15:08
@TheLastProject
TheLastProject merged commit 59001d4 into main Dec 25, 2025
3 checks passed
@TheLastProject
TheLastProject deleted the feature/barcodeEncoding branch December 25, 2025 15:23
@TheLastProject

Copy link
Copy Markdown
Member Author

Follow-up for Gadgetbridge in #2890. If anyone asks on the Gadgetbridge side why it's not supported, feel free to send them to that issue :)

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