Repository navigation
Potentially support platform-specific formats in BarcodeFormat enum #66
Description
Currently, the specification provides "unknown" as a valid BarcodeFormat [1]. However, it doesn't make sense for a user to hint "unknown" in a BarcodeDetectorOptions, and returning "unknown" in getSupportedFormats doesn't (currently) make sense either.
One possibility proposed by @reillyeon is to convert "unknown" to "platform-specific", i.e. encompassing platform-supported formats unknown to the spec.
This could be passed back to the user, in getSupportedFormats or elsewhere, to indicate the platform supports more formats than expressed in the spec, and could be used by the user to include platform-specific formats in the hint in addition to spec-known formats.
[1] https://wicg.github.io/shape-detection-api/#dom-barcodeformat-unknown
Activity
yell0wd0g commentedon Mar 29, 2019
I guess it all stems because
BarcodeFormatis used both ingetSupportedFormats()returnedsequenceandDetectedBarcode.format, where it makes sense to find an "unknown" but is also used in the settings dictionaryBarcodeDetectorOptions, where it doesn't. Perhaps we could split it into two dictionaries, one with and one without theunknown.reillyeon commentedon Mar 29, 2019
My argument against
"unknown"is also that it doesn't make sense that the API has detected an "unknown" barcode format because if the format is unknown then how was it detected? Even in the case ofDetectedBarcode.formatusing"platform-specific"as the enum value would instead indicate simply that the format is one that is specific to the current native platform.