Upstream: Patch .ttf/.vfb/.cfg licence information

I'll ack Paul's description of the versioning and ask that the package
and font versions be brought into line.

Mark

The Truetype specifcation has version numbers in two main places:

  1. 'name' table, entry nameID=5, string, in the form "^Version [0-9]{1,5}\.[0-9]{1,5}([^0-9].*)?$"
  2. 'head' table, fixed point fraction 16-bits.16-bits

Both locations allow any version number in the range 0-65,535 point 0-65,535. With the string name being a free-form string beyond that. The example given by MS in the OpenType specification for the field is:

  "Version 1.00 June 1, 1990, initial release"
  http://www.microsoft.com/typography/otspec/name.htm

Which demonstrates the intent that strings be longer than a simple Major.Minor. Running the following test over the fonts already on my current system:

  dpkg -S .ttf | cut -d\ -f2 | xargs strings | grep Version | grep [0-9]\\.[0-9]*\\.[0-9]* | sort | uniq

shows several version numbers that are compliant with the Truetype specification and which are similar or identical to the intended format proposed and introduced at the top of this bug report (Major.Minor.Sub.Increment)

 Version 0.730.4 2008
 Version 2.4.3
 Version 2.4.4

The question is therefore /not/ how or if to set the Version field (eg. "Version 0.6.7", or "Version 0.6.7.1" for a re-spin), but /what/ to do about aligning this comparatively verbose field with the fixed-point fraction provided in the 'head' table. Currently Microsoft general operating system and utilities appear to use the Version string. Apple's documentation for the fixed-point fontRevision merely states "set by font manufacturer", so it's entirely possible that the fraction could be /anything arbitrary/. Currently the fractional component has been set to by Font Lab to 0xab85 (~0.6700 decimal).

Microsoft hints at (their apparent understanding of) obsoleteness for the binary fraction from the 'head':

  http://www.microsoft.com/typography/otspec/head.htm
  "For historical reasons, the fontRevision value contained in this table is not used by Windows to determine the version of a font. Instead, Windows evaluates the version string (id 5) in the 'name' table. "

FontConfig (the matching and substitution system used on Linux and Ubuntu) appears to cache the value of the fractional from the head, but doesn't parse it, merely evaluating that it is not equal to zero (ie. not set/not present) and ignoring it if it is:

  head->Font_Revision != 0 // value cached (but not parsed) is non-zero
  TT_NAME_ID_VERSION_STRING // not evaluated
  TT_NAME_ID_UNIQUE_ID // commented out, not evaluated

Testing: setting the Version (nameid=5) and Unique ID (nameid=3) string to contain "0.6.7" (or even "0.6.7.1") both work fine and the implementation in FontForge picks a fractional representation of 0xaaaa when offered '0.67' (as compared to 0xab85), which probably illustrates the arbitrariness of the field.

Mark: your call. The numbering scheme (documented in the other shared document and, I believe, codified here) will only be present in the Version and Unique ID (string field), with something simpler in the binary form. Dalton Maag's concerns are that these should be interchangable... ie. about not putting more verbose data in the Version string (nameid=5) that can be included in the fractional h...

We actually have no objection to the verbosity of a Version string in the format "Version 0.6.7.1", but this naturally leads to the issue that the binary representation would have to be something different - 0.6, 0.671, etc. and this raises two technical problems:

* Despite the limitations of the binary format, Microsoft does issue guidance in the OT spec on how it should be interpreted, so there is the risk that the font would report a different version information to the user depending on how the OS/application fetches it.
* If we choose 0.6 as the binary representation, it would then be unwise to issue any future 0.6.x.x numbered fonts as there's the possibility of version confusion.

A possible way forward which avoids both of these would be, in the case of 0.6.7.1:
Binary representation: 0.671
Version string: "Version 0.671 (0.6.7.1)"

This would be to-spec, robust, consistent, unambiguous, and I think clear to users and maintainers.

Posting David Marshall's reply here for clarity:

