Wibblings about version numbers

diff --git a/NOTES b/NOTES
index 006329438230323a99f051f559c81dd80de09361..7dce48468023759b3dfb1e1d57066a4be2b7d069 100644 (file)
--- a/NOTES
+++ b/NOTES
@@ -200,3 +200,34 @@ Not sure if these are a good idea, but they're fun:
 #define XML_IF (test, inner) \
        XML_FOR_I (bool _done = false, !_done && (test), _done=true, inner)
 #define XML (elem) XML_IF(true, elem)
+
+Version numbers
+===============
+
+Up until version 002.009, Bedstead's version numbers took the form of
+two dot-separated three-digit numbers with leading zeroes.
+
+The example fonts in "Adobe Type 1 Font Format" (version 1.1) have
+version numbers like "001.003".  The PostScript Language Reference
+Manual (3rd edition) places no requirements on font versions as stored
+in the "version" entry of the FontInfo dictionary.
+
+The "%%Version" comment in DSC 3.0 takes a <real> followed by a
+<uint>.  <real> is defined broadly, and includes "-.002", "34.5",
+"-3.62", "123.6e10", "1E-5", "-1.", and "0.0".
+
+OpenType 'head' field "version" is a 16.16 fixed-point binary number.
+This is recommended to be rounded and padded to three decimal places
+for display.  OpenType 'name' ID 5 is required to contain two numbers,
+at most 65535 each, separated by a dot.  It's recommended that this
+come just after "Version " at the start.
+
+dpkg (like many other things) thinks a version number consists of dot
+separated integers.  It treats "002.009" as equal to "2.9", but "1.3"
+as different from "1.300".
+
+So I think version numbers of the form "3.141" are sensible.  Losing
+the leading zeroes and having three decimal places means they can be
+formatted correctly from the 'head' table.  Not having leading or
+trailing zeroes in the fractional part means that they can't be
+suppressed by anything that might try to canonicalise version numbers.