<div dir="auto">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”. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Of course type designers might want to refine this, but as a general rule, just one value works surprisingly well.</div><div dir="auto"><br></div><div dir="auto">A.</div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 17 Sep 2020 at 10:26, David Lemon <<a href="mailto:typenerd@mindspring.com">typenerd@mindspring.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">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...<br><br>David Lemon<br><br><br><br><br><br>-----Original Message-----<br><br>>From: Laurence Penney <<a href="mailto:lorp@lorp.org" target="_blank">lorp@lorp.org</a>><br><br>>Sent: Sep 16, 2020 2:03 PM<br><br>>To: "MPEG OT Spec list (<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a>)" <<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a>><br><br>>Subject: Re: [MPEG-OTSPEC] 'opbd' feature<br><br>><br><br>>> On 17 Sep 2020, at 00:21, John Hudson <<a href="mailto:john@tiro.ca" target="_blank">john@tiro.ca</a>> wrote:<br><br>>> <br><br>>> 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<br><br>><br><br>>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.<br><br>><br><br>>- Laurence<br><br>><br><br>>_______________________________________________<br><br>>mpeg-otspec mailing list<br><br>><a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br><br>><a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br><br>_______________________________________________<br><br>mpeg-otspec mailing list<br><br><a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br><br><a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br><br></blockquote></div></div>