patrickjane / ut-passes

Access .pkpass passes on Ubuntu Touch
MIT License
4 stars 4 forks source link

Aztec-Code of pass displayed wrong #12

Open masda-gib opened 3 months ago

masda-gib commented 3 months ago

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:

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 commented 3 months ago

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ÝËí#<##³L7L`db###V§l#µzÜa<####Þ##ô

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

patrickjane commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

Danfro commented 3 months ago

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 commented 3 months ago

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