Closed ChristopherA closed 3 years ago
It's true that we could have saved space by using SHC:
instead of shc:
; we considered this at the time but landed on shc:
after testing app-to-app redirection on Android (see discussion at https://github.com/smart-on-fhir/health-cards/pull/67#discussion_r575607425).
Edit: indeed, behavior should not be affected by case of the URI scheme. Our experience, however, varied :/
For those of you following this, the particular trick the shc:
QR codes use is to segment the QR and encode the segments separately for optimum size. This is not a function available in most QR libraries, but we have ported @nayuki's QR library that does support it to pure swift. https://www.nayuki.io/page/qr-code-generator-libraryhttps://github.com/BlockchainCommons/QRCodeGenerator
Thanks! Consider adding a note at https://github.com/smart-on-fhir/health-cards/wiki/Libraries-for-SMART-Health-Cards#what-are-good-libraries-for-qr-generation if you've used this library for Health Card generation
Great note, thanks @ChristopherA ! The iOS-native CIQRCodeGenerator
has been updated in iOS 15 to do optimal segmentation automatically. It’s not configurable (beyond correction level), however.
If use use lower case
shc:
for the scheme you are drastically increasing the QR code size, as lower case triggers in the QR standard to binary mode and to not use native QR compression.If you instead encourage
SHC:
the QR will be more compact.In particular, verifiers should accept upper case, as RFC 3986 says URL schemed are not case-sensitive: https://datatracker.ietf.org/doc/html/rfc3986#section-3.1
If useful, we have a lot more data about optimizing for more data in QRs, as well as working specs and reference for animated QRs for very large data with fountain codes at https://github.com/BlockchainCommons/research.