Open askdkc opened 5 months ago
Attention: Patch coverage is 0%
with 1 lines
in your changes are missing coverage. Please review.
:exclamation: No coverage uploaded for pull request base (
main@c01758c
). Click here to learn what that means.
Files | Patch % | Lines |
---|---|---|
src/Encoder/Encoder.php | 0.00% | 1 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I'm not a big fan of this – the kanji mode exists specifically to massively reduce the amount of storage required for that.
Looking at the original zxing code I noticed that they subtract 1 from the length to make it uneven, which we don't do.
Could you test locally if that makes a difference for your result?
I also tried to generate the same QR code with ZXing, which yielded a valid QR code, so there must be some bug in Bacon, but I can't tell, which.
@DASPRiD
I tested your suggestion but unfortunately the result is still unreadable QR code.
I also tried to generate the same QR code with ZXing, which yielded a valid QR code, so there must be some bug in Bacon, but I can't tell, which.
@DASPRiD
Could you test with "あいうえお" not "あいうえお123"?
You can open the link yourself :)
You can open the link yourself :)
My bad😅 (I thought you are testing it in locally.)
It works with "あいうえお" in ZXing. So yeah, I think something wrong with Bacon but I'm not sure what is.
I'd recommend to poke around and compare the code paths for kanji between Bacon and ZXing, it might be some very small knob.
This PR is fix for the issue #172