[MPEG-OTSPEC] SHORT vs int16 vs ???

[Peter Constable]

Those changes were not made unilaterally. Behdad and others reviewed these changes before OT1.8.1 was published; Behdad suggested the type names could make big-endian explicit, but considered it “bikeshedding”. Without any further input, it was left as we see now.


Peter

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Dave Crossland
Sent: Friday, August 14, 2020 1:19 PM
To: Behdad Esfahbod <behdad at behdad.org>
Cc: mpeg-otspec <mpeg-otspec at lists.aau.at>
Subject: [MPEG-OTSPEC] SHORT vs int16 vs ???



On Fri, Aug 14, 2020 at 1:36 PM Behdad Esfahbod <behdad at behdad.org<mailto:behdad at behdad.org>> wrote:
On Fri, Aug 14, 2020 at 7:40 AM Eric Muller <eric.muller at efele.net<mailto:eric.muller at efele.net>> wrote:
At the same time, the names of structures in OpenType tables end up in code, documentation, tools' UI, discussions on this list, our heads, etc.. Changing them every two months is not going to help. I would prefer such changes to occur infrequently, may be accumulating them in a backlog in the mean time.

Not just that: Peter's unilateral renaming was a disservice to the specification: he replaced the obscure-looking "SHORT", "USHORT", "LONG", "ULONG", with common words "int16", "uint16", "int32", "uint32", even though those do not match the similarly-named types in computers and languages, because the OpenType ones are always big-endian.  If he had consulted others, we could have reached a universally-unambiguous and clear names.

What alternatives do you propose, Behdad, Peter, Eric, anyone? :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200814/0d9372ed/attachment-0001.html>