RFC: Storing units of measurement in SI

[ja573]

Before #259 we stored and output book dimensions in millimetres only. We solved #259 by implementing a conversion mechanism that allowed us to (1) keep storing dimensions in millimetres; (2) allow users to input dimensions in SI and imperial units; and (3) allow outputting dimensions in SI and imperial units. Inputting dimensions in inches, storing them in millimetres and outputting them back in inches causes rounding errors, as reported in #300. However we choose to solve this issue should also be implemented in #341.

US-based publishers work with inches and ounces and need to be able to output measurements in these units. However, bibliographic best practices suggest that imperial units should be used in addition to SI units: EDItEUR recommends to “use metric measurements” and “[a]dditionally, repeat the same measurements using imperial units” ¹ and International Standard Bibliographic Description (ISBD) states that “dimensions [...] are expressed in terms of centimetres” ².

Since the canonical unit of measurement should be in SI, and optionally output in imperial too, the proposal is to keep storing dimensions in SI, allow inputting only in SI, and allow outputting in both SI and Imperial. Publishers that work primarily in Imperial would input measurements in SI and see the resulting, read-only, Imperial conversion alongside so they could ensure that rounding is performed to their taste.

Footnotes

1. https://www.editeur.org/files/ONIX%203/APPNOTE%20Weights%20and%20dimensions%20in%20ONIX.pdf ↩

2. https://archive.ifla.org/VII/s13/pubs/isbd_m0602.pdf ↩

[vincentwj]

Despite ISBD and other international standards, imperial measurements are standard across US book printing industry. Native inputting and storing in imperial should be possible, since inputting those data in SI will lead to rounding errors. Not including this feature will be offputting to any publishers wanting to adopt Thoth from the US.

Input and storage should be allowed in both SI and Imperial since there is no conversion that will not lead to rounding errors.

[ja573]

Actually, we've discussed this further and decided to do: #300 (comment)