[XeTeX] diacritics stacking using anchor points

Michael Maxwell mmaxwell at umd.edu
Mon Oct 25 19:59:31 CEST 2021 

 > I also fixed the stacking_above_AND_below. NewCM will have stellar
 > support for diacritics stacking 😁


You probably know this, but 'stacked diacritics' refers to the stacking 
of diacritics above each other.  Maybe also to one diacritic above and 
one below the base char, but I've only heard it used for the situation 
where you have two or more diacritics above, or two or more below, the 
base char.  In order to stack correctly in this situation, the 
diacritics themselves need to have two anchors, one above and one below.

On 10/25/2021 1:54 PM, Antonis Tsolomitis wrote:
> 
> 
> The problem has been solved (it seems). The problem was not the Class 
> value as
> I hand edited the ttx file, reconstructed the otf but again did not work.
> 
> I deleted the anchors of this glyph, recreated them (exactly the same) 
> and then
> as a miracle everything worked.
> 
> This explains why nobody answered me when I asked the fontforge list 
> yesterday.
> It looks like a bug of fontforge to me.
> 
> I also fixed the stacking_above_AND_below. NewCM will have stellar support
> for diacritics stacking 😁
> 
> Thanks for your time, help and xetex support for stacking,
> 
> cheers,
> 
> Antonis.
> 
> 
> 
> 
> 
> 
> On 10/23/21 11:11 PM, Jonathan Kew wrote:
>> On 23/10/2021 16:48, Antonis Tsolomitis wrote:
>>>
>>> Thanks for the answer.
>>>
>>> Yes acute works. But where do you see the difference? I am looking 
>>> the dialogs of
>>> fontforge and can not locate the difference.
>>>
>>> I have more trouble with diacritics stacking especially when stacking 
>>> above AND below.
>>> x́ (x+ U+0301) works
>>> x̖ (x + U+0316) works as well, but
>>> x̖́ (x+ U+0301 + U+0316) fails.
>>>
>>>
>>> I have been trying to resolve these issues for a long time but 
>>> without luck. The fontforge
>>> dialogs show correct stacking but xetex does not stack as expected an 
>>> I have routinely failed
>>> to find the reasons.
>>>
>>> So at which dialogs do you see the difference between U+0301 and 
>>> U+0300 ?
>>> And why simultaneous stack above and below fails?
>>>
>>
>> I haven't looked at FontForge dialogs; I used TTX (from the FontTools 
>> package) to look at an XML dump of the .otf file, and noticed that for 
>> the uni0300 glyph, the mark-to-base lookup has an attachment point 
>> with class=1:
>>
>>             <MarkRecord index="9">
>>               <Class value="1"/>
>>               <MarkAnchor Format="1">
>>                 <XCoordinate value="218"/>
>>                 <YCoordinate value="516"/>
>>               </MarkAnchor>
>>             </MarkRecord>
>>
>> whereas for uni0301 and other diacritics that should attach to the 
>> "above" anchor of the base, the attachment has class=3:
>>
>>             <MarkRecord index="10">
>>               <Class value="3"/>
>>               <MarkAnchor Format="1">
>>                 <XCoordinate value="284"/>
>>                 <YCoordinate value="522"/>
>>               </MarkAnchor>
>>             </MarkRecord>
>>
>> In the associated BaseArray, glyphs like uni2C9B appear to have only 
>> anchors 3 (above) and 4 (below) defined:
>>
>>             <BaseRecord index="876">
>>               <BaseAnchor index="0" empty="1"/>
>>               <BaseAnchor index="1" empty="1"/>
>>               <BaseAnchor index="2" empty="1"/>
>>               <BaseAnchor index="3" Format="1">
>>                 <XCoordinate value="272"/>
>>                 <YCoordinate value="453"/>
>>               </BaseAnchor>
>>               <BaseAnchor index="4" Format="1">
>>                 <XCoordinate value="296"/>
>>                 <YCoordinate value="-20"/>
>>               </BaseAnchor>
>>               <BaseAnchor index="5" empty="1"/>
>>               <BaseAnchor index="6" empty="1"/>
>>             </BaseRecord>
>>
>> so I'm assuming that's why uni0300 fails to attach.
>>
>> I don't know exactly how this is exposed in the FontForge interface, 
>> sorry....
>>
>> As for combinations with above + below, you may need investigate mark 
>> classes, and ensure that MarkToBase lookups for the "above" and 
>> "below" classes are each set to ignore the other class of marks. So if 
>> you have <x + U+0301 + U+0316>, the lookup that wants to handle <x + 
>> uni0316> needs to *ignore* the uni0301 glyph that appears in between. 
>> This is done using mark classes; see the documentation of the 
>> MarkToBase lookup in 
>> https://docs.microsoft.com/en-gb/typography/opentype/spec/gpos.
>>
>> Hope this helps -- sorry I don't know details of how to control all 
>> this from FontForge, but I'm sure it has the capabilities somewhere...
>>
>> JK
>>
>>> Thanks for your help,
>>>
>>> Antonis.
>>>
>>>
>>>
>>>
>>>
>>> On 10/23/21 6:26 PM, Jonathan Kew wrote:
>>>> On 23/10/2021 14:37, Antonis Tsolomitis wrote:
>>>>>
>>>>> It is a long time now that NewComputerModern has build-in 
>>>>> information for diacritics stacking.
>>>>> I have heard  that xetex supports this but I can not make it work. 
>>>>> The font is developed
>>>>> with fontforge and as you can see in the attached screenshot, 
>>>>> fontforge shows stacking working.
>>>>>
>>>>> However xelatex just places, say the grave (uni0300) next and not 
>>>>> above the character, say uni2C9B
>>>>> (as in screenshot).
>>>>>
>>>>> So I guess I have something wrong in the font that xetex does not 
>>>>> like(?)
>>>>
>>>>
>>>> Do any other diacritics such as the acute (U+0301) or dieresis 
>>>> (U+0308) work? From a quick look at the GPOS table in the font -- if 
>>>> I'm reading it correctly -- it appears that uni0300 may have the 
>>>> wrong attachment point class (whereas in uni0301 and uni0308, it 
>>>> looks correct).
>>>>
>>>> JK
>>>>
>>>>
>>>>
>>>>>
>>>>> The font currently develops the coptic block for academic needs 
>>>>> this is why I use uni2C9B.
>>>>>
>>>>> A sample file is
>>>>>
>>>>> \documentclass{article}
>>>>> \usepackage{fontspec}
>>>>> \setmainfont{NewCM10-Regular.otf}
>>>>> \begin{document}
>>>>> ⲛ̀
>>>>> \end{document}
>>>>>
>>>>> However the font that contains this character (since it is under 
>>>>> development) is here:
>>>>> https://myria.math.aegean.gr/~atsol/tmp/NewCM10-Regular.sfd 
>>>>> <https://myria.math.aegean.gr/~atsol/tmp/NewCM10-Regular.sfd>
>>>>> https://myria.math.aegean.gr/~atsol/tmp/NewCM10-Regular.otf 
>>>>> <https://myria.math.aegean.gr/~atsol/tmp/NewCM10-Regular.otf>
>>>>>
>>>>> thanks for any help,
>>>>>
>>>>> Antonis.
>>>>>
>>>>
>>>
>>
> 

--
     Mike Maxwell
     "Digital objects last forever--or five years,
     whichever comes first."  --Jeff Rothenberg

More information about the XeTeX mailing list.