It's probably worth me listing all of the options, and we can just pick
one to go with:

  A: "Version 0.6.7.1" -> Binary: 0.6
      Will validate. Possible issue with multiple releases being labelled 0.6 in the binary field, possible user-confusion.
  B: "Version 0.6.7.1" -> Binary: 0.671
      Won't validate.
  C: "Version 0.671 (0.6.7.1)" -> Binary: 0.671
      Will validate. Decimal place issues.

I don't regard any of these as "good". B is unacceptable, A and C are
acceptable but have different reporting and future-proofing problems.

Please advise which you prefer and we'll implement it.

Regards
David Marshall
Dalton Maag Ltd

 On 14/09/10 18:46, David Marshall wrote:
> A possible way forward which avoids both of these would be, in the case of 0.6.7.1:
> Binary representation: 0.671
> Version string: "Version 0.671 (0.6.7.1)"
>

Sortability seems a problem with this proposal:

 0.671 ... <?> 0.7?

If you think of the "minor" number as just a number, 671 is definitely
greater than 7. So we'd need to do 0.700 which is just weird.

Mark

The jumping straight up to a number that is about two-thirds is purely for intuitiveness of users and to give a proportionate demonstration of our believe in the overall status (eg. political rather than technical). Whether or not it was a good thing is do is somewhat by-the-by.

I've had discussions with Colin Watson (who often has clear insight in such matters) and Keith Packard (FontConfig). One issue (as noted by Mark) is that the software versioning that we're used―and which is documented in great detail in the Debian Policy Manual:

  http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

"goes up to eleven" per component. The version numbers are not purely a strict concatenation of the digits, with each component being compared based on its own numerical merit. If one needs more than nine-revisions then you go to ten, eleven, twelve and these are evaluated as being numerically higher:

  ...x.1.y... < ...x.9.y... < ...x.10.y...

despite ten and one both beginning with a '1' and nine with a '9'.

Colin's thoughts leaned towards using a strict, subset for encoding the preferred version into the available fractional codespace and *documenting* this in the developer readme such that there are bounds (effectively, we agree not to go above nine, and any increase requires a bump of the next digit up) ...and that Canonical agree to bump the minor (.6) as the next decimal is exhausted. This gives ~33 releases until next summer and retagging as 1.000; There is a third digit if we really get desperate: ~338.

Keith noted that the 32-bit (16+16-bit) version is treated as a simple comparison, and only in the case of a collision is the comparison any use (this is at odds with non-Linux operating systems, which appear to be using the string version). His suggestion was for an 8.8.8.8 encoding across the bits, the actual /encoding/ being somewhat arbitrary―and as we have noted, it already varies between implementations. He further stressed that that the packaging system takes care of removing those version conflicts in the first place by other having the latest packaged version installed. The disadvantage is that applications are already setup to do a 1/65,535 encoding for the fraction.

I (still) don't yet have a clear answer distilled in my head, but yes David, I concur with you that version C is possibly the least-worst of a bad bunch, given the options and a desire to validate against whatever piece of software it is on your side that is complaining.

Given a free choice (B) might be my preferred desire; the textually formatted version number (suitably restricted as Colin suggested, to numerical values 0-9 per component) is there in its original simple glory, and is what the user sees; and the binary /encoding/ (transformation) of this stored in the 'head' also fulfils the criteria of monotonically incrementing. An encoding that was only capable of perpetually inserting 0.6, or 0.7, or 0.8 into the binary field would fail the criteria to monotonically increment.

(We can add some regression testing code to validate that the binary head->fontRevision is indeed incrementing).

Yes, sortability is an issue in option C. The OT spec is clear that 0.7 = 0.70 = 0.700 but that's of course not the same for other contexts.

We hit the same problem with sortability in the other direction with option A, where OT would regard 0.7 and 0.70 as the same version.

I think we're all gravitating towards option A being the best compromise, despite these caveats.

Dave

What about treating major and minor as 0-99, so:

 0.67
 0.68
 1.01
 1.02

We'd encode the minors as "01", "02", ... "67" ... "99" and the majors
as "1, 2, 3..."

Mark

