[MPEG-OTSPEC] Why no GPOS10?

Simon Cozens simon at simon-cozens.org
Sun Aug 2 17:47:10 CEST 2020


By analogy with rsub (GSUB8), if it existed then rpos (GPOS10) would be a contextual positioning rule that applied while advancing backwards through the glyph stream from last to first.

This would allow for moving consecutive nukta marks rightwards while being sure they don’t conflict with other marks to their right.

If that’s unclear (or you’re not convinced this solves a problem that can’t be dealt with other ways) I’ll try and hack up an example and implementation in Harfbuzz.

Simon

> On 2 Aug 2020, at 16:35, Peter Constable <pgcon6 at msn.com> wrote:
> 
> Please describe 'rpos'.
> 
> -----Original Message-----
> From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Simon Cozens
> Sent: Friday, July 31, 2020 11:34 PM
> To: Greg Hitchcock <gregh at microsoft.com>; mpeg-otspec at lists.aau.at
> Subject: Re: [MPEG-OTSPEC] Why no GPOS10?
> 
> Thanks Greg!
> 
> Unfortunately Paul's answer conflates two things about positioning: 
> cursive positioning (GPOS3), which can indeed be done easily front to back, and other GPOS rules including contextual positioning.
> 
> In Linotype's patent for Urdu typesetting, it describes the need for both glyph selection from back to front *and* contextual glyph positioning (for nukta collision avoidance) from back to front. I'm
> (still) surprised that one was implemented and the other was not.
> 
> But then I find that in general people don't tend to do clever things with contextual positioning, because substitution is easier to reason about (and easier to expose in font tools), so maybe it never came up.
> 
> I still think rpos would be useful, but anyway, we are where we are.
> 
> Simon
> 
> 
>> On 01/08/2020 00:13, Greg Hitchcock wrote:
>> Here was a thread from 2003 for context.
>> 
>> GregH
>> 
>> From: Paul Nelson <paulnel at winse.microsoft.com>
>> Sent: Wednesday, September 24, 2003 9:58 PM
>> To: opentype at topica.com; sarmad.hussain at nu.edu.pk
>> Subject: RE: [OpenType] Question about Reverse Chaining Contextual 
>> SIngle Substitution S
>> 
>> Hi Yannis,
>> 
>> I don't know if you got a satisfactory answer. Here is more information.
>> 
>> Urdu shaping is done based on the last character of the jour. A jour is a group of connected letters. The reason that you have not seen many fonts using this lookup is because it is just recently implemented in Uniscribe.
>> 
>> Reverse processing is critical for nastaliq shaping to make sure the thin/thick connections are done correctly. Moving from front to end of the jour would require that a long context be set up to get the shaping correct. And then, of course, one more letter would break the shaping and the jour would not have the correct glyphs.
>> 
>> Cursive attachment (GPOS) is a different subject and can easily be done from front to back.
>> 
>> Paul
>> 
>> -----Original Message-----
>> From: Yannis Haralambous [mailto:yannis.haralambous at enst-bretagne.fr]
>> Sent: Saturday, September 20, 2003 11:48 AM
>> To: Opentype; sarmad.hussain at nu.edu.pk
>> Subject: [OpenType] Question about Reverse Chaining Contextual SIngle 
>> Substitution Subs
>> 
>> There is one thing I don't understand about lookup type 8 of GSUB and Urdu :
>> 
>> it is said in the OpenType specs that in Urdu the shape of a glyph depends on the following glyph. Well this is true in Arabic as well, where each glyph shape depends on the preceding and on the following ones. What makes Urdu special is the fact that one is typesetting on an oblique base line, for each word segment.
>> 
>> For obtaining such an oblique typesetting, one could start by using cursive attachment marks in the GPOS table. But the problem is that typesetting is done in the logical order, so that the first glyph would be at normal position, and all other would get lower and lower.
>> 
>> So it is clear to me that one has to start from the end to get the first glyph at the highest position.
>> 
>> What I don't understand is why the reverse chaining lookup has been implemented for GSUB and not for GPOS. What I have described above is purely positioning.
>> It could be done with cursive attachment marks.
>> 
>> What is wrong in my arguments? Why is only GSUB doing reverse lookups?
>> 
>> And a subsidiary question: how come the Nafees Nastaliq font does *not* use a single time such a reverse chaining subtable? Do you know of any fonts using it?
>> 
>> +--------------------------------------------------------------------+
>> | Yannis Haralambous, Ph.D.      yannis.haralambous at enst-bretagne.fr |
>> | Professor                            https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fomega.enstb.org%2Fyannis&data=02%7C01%7C%7C27c32b04a87a4d03efcc08d835e4f1ca%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637318604704592010&sdata=j3MCdaU70I2MOva8YcK3VjNwdOlhnX1AcoFjeHEz7Ec%3D&reserved=0 |
>> |                                          Tel. +33 (0)2.29.00.14.27 |
>> |                                          Fax  +33 (0)2.29.00.12.82 |
>> | Computer Science Department                                        |
>> | Ecole Nationale Superieure des Telecommunications de Bretagne      |
>> | Technopole de Brest Iroise, CS 83818, 29238 Brest CEDEX 3, France  |
>> +--------------------------------------------------------------------+
>>                          ...pour distinguer l'exterieur d'un aquarium,
>>                                         mieux vaut n'etre pas poisson
>> 
>>                         ...the ball I threw while playing in the park
>>                                        has not yet reached the ground
>> 
>> --
>> OpenType - for technical issues specific to building and using OpenType fonts.
>> 
>> --
>> OpenType - for technical issues specific to building and using OpenType fonts.
>> --^----------------------------------------------------------------
>> 
>> EASY UNSUBSCRIBE click here: 
>> https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftopic
>> a.com%2Fu%2F%3FbUrFCd.bVdsp5.Z3JlZ2hA&data=02%7C01%7C%7C27c32b04a8
>> 7a4d03efcc08d835e4f1ca%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63
>> 7318604704592010&sdata=qAtk0xbVf4L1wIITj3JKMxBRBvWDfzKGFI%2FnyLD2M
>> Fo%3D&reserved=0 Or send an email to: 
>> opentype-unsubscribe at topica.com
>> 
>> TOPICA - Start your own email discussion group. FREE!
>> https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.t
>> opica.com%2Fpartner%2Ftag02%2Fcreate%2Findex2.html&data=02%7C01%7C
>> %7C27c32b04a87a4d03efcc08d835e4f1ca%7C84df9e7fe9f640afb435aaaaaaaaaaaa
>> %7C1%7C0%7C637318604704592010&sdata=Bj4Nve%2BntF5KEPX0M0Xo18U4lST7
>> Lv6%2FdO4LytwVRkA%3D&reserved=0
>> --^----------------------------------------------------------------
>> 
>> -----Original Message-----
>> From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of 
>> Simon Cozens
>> Sent: Friday, July 31, 2020 1:23 PM
>> To: mpeg-otspec at lists.aau.at
>> Subject: [MPEG-OTSPEC] Why no GPOS10?
>> 
>> This is more of a historic rationale question than anything else.
>> 
>> GSUB8 was added in OT1.4, giving reverse chaining substitution ("rsub").
>> But at that time there was no parallel addition of reverse chaining positioning. I presume at the time there was a discussion about it and a good reason why it was not eventually added, but I can't get to any opentype mailing list archives.
>> 
>> I'm quite surprised, because knowing the rationale for why it was added (glyph selection in Urdu), any discussion would probably have also touched on nukta repositioning which has to be done in more or less the same way.
>> 
>> Simon
>> 
> 
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7C%7C27c32b04a87a4d03efcc08d835e4f1ca%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637318604704602003&sdata=zWLke1OmjVYuC8iEwCK9VouJC27LdMFJBqde0XAo84g%3D&reserved=0


More information about the mpeg-otspec mailing list