David Linke

I just see that the Menu position was fixed in version 1.0.6 of this plugin. Thanks!

[Tudumo](https://www.tudumo.com/) had a nice interface: By ``-clicking multiple tags you got "AND"-filtering and by ``-clicking "OR"-filtering. `` excluded a tag.

Maybe just have the message "Want to contribute to ..." or use a sticky issue at the top of the issue page? See e.g. [mypy](https://github.com/python/mypy/issues).

Out of curiosity I tried to scan the three EAN-13-barcodes above. All were correctly recognized using version 2.1.6. I am writing the value to a string input and the leading...

When I try to read above barcodes with https://scanapp.org I also cannot see the leading zeros. However, in my code that uses version 2.1.6 and reads `decodedText` the leading zeros...

I am not sure I understand what to try: Do you mean to ``` experimentalFeatures: { useBarCodeDetectorIfSupported: true }, ``` to my app/code and see if it "looses" the leading...

With `useBarCodeDetectorIfSupported: true` the barcodes above are not read/detected but with `useBarCodeDetectorIfSupported: flase` they are correctly read. I used version 2.1.6 and 2.2.0 for this test.

I also thought a bit about this: mDegC is the same as 1e-3 * degC which is a multiplication that is forbidden by default. So to be consistent pint should...

If you are using magnitude you are leaving the safety net that pint provides (Maybe [use wrapping instead](https://pint.readthedocs.io/en/latest/performance.html?highlight=magnitude#a-safer-method-wrapping)?). It is a way to bypass unit checks/conversions. I would not call...

The imprecision is a consequence of using floats and how they are represented. Pint does not do anything special. You may use decimal numbers instead. In general, avoid unnecessary back-and-forth...