[MPEG-OTSPEC] 'opbd' feature
David Lemon
typenerd at mindspring.com
Thu Sep 17 10:26:03 CEST 2020
Wow. We spec'd 'oped' two decades ago hoping it could get used, and that reasonable tools would be created to assign values. Nothing happened (AFAIK) for 20 years. Now, under the threat of getting rid of this good but unused idea, some cool proposals for actually doing something with it crop up. Not complaining, but maybe we should have deprecated it 15 years ago...
David Lemon
-----Original Message-----
>From: Laurence Penney <lorp at lorp.org>
>Sent: Sep 16, 2020 2:03 PM
>To: "MPEG OT Spec list (mpeg-otspec at lists.aau.at)" <mpeg-otspec at lists.aau.at>
>Subject: Re: [MPEG-OTSPEC] 'opbd' feature
>
>> On 17 Sep 2020, at 00:21, John Hudson <john at tiro.ca> wrote:
>>
>> Because of the amount of work involved in defining lfbd and rtbd GPOS lookups (and the current lack of any very convenient visual editing tool), I don't imagine it being something a lot of font makers would do for a lot of fonts
>
>IMO it would be worth exploring the radical idea that a glyph’s left and right boundaries become the *standard* horizontal type design metrics (just as we think of alignment to vertical metrics, with overshoot etc.). There would be separate specification of padding-left and padding-right (usually equal) which would be consistent across the font (but varying according to wdth, opsz etc.). On export, the type design app would pad every glyph so that the font is spaced normally. The app would also add suitable lfbd/rtbd GPOS lookups, of course.
>
>- Laurence
>
>_______________________________________________
>mpeg-otspec mailing list
>mpeg-otspec at lists.aau.at
>https://lists.aau.at/mailman/listinfo/mpeg-otspec
More information about the mpeg-otspec
mailing list