Paul I think has squarely ruled out option A there, but also I think opened the door on having OT-specific version numbers derived from but in an obviously different format to the real version number.

Using the full 32-bits is nice, but given the rounding to three decimal places for the string equivalent, we're going to lose bits at the far end.

If we could limit it to no component of the version number going higher than 99, we end up with the accurate, if bizarre:

"Version 70.601 (0.7.6.1)"

We'll call this Option D.

Dave

Yes, I think we're getting cleverer by far, but in danger of getting progressively weirder (Baldrick, "I have a cunning plan").

So going back, if we've already restricted ourselves to 0-9 per component and we accept that, we're pretty much at:

   Option E: 0.67, 0.68, 0.69, 0.70, ... 0.99, 1.00, 1.01. (Mark, comment #8)

or the same with three digits:

   Option F: 0.671, 0.672, 0.700, 0.710, ...

And only the major is special (and at Canonical's threshold for quality/metrics stability going forward). Two digits is what we've got at the moment; and we can adjust the in-vision glyphs in the PUA to match, and align the documentation. Version string is a straight forward writing out of the number X.YY with a perpended zero, which also meets the Debian versioning requirements. Both of these go verbatium in the string (with relevant zeros) and both /sort/ in the binary fraction correctly, even if they might not display with suffixed zeros.

The "clarification" is then that we make the documentation match the product and codify the methodology and reasoning in a readme: much like the versioning of the Ubuntu (operating system, eg. 10.04) the zeros are important when written but we can still reduce the number of them if we go with (E).

I'm happy with limiting all components to a single digit, having three decimal places, and insisting that trailing zeroes are significant.

Which I think means I vote for option F.

If I'm understanding correctly, this would make the current version 0.671. We could still add the correct format version in the Version string as in option D: "Version 0.671 (0.6.7.1)".

Dave

If we went for three digits, I think we'd re-spin with a string of solely:

  "Version 0.671"

and if we went for two digits, we'd re-spin with a string of solely:

  "Version 0.68"

consolidating all the rest of the components down to just a Major and a Minor (and no parentheses).

OK. I'd go for three digits as it gives us more scope for precision. So the in-flight version will be 0.671.

Dave

Dave: we got overruled. Mark says two digits, so tomorrow's spin at "Version 0.68". We'll have another low-delta spin shortly after that when the licensing situation gets finalised. I'll update you as I know more.

OK, 0.68 is fine. Hopefully we don't run out of numbers before we reach 1.00. :)

Dave

Sorry, didn't mean to overrule anyone, I just thought two digits were
less anorak than three, and still give us nearly two years of weekly
point releases between major versions if we need 'em :-)

Mark

:)

ubuntu-font-family-sources (0.68+ufl-0ubuntu1) maverick; urgency=low

  * New upstream release 0.68+ufl: (LP: #629622, #633508)
    - Libre font, licensed under the Ubuntu Font Licence 1.0 (LP: #632411)

  * New upstream release 0.68:
    - All
      + Version numbering agreed (LP: #633176, #629727)
      + The glyph at Unicode x1F5d was changed in all fonts, i.e. change
        of commaaccent in Greek glyph
      + Updated OS/2 table Strikethrough and 'post' table underline
        values to match thickness of underscore.
    - Italic / Bold Italic
      + The feminineordinal in the Italic now follows the design of
        the a, it has been updated and hinted.

  * New upstream release 0.67:
    - All
      + Version number forwarded to 0.67
    - Regular
      + Hinting adjustments for 15 - 18 ppm
      + Greek glyph uni1F5D has accent corrected.
      + Hinting amends for lowercase v, w and y in sizes 30 - 42
      + hdmx table include 120dpi ranges (LP: #608823)
      + Hinting amended to adjust for Freetype hint
        implementation. (LP: #614693)
    - Italic
      + Greek glyph uni1F5D has accent corrected.
    - Italic / Bold Italic:
      + lowercase f redesigned. (LP: #623925)
      + ae dipthong redesigned. (LP: #621157)

 -- Paul Sladen <email address hidden> Tue, 28 Sep 2010 06:00:00 +0100