Re: [XeTeX] combine 2 glyphs with xelatex
What you ask is easy, at least with NewComputerModern fonts.
For this task you just need to disable the Script. It is the Script
that puts the dotted circle not the font or xelatex.
Now since what you want is not supported by the Script for Devanagari
you may need some horizontal adjustment with \kern as below:
\documentclass{article}
\usepackage{fontspec}
\newfontfamily{\noscriptdevanagari}{NewCM10Devanagari-Regular.otf}
\begin{document}
{\noscriptdevanagari
\symbol{"093D}\kern-1pt\symbol{"0947}
}
\end{document}
Antonis.
On Mon, 2024-03-11 at 10:40 +0100, Zdenek Wagner wrote:
> I'm afraid not or at least not easily. The matras are present in the
> font without the dotted circle but the circle is present in the font
> as a glyph which is inserted by the shaping engine if matra is used
> without the consonant. Thus the solution suggested by John Waś will
> not work because you will still get the dotted circle meaning that
> the
> consonant is missing. You must somehow force the shaping to think
> that
> the consonant is here or find a font where the dotted circle is
> missing. I am not a font expert thus I do not know how to do it.
>
> Zdeněk Wagner
> https://www.zdenek-wagner.eu/
>
> po 11. 3. 2024 v 10:00 odesílatel François Patte
> napsal:
> >
> > Le 2024-03-11 00:11, Zdenek Wagner a écrit :
> > > Bonjour
> > >
> > > avagraha is an independent vowel thus it IMHO cannot be combined
> > > with
> > > a matra but it works fine with consonants, try this:
> >
> > Thank you for this answer. I would like to reproduce the sign used
> > to
> > note a pluta in devanagari text (I attach an image in yellow color)
> > and
> > the solution I wanted to create for this purpose would have been a
> > good
> > solution
> >
> > Is there a way to create this pluta sign with xelatex?
> >
> > Thank you.
> >
> >
> > > ne 10. 3. 2024 v 22:39 odesílatel François Patte
> > > napsal:
> > > >
> > > > Bonjour,
> > > >
> > > > I would like to combine glyphs using xelatex : the glyphs are:
> > > > U+0947
> > > > and U+093D if I write \symbol{"0947}\symbol{"093D}, I get the
> > > > two
> > > > glyphs
> > > > side by side, the first one with a dotted circle below.
> > > >
> > > > What I want is the first one combined with the second one ie.
> > > > the
> > > > first
> > > > one above the second one.
> > > >
> > > > How can I get this result?
> > > >
> > > > Thank you.
> > > >
> >
> > --
> > François Patte
> > UFR de mathématiques et informatique
> > Laboratoire CNRS MAP5, UMR 8145
> > Université Paris Descartes
> > 45, rue des Saints Pères
> > F-75270 Paris Cedex 06
> > Tél. +33 (0)6 7892 5822
> > http://www.math-info.univ-paris5.fr/~patte
> > FSF
> > https://www.fsf.org/blogs/community/presenting-shoetool-happy-holidays-from-the-fsf
>
Re: [XeTeX] does language switching works properly?
If so, I will take this to the fontforge lists.
Thank you.
Antonis.
On 12/3/21 5:38 PM, Zdenek Wagner wrote:
> Hi,
>
> I think that this is not a XeTeX problem but a font problem. For
> instance, FreeSerif can distinguish conjuncts for Hindi from conjuncts
> for Sanskrit and can use different spacing for interpunctin based on
> the language. This leads me to thinking that it is a font problem.
>
> Zdeněk Wagner
> http://ttsm.icpf.cas.cz/team/wagner.shtml
>
> pá 3. 12. 2021 v 16:18 odesílatel Antonis Tsolomitis via XeTeX
> napsal:
>>
>>
>> In Greek (and Russian) the guillemots are different than the default. So the
>> NewCM fonts
>> include a lookup cv04 for the Greek and cv03 for the Russian to switch to
>> the proper glyphs.
>>
>> I thought that if cv04 has metadata
>>
>> grek(dflt)
>>
>> and if I switch to Greek using the polyglossia command
>> \textlang{greek}{\newcmgreekguillemots «»}
>>
>> where
>>
>> \newfontfamily\newcmgreekguillemots[CharacterVariant=4]{NewCM10-Book.otf}
>>
>> then the substitution will work. But it does not.
>>
>> If I add to metadata
>>
>> latn{dflt}
>>
>> then it works. But is this proper? Shouldn't it work only with grek{dlft} ?
>>
>> It is either my understanding wrong or polyglossia does not do the proper
>> switching or xetex
>> does not pickup the change of language properly.
>>
>> In my sources I have added latn{dflt} for both Greek and Russian to make the
>> fonts work.
>> So if a test is needed I have to send a custom font.
>>
>> Thanks,
>>
>> Antonis.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
OpenPGP_signature
Description: OpenPGP digital signature
[XeTeX] does language switching works properly?
In Greek (and Russian) the guillemots are different than the default. So
the NewCM fonts
include a lookup cv04 for the Greek and cv03 for the Russian to switch
to the proper glyphs.
I thought that if cv04 has metadata
grek(dflt)
and if I switch to Greek using the polyglossia command
\textlang{greek}{\newcmgreekguillemots «»}
where
\newfontfamily\newcmgreekguillemots[CharacterVariant=4]{NewCM10-Book.otf}
then the substitution will work. But it does not.
If I add to metadata
latn{dflt}
then it works. But is this proper? Shouldn't it work only with grek{dlft} ?
It is either my understanding wrong or polyglossia does not do the
proper switching or xetex
does not pickup the change of language properly.
In my sources I have added latn{dflt} for both Greek and Russian to make
the fonts work.
So if a test is needed I have to send a custom font.
Thanks,
Antonis.
OpenPGP_signature
Description: OpenPGP digital signature
Re: [XeTeX] diacritics stacking using anchor points
> I also fixed the stacking_above_AND_below. NewCM will have stellar > support for diacritics stacking 😁 > Which is very useful for languages like Vietnamese. > A.S. True but not only. More languages need stacking. Such as Hebrew or even Greek for academic work. On 10/25/21 8:59 PM, Michael Maxwell wrote: > 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. Yes, of course. The font supports these things in its current state in my sources. CTAN version has---I would say---preliminary support since bugs have been found and needs fixes for these to work. Fixes (unless more bugs surface (in which case I will report back here)) will be uploaded with version 4 which hopefully will include Coptic for Academic (and not only) use. Here is x with stacking above and below as shown with okular: thanks, Antonis
Re: [XeTeX] diacritics stacking using anchor points
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:
>
>
>
>
>
>
>
>
>
> whereas for uni0301 and other diacritics that should attach to the
> "above" anchor of the base, the attachment has class=3:
>
>
>
>
>
>
>
>
>
> In the associated BaseArray, glyphs like uni2C9B appear to have only
> anchors 3 (above) and 4 (below) defined:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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 , the lookup that wants to handle 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.
>>>>
>>>
>>
>
Re: [XeTeX] diacritics stacking using anchor points
Thank you Jonathan so much.
I do not really care about the dialogs of ff since I can always edit the
sfd file
for such simple things with vi.
Now that I know the difference even if I fail, I have something to take
to the ff list 😁
best,
Antonis.
On 23/10/21 23:11, 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:
whereas for uni0301 and other diacritics that should attach to the
"above" anchor of the base, the attachment has class=3:
In the associated BaseArray, glyphs like uni2C9B appear to have only
anchors 3 (above) and 4 (below) defined:
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 , the lookup that wants to handle 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.
Re: [XeTeX] diacritics stacking using anchor points
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?
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.
>>
>
[XeTeX] diacritics stacking using anchor points
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(?)
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.otf
thanks for any help,
Antonis.
Re: [XeTeX] question about ScriptPercentScaleDown
On 10/10/2016 05:19 μμ, Jonathan Kew wrote: On 10/10/2016 12:26, Antonis Tsolomitis wrote: Hello, I am not sure if this is the correct list for such a question... if not, I would be glad if someone can direct me to the correct list. I am developing a Math Table for a font (to be released with OFL license) and I have a difficulty with the parameters ScriptPercentScaleDown and ScriptScriptPercentScaleDown. If I do not set any point size in the documentclass (so it defaults to 10pt) everything works fine. But if I set the 11pt or the 12pt option, xelatex (as well as lualatex) ignore the ScriptPercentScaleDown and ScriptScriptPercentScaleDown parameters and default to 80% and 60% respectively. Do I miss something here or have I hit a bug..., maybe? Let me also mention that I just checked with Asana-Math and the behavior is the same. Could you provide a minimal testcase (using Asana-Math if your font isn't yet ready to be made available for others to test) demonstrating the problem? Offhand, I think this may be an issue with the unicode-math package (I presume that's what you're using?) rather than the actual engine. JK Sure, but to test you will have to modify Asana-Math at this point. So I attach a minimal example. 1. Open Asana-Math.otf in fontforge. Go to Element → Other Info → Math Info Modify ScriptPercentScaleDown, to something that will make it easy to spot the problem. Say to 120. Generate fontfiles, producing Asana-Math.otf, and make sure you export the Math table in it's options. 2. Run xelatex on my example (set at 12pt). You will see in the output that the exponent is smaller than the base, although we have instructed in the Math table the engine/font to upscale the exponents to 120% 3. Now modify my attached file by removing the 12pt in the documentclass options. Re run xelatex. You will see that now the exponent scales properly and it is larger that the base. Could be a bug in the unicode-math package. I just do not know. Thanks, Antonis. exptestlocal-asana.tex Description: TeX document -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] question about ScriptPercentScaleDown
Hello, I am not sure if this is the correct list for such a question... if not, I would be glad if someone can direct me to the correct list. I am developing a Math Table for a font (to be released with OFL license) and I have a difficulty with the parameters ScriptPercentScaleDown and ScriptScriptPercentScaleDown. If I do not set any point size in the documentclass (so it defaults to 10pt) everything works fine. But if I set the 11pt or the 12pt option, xelatex (as well as lualatex) ignore the ScriptPercentScaleDown and ScriptScriptPercentScaleDown parameters and default to 80% and 60% respectively. Do I miss something here or have I hit a bug..., maybe? Let me also mention that I just checked with Asana-Math and the behavior is the same. Thanks for any hint, Antonis. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
