Hi, I really like the idea of using a single font and only changing variables and using it for the whole document. Ubuntu Sans (Variable) makes this possible, but upper diacritics (eg. Ä) are not scaled when width is changed, the lower diacritics (eg. ą) seem to work as desired. Unfortunately, I can't narrow down the problem any further. I can change the width with Google Fonts without any errors, and Inkscape doesn't cause any problems either. How can I fix that? Thanks for support mwe : Context Version; 2025.06.12 14:21 \definefontfeature [fntubuntf] [axis={wght=300,wdth=75}] \definefontfamily [ubuntufont] [ss] [Ubuntu] [tf={file:{UbuntuSans[wdth,wght].ttf},features:fntubuntf,}] \setupbodyfont [ubuntufont, ss] \starttext ÄöÖöÜü \stoptext
On 6/15/2025 4:46 PM, paper@mgrz.de wrote:
Hi, I really like the idea of using a single font and only changing variables and using it for the whole document. Ubuntu Sans (Variable) makes this possible, but upper diacritics (eg. Ä) are not scaled when width is changed, the lower diacritics (eg. ą) seem to work as desired. Unfortunately, I can't narrow down the problem any further. I can change the width with Google Fonts without any errors, and Inkscape doesn't cause any problems either. How can I fix that?
Thanks for support
mwe : Context Version; 2025.06.12 14:21
\definefontfeature [fntubuntf] [axis={wght=300,wdth=75}] \definefontfamily [ubuntufont] [ss] [Ubuntu] [tf={file:{UbuntuSans[wdth,wght].ttf},features:fntubuntf,}] \setupbodyfont [ubuntufont, ss]
\starttext ÄöÖöÜü \stoptext
The accents are part of the glyph (so not separate and anchored). \definefontfeature [fntubuntfa] [default] \definefontfeature [fntubuntfb] [default] [axis={wght=300,wdth=75}] \definefontfeature [fntubuntfc] [default] [axis={wght=600,wdth=75}] \definefontfeature [fntubuntfd] [default] [axis={wght=300,wdth=150}] \definefontfeature [fntubuntfe] [default] [axis={wght=300,wdth=100}] \showglyphs \startTEXpage[offset=1ts] \definedfont[file:UbuntuSansVariable.ttf*fntubuntfa] ÄöÖöÜü\par \definedfont[file:UbuntuSansVariable.ttf*fntubuntfb] ÄöÖöÜü\par \definedfont[file:UbuntuSansVariable.ttf*fntubuntfc] ÄöÖöÜü\par \definedfont[file:UbuntuSansVariable.ttf*fntubuntfd] ÄöÖöÜü\par \definedfont[file:UbuntuSansVariable.ttf*fntubuntfe] ÄöÖöÜü \stopTEXpage it looks like when the width goes negative relative to the default 100 there is some sign issue but i wonder at what end that error is because the main shape is ok Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 6/15/25 16:46, paper@mgrz.de wrote:
[...] Ubuntu Sans (Variable) makes this possible, but upper diacritics (eg. Ä) are not scaled when width is changed, the lower diacritics (eg. ą) seem to work as desired.
Hi, what I see (using the sample below) is that upper diacritics are misplaced (wrong centered), but not wrong scaled. \definefontfeature [one] [axis={wght=100,wdth=75}] \definefontfeature [two] [axis={wght=800,wdth=100}] \definefontfamily [one] [rm] [Ubuntu Sans] [features={default,one}] \definefontfamily [two] [rm] [Ubuntu Sans] [features={default,two}] \setupbodyfont [one] \starttext \startTEXpage[offset=1dk] ÄąÖöÜü\\ \switchtobodyfont[two] ÄąÖöÜü \stopTEXpage \stoptext
Unfortunately, I can't narrow down the problem any further. I can change the width with Google Fonts without any errors, and Inkscape doesn't cause any problems either. I can confirm that ConTeXt cannot match the same results as Inkscape, where all diacritics where placed properly in relation to their main characters.
How can I fix that?
ConTeXt supports variable fonts, but from time to time glitches may appear. Sorry, Hans, could you check what it seems to be misplaced diacritcs in variable fonts? Many thanks for your help, Pablo
On 6/15/2025 7:13 PM, Pablo Rodriguez via ntg-context wrote:
On 6/15/25 16:46, paper@mgrz.de wrote:
[...] Ubuntu Sans (Variable) makes this possible, but upper diacritics (eg. Ä) are not scaled when width is changed, the lower diacritics (eg. ą) seem to work as desired.
Hi,
what I see (using the sample below) is that upper diacritics are misplaced (wrong centered), but not wrong scaled.
\definefontfeature [one] [axis={wght=100,wdth=75}] \definefontfeature [two] [axis={wght=800,wdth=100}] \definefontfamily [one] [rm] [Ubuntu Sans] [features={default,one}] \definefontfamily [two] [rm] [Ubuntu Sans] [features={default,two}] \setupbodyfont [one]
\starttext \startTEXpage[offset=1dk] ÄąÖöÜü\\ \switchtobodyfont[two] ÄąÖöÜü \stopTEXpage \stoptext
Unfortunately, I can't narrow down the problem any further. I can change the width with Google Fonts without any errors, and Inkscape doesn't cause any problems either. I can confirm that ConTeXt cannot match the same results as Inkscape, where all diacritics where placed properly in relation to their main characters.
How can I fix that?
ConTeXt supports variable fonts, but from time to time glitches may appear.
Sorry, Hans, could you check what it seems to be misplaced diacritcs in variable fonts?
but what is weird is that it only happens in one direction, compare < 100 and > 100 (there is some delta code that we don't yet apply but when i test with that it looks like that can be ignored, very tiny values) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 6/15/2025 7:13 PM, Pablo Rodriguez via ntg-context wrote:
ConTeXt supports variable fonts, but from time to time glitches may appear.
Keep in mind that we were among the firstin supporting variable fonts (someone involved told me actually the first using it in typeset text). There were not that many fonts at that time and the specification was minimal. So a lot of trial and error was involved. And it's not like I use these fonts myself. So, we adapt as we go and fonts show up, it's the best we can do.
Sorry, Hans, could you check what it seems to be misplaced diacritcs in variable fonts?
I have a clue but need to check how reliable it is, which of course you will test. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Am 16.06.25 um 09:05 schrieb Hans Hagen:
On 6/15/2025 7:13 PM, Pablo Rodriguez via ntg-context wrote:
ConTeXt supports variable fonts, but from time to time glitches may appear.
Keep in mind that we were among the firstin supporting variable fonts (someone involved told me actually the first using it in typeset text). There were not that many fonts at that time and the specification was minimal. So a lot of trial and error was involved. And it's not like I use these fonts myself. So, we adapt as we go and fonts show up, it's the best we can do.
There’s an increasing number of variable fonts e.g. at Google: https://fonts.google.com/?categoryFilters=Technology:%2FTechnology%2FVariabl... Since “everyone” is producing them I guess their use is already quite widespread. They’re supported in CSS: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_fonts/Variable_fonts_gu... See also https://en.wikipedia.org/wiki/Variable_font#Adoption Hraban
On 6/16/2025 9:38 AM, Henning Hraban Ramm wrote:
Am 16.06.25 um 09:05 schrieb Hans Hagen:
On 6/15/2025 7:13 PM, Pablo Rodriguez via ntg-context wrote:
ConTeXt supports variable fonts, but from time to time glitches may appear.
Keep in mind that we were among the firstin supporting variable fonts (someone involved told me actually the first using it in typeset text). There were not that many fonts at that time and the specification was minimal. So a lot of trial and error was involved. And it's not like I use these fonts myself. So, we adapt as we go and fonts show up, it's the best we can do.
There’s an increasing number of variable fonts e.g. at Google: https://fonts.google.com/?categoryFilters=Technology: %2FTechnology%2FVariable
which is no guarantee for beauty or excessive push of "whatever variantions we can come up with that a font editoir can make me" so i don't really go on a "check out every font" frenzy
Since “everyone” is producing them I guess their use is already quite widespread.
it reduces bandwidth which is one reason why the project got started (i was told) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Am 16.06.25 um 10:10 schrieb Hans Hagen:
On 6/16/2025 9:38 AM, Henning Hraban Ramm wrote:
There’s an increasing number of variable fonts e.g. at Google: https://fonts.google.com/?categoryFilters=Technology: %2FTechnology%2FVariable
which is no guarantee for beauty or excessive push of "whatever variantions we can come up with that a font editoir can make me" so i don't really go on a "check out every font" frenzy
No, of course.
Since “everyone” is producing them I guess their use is already quite widespread.
it reduces bandwidth which is one reason why the project got started (i was told)
Makes sense for webfonts. Hraban
Hans Hagen wrote:
On 6/16/2025 9:38 AM, Henning Hraban Ramm wrote:
...so i don't really go on a "check out every font" frenzy...
oh come on, there are only about 500 fonts on google fonts. Joking aside, I am very grateful for your support, maybe you have an idea specifically for my problem? I'll randomly list my observations that seem unusual and may have something to do with my problem. I've been playing around on opentype.js.org and they have the problem that both the top and bottom diacritics are not scaled, then for each font. If I set aalt under the fontfeatures, then the document cannot be created, or it would take forever, unfortunately I don't have that much time. The features that should actually be on by default are not, for example Kern, but I'm not sure if that's intentional. Thanks everyone Translated with DeepL.com (free version)
On 6/16/2025 7:38 PM, Michael G wrote:
Hans Hagen wrote:
On 6/16/2025 9:38 AM, Henning Hraban Ramm wrote:
...so i don't really go on a "check out every font" frenzy...
oh come on, there are only about 500 fonts on google fonts. Joking aside, I am very grateful for your support, maybe you have an idea specifically for my problem?
i have it kind of working here but this whole variable font mechanism is ... well ...
I'll randomly list my observations that seem unusual and may have something to do with my problem.
as always with fonts, glyohs in a font are not defined in a consistent way so at first sight similar situations have different implementations (features etc) and as many features like this are generated by applications (same as svg) no one cares much about that
I've been playing around on opentype.js.org and they have the problem that both the top and bottom diacritics are not scaled, then for each font.
If I set aalt under the fontfeatures, then the document cannot be created, or it would take forever, unfortunately I don't have that much time.
hm, in context?
The features that should actually be on by default are not, for example Kern, but I'm not sure if that's intentional.
you need to take them from default : \definefontfeature[foo][default][....] in tex it's all ahbout control so no hard coded defaults
Translated with DeepL.com (free version)
so is this a human or bot speaking here ... Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
i have it kind of working here but this whole variable font mechanism is ... well ... Thank you for your efforts.
I've been playing around on opentype.js.org and they have the problem that both the top and bottom diacritics are not scaled, then for each font. If I set aalt under the fontfeatures, then the document cannot be created, or it would take forever, unfortunately I don't have that much time. hm, in context? It was supposed to be a wild collection of clues that I thought might be useful and does not have to be related.
1. opentype.js.org (the Glyph Inspector to be pecise) has comparable problems, and show informations about composition of the glyph. It was helpful for my understanding. 2. aalt is an independent problem that occurs in context. The process stalls and must be cancelled manually.
The features that should actually be on by default are not, for example Kern, but I'm not sure if that's intentional. you need to take them from default :
\definefontfeature[foo][default][....] in tex it's all ahbout control so no hard coded defaults Yes, actually obvious, but I didn't think of it myself.
Translated with DeepL.com (free version) so is this a human or bot speaking here ... A human, I use deepl as a little helper because my english is ...well... good for reading technical documentation and not much more. The attachment wasn't intended.
On 6/16/2025 8:57 PM, Michael G wrote:
2. aalt is an independent problem that occurs in context. The process stalls and must be cancelled manually.
then we need an example Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 6/16/25 09:05, Hans Hagen wrote:
On 6/15/2025 7:13 PM, Pablo Rodriguez via ntg-context wrote: [...]
Sorry, Hans, could you check what it seems to be misplaced diacritcs in variable fonts?
I have a clue but need to check how reliable it is, which of course you will test.
Of course, Hans, I don’t mind testing whatever is required for ConTeXt (although not in about ten days starting from next Friday: away from home and probably without laptop with a reliable internet connection]). BTW, some time ago, I stopped using variable fonts because of having the impression that ConTeXt had many issues dealing with them. If the following were the case, I would totally understand that you weren’t interested in improving the support for variable fonts in ConTeXt. I simply ask: would you be interested in issue reports about variable fonts? Besides that, if you agree, since Inkscape seems to have less issues with variable fonts, I can ask at https://gitlab.com/inkscape/inkscape whether they have any publicly accessible reference used for their implementation. Many thanks for your help, Pablo
On 6/18/2025 7:16 PM, Pablo Rodriguez via ntg-context wrote:
On 6/16/25 09:05, Hans Hagen wrote:
On 6/15/2025 7:13 PM, Pablo Rodriguez via ntg-context wrote: [...]
Sorry, Hans, could you check what it seems to be misplaced diacritcs in variable fonts?
I have a clue but need to check how reliable it is, which of course you will test.
Of course, Hans, I don’t mind testing whatever is required for ConTeXt (although not in about ten days starting from next Friday: away from home and probably without laptop with a reliable internet connection]).
BTW, some time ago, I stopped using variable fonts because of having the impression that ConTeXt had many issues dealing with them.
Really? Many? These fonts are relatively new, and esp in the beginning were often not ok. When I gave some presentations long ago it were for some involved the first time they saw these fonts used in typesetting so it can't be that bad.
If the following were the case, I would totally understand that you weren’t interested in improving the support for variable fonts in ConTeXt. I simply ask: would you be interested in issue reports about variable fonts?
Sure, but only it they are clear issues. Side effects like bad shapes are not that interesting. Also, I'm not going to add heuristics for border cases. And it has not the highest priority.
Besides that, if you agree, since Inkscape seems to have less issues with variable fonts, I can ask at https://gitlab.com/inkscape/inkscape whether they have any publicly accessible reference used for their implementation.
They probably use some library. And then there is of course the issue of bugs that became standards (as happened with some in pdf). (btw, I fix issues in lmtx and only occasionally backport to mkiv.) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 6/18/25 19:26, Hans Hagen wrote:
[...] Really? Many?
Well, probably not as many as they wouldn’t work at all. With fixed fonts I‘m fairly sure I’m getting the same shapes as with any other software. With variable fonts (“devil is in the detail”), I’m afraid I cannot be sure whether the results are the same. I have no means to know (other than testing) when they will differ. Since variable fonts are an option, fixed ones are more convenient (less hassle).
Sure, but only it they are clear issues. Side effects like bad shapes are not that interesting. Also, I'm not going to add heuristics for border cases. And it has not the highest priority.
Fine for me with low priority as long as they don’t get forgotten. I cannot remember now (I would have to start testing again), but not few issues where bad shapes. Whether some of these come from border cases or not, I’m afraid I don’t have the knowledge to distinguish their cause.
(btw, I fix issues in lmtx and only occasionally backport to mkiv.)
MkIV? I only use it nowadays to check that LMTX isn’t misbehaving. The moment I started using tw and th (and similar) as dimension units, there was no way back. Many thanks for your help, Pablo
participants (5)
-
Hans Hagen -
Henning Hraban Ramm -
Michael G -
Pablo Rodriguez -
paper＠mgrz.de