[MPEG-OTSPEC] 'opbd' feature

[Adam Twardoch (Lists)]

I think that either LuaTeX or XeTeX support optical bounds, but I think
they b just call the lfbd & rtbd directly. I never got the idea how one
would implement opbd as this “meta feature”.

It’s worth noting that both Lorp & Yuri pointed out to me that designing
lfbd/rtbd is not so complex: in most alphabetic scripts, you basically get
the LSB/RSB of a flat glyph like H/n (ignoring serifs), and you subtract
that very value uniformly from the LSB/RSB of all glyphs. In a sense, this
is like tracking, which is also typically uniform.

The results are surprisingly good with fonts that are spaced in the typical
way — when you subtract the LSB of H from the LSB of O, A, V etc., the left
bounds of those glyphs will protrude just the right amount.

Of course type designers might want to refine this, but as a general rule,
just one value works surprisingly well.

A.



On Thu, 17 Sep 2020 at 10:26, David Lemon <typenerd at mindspring.com> wrote:

> 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
>
> _______________________________________________
>
> mpeg-otspec mailing list
>
> mpeg-otspec at lists.aau.at
>
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200917/0679c157/attachment.html>