[mpeg-OTspec] version string issues

[Denis Jacquerye]

Wouldn’t this make some existing fonts invalid?
Some fonts (including recent ones) have head.revision value that has
nothing to do with the version string’s number in the name table.

There is no explicit relation between the two values in the specs.

Wouldn’t this be better as a recommendation? It would also have to work
with the current 'head' table recommendation:

'head' table
Although historical usage of the fontRevision value is varied, the
recommended use of the field is to set it as a Fixed 16.16 value, and to
report it rounded and zero-padded to three fractional decimal places.
Examples: Decimal 1.5 is set as 0x00018000 and is reported as "1.500";
decimal 1.001 is set as 0x00010041 and is reported as "1.001". All data
required. If the font has been compressed with Microtype Express
compression defined in ISO/IEC 14496-18 this must be indicated in the flags
field of the 'head' table.

On Fri, 11 Sep 2015 at 02:43 Martin Hosken martin_hosken at sil.org
[mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com> wrote:

>
>
> Dear All,
>
> I sent this message a while back, but since the list doesn't send back my
> messages to me, I don't know if it hasn't arrived. My apologies if you've
> seen this before.
>
> I've been looking at the version string in the name table and this is what
> it says:
>
> Version string. Should begin with the syntax 'Version <number>.<number>'
> (upper case, lower case, or mixed, with a space between “Version” and the
> number).
> The string must contain a version number of the following form: one or
> more digits (0-9) of value less than 65,535, followed by a period, followed
> by one or more digits of value less than 65,535. Any character other than a
> digit will terminate the minor number. A character such as “;” is helpful
> to separate different pieces of version information.
> The first such match in the string can be used by installation software to
> compare font versions. Note that some installers may require the string to
> start with “Version ”, followed by a version number as above.
>
> My assumption is that the aim here is to turn a 16.16 fixed point number
> as used in the head table into a string floating point representation. If
> this is the case then I don't think the above text meets the need. First of
> all consider the two numbers 0.10001 and 0.10002. These end up with the
> same 16.16 representation (0000199A). So I don't think the 65536 can
> represent the accuracy of the 16.16. Alternatively, what if we say that the
> 65536 just gets mapped as a number? Then, for example, 1.5 would map to
> 00010005, which is the floating point number 1.00009155. Which is not what
> we want. The only other alternative is to use Binary Coded Decimal but that
> can't handle more than 4 digits, so anything over 10000 is out. Therefore I
> suggest that the description here is wrong and we need something better.
>
> What I think we want is some way to turn a 16.16 into what looks like a
> floating point number in decimal. While we could strive for purity and the
> full code space, we would end up with some pretty crazy numbers as per the
> example above of 1.000091552734375. Instead, I would like to suggest that a
> 16.16 can accurately represent a decimal floating point number with up to
> and including 4 decimal places and that we just go with that. Anything more
> and we risk all kinds of rounding problems. Thus we can store 1.1001 but
> not 1.10011 and so on. For those interested in the maths, I propose the
> following functions to do the conversion:
>
> def asfixed(x : float) : return int(x * 65536)
> def asfloat(x : int) : return float(int(float(x+1)/65536*10000))/10000
>
> asfixed takes a floating point number with 1-4 decimal places, and asfloat
> takes a 32-bit number representing a 16.16 number and returns a floating
> point number with 0-4 decimal places (you'll have to sort out the .0
> yourself!). The x+1 in the asfloat() sorts out any rounding issues given
> that all version numbers are positive and int() rounds down. For example
> asfixed(1.21) is 0x000135C2 whereas 0x000135C1 represents 1.2099.
>
> I propose the following wording to replace the text in the standard:
>
> Version string. Should being with the syntax 'Version <number>' (upper
> case, lower case or mixed, with a space between "Version" and the number).
> The string must contain a version number that is a decimal less than 32768
> that has 1-4 decimal places. Any character other than a digit will
> terminate the number. A character such as ";" is helpful to separate
> different pieces of version information.
> The first such match in the string can be used by installation software to
> compare font versions. Note that some installers may require the string to
> start with “Version ”, followed by a version number as above.
> The correspondance between the version number and the corresponding
> version number in the head table, is that the head version = int(number *
> 65536) and the number = float(int(float(head version + 1)/65536 *
> 10000))/10000
>
> Yours,
> Martin Hosken
>
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20150911/f904430e/attachment.html>