Aztec-Code of pass displayed wrong

[masda-gib]

Hello, I imported a train ticket .pkpass (Deutschlandticket) into the app.
That worked fine and all the textual data is displayed correctly. But the Aztec-code of the pass is displayed wrong. It is way too simple/small.

I will attach:

• a screenshot of the code in your UT app (that's the incorrect code)
  
• a screenshot of the code in an android app "Passes" (here it looks different)
  
• the pass.json file with edited out personal info
  pass_issue.json

If you like I can email you the complete .pkpass file for testing.

It would be awesome if that issue is fixed, the UbPorts and Passes can display my country wide train ticket. :)

[masda-gib]

I read the two Aztec-codes with a code reader (bcTester) and got the following results:

Ut Passes (added whitespaces at front for positioning relative to other code):
          #UT013076AM0130,##B¾#x8#/#³a###Î)Ú^î,N##PËA#Æ##f##µK*Þ4ê#êB#
Android Pass App:
]z3\000001#UT013076AM0130,##B¾#x8#/#³a###Î)Ú^î,N##PËA#Æ##f##µK*Þ4ê#êB#####0436x###÷put1040056607S@##æ#¡#ÎaþF¦#&F#F&#f@e.®.®¡ñ!>##@MÆÆfAÎ!F###¦@la`hl#ä#Xº%f#e'##¤##5#ª³####û¤f&¥æ####!Ä#22s2####!º####»¤###'gä$æ¥#d&g§####é###T#ä##)3#Ç  µ¨8?O#5OÓÀ#È540#)#:#,`###jÐ##f#æ###+ e#6#¡Æ#(b##1#«13######]b#r#±¹{)Ð?#é#eù¹#`#ô@#+$e##¹f`®¡1Ø#c#~c×Ð  #h#!Ä##K###Ðx7#×#C #Ì######Ù-ZtV<9tçÙ#So#Ö#zòâÉ¥SG#ún##à$³}qh#Õå#¬.#Ø¡#Ç##X.§##%#Ö#<#|Ñ#W##Í|yø###B RÃ##;]###&##uëúrry{tÏôõêäæ¬kpJiP»ÛÂhº(l:ëf7ÝËí#<##³L�7L`db###V§l#µzÜa<####Þ##ô

So the code displayed in the Ut Passes app is only a small fraction of the actual data.

[patrickjane]

Its the same issue as #11. I could not yet figure out a solution. Currently I am away for a couple of weeks so I cant investigate this further at the moment.
Will pick it up once I am back.

[Danfro]

Just a guess. The pass shared above is using encoding ISO-8859-1. In line 54 of barcode.cpp UTF-8 is set as encoding.

Another idea was to change the dimensions specified in barcode.cpp to a larger size, but that seems not to affect the size or detail of the code provided above.

[patrickjane]

No, it does not have anything to do with cropping. The generated code is wrong, because the input value for code generation is not interpreted correctly.

The JSON is interpreted as UTF-8 because it shall be UTF-8 according to the specification.
Even if interpreted as iso8859-1, it would not interpret it correctly.

[Danfro]

Ok, then maybe an update of the used libraries might help? 1.0.8 for zxing is quite outdated. And for quazip also a newer version is available?
Although some other things will need to be fixed to make use of them. I just saw errors when trying, but don't understand enough to fix them.

[patrickjane]

I am no expert on character encodings but it is my assumption that the json contains binary data, which is the main problem.

[Danfro]

Hmm, true. When looking at it in an editor, it shows some strange symbols. Applying another encoding doesn't print them nicely either. So yes, likely no encoding issue.

[masda-gib]

Yes, I'm sure the payload data contains binary data. With DB tickets, I read there is a compressed data package encoded in the aztec code.
Sadly I can't find the link again where I had that info from.

Maybe those can help?
https://github.com/rumpeltux/onlineticket/blob/master/onlineticket.py
https://github.com/pbock/ticket-parser?tab=readme-ov-file