Positioning with number values not working as should

Glyphs
1

Hi, I tried following this tutorial with my variable font:

I wanted to make some case-sensitive (and smallcaps-sensitive) forms for parenthesis, quotes, dashes, some symbols, inverted question and exclamation marks using opentype pos function inside case, smcp and c2sc, but it doesn’t work exactly as it should. In the thinnest master it looks okay, but as the weight increases, the forms shift too much. I am pretty sure I calculated everything, but here are my number values and metrics:

  • $exclamCaseShift — distance between x-Height and Cap Height used to shift exclamdown and questiondown upwards to match the uppercase (= Cap Height - x-Height)
  • $symbolCaseShift — distance between the centre of lowercase characters and the centre of uppercase characters used to shift parenthesis and some symbols ex. arrows upwards to match the uppercase (= Cap Height / 2 - x-Height / 2)
  • $quotesCSShift — distance between the Cap Height and Small Caps Height used to shift the upper quotes downwards to match the small caps (= Small Caps Height - Cap Height)
  • $dashCSShift — distance between the centre of small caps and the centre of uppercase characters used to shift dashes downwards to match the small caps (= Small Caps Height / 2 - Cap Height / 2)
MASTER WEIGHT:      20     70    140
Cap Height:        705    705    705
Small Caps:        535    550    560
x-Height:          510    528    540
$exclamCaseShift:  195    177    165
$symbolCaseShift:   98     89     83
$quotesCSShift:   -170   -155   -145
$dashCSShift:      -89    -80    -75

Below is a screenshot from InDesign showing how the quotes, dashes and inverted exclamation marks miss their desired positions in bolder masters. The problem seems to be gradually more significant, interpolating along weight, so it looks like the unit by which the pos function performs is different than the one of the font, idk… What do you think? Has anybody had this kind of problem before me? I haven’t seen similar topics on the forum. I mean I could always do a workaround by making the substitution. Thanks

Screenshot 2023-02-08 at 21.24.08
Screenshot 2023-02-08 at 21.24.082104×1380 157 KB

Screenshot 2023-02-08 at 20.42.48
Screenshot 2023-02-08 at 20.42.482102×1730 271 KB

Screenshot 2023-02-08 at 20.42.37
Screenshot 2023-02-08 at 20.42.372102×1730 423 KB

2

What version of Glyphs do you have?

3

3.2 (3177)

4

Can you send me that file?

5

Hey Georg, I sent you the file via direct message. Did you get it?

6

I should have check myself. Number values are not variable, yet. We are working on this.

7

Ah okay! So I understand that for the variable font I must create alternate .case versions for cease sensitive forms? Or maybe the feature will come in some not so distant update? :slight_smile:

8

No you can variate within feature code. Read the release notes of 3.1.1 in the News.

9

Hello @mekkablue I’ve been trying to use this variable positioning within ot code and had strange effects. The values don’t interpolate and other glyphs are shifted. I noticed that the shift is calculated by the first set of values.

My code looks like this in the case feature:

pos @HighQuotes 	 <0 -55 0 0 (wght:70 opsz:65) 0 -55 0 0 (wght:140 opsz:65) 0 -55 0 0 
	(wght:20 opsz:12) 0 0 0 0 	(wght:70 opsz:12) 0 0 0 0 	(wght:140 opsz:12) 0 0 0 0>;

Here are the results in InDesign in three weights: first line is with case turned off; second line has it on only on the middle “H” and it seems to work fine only in this case; third line has this turned on everywhere and in this case instead of lowering the quotes, InDesign lifts the Hs up. I added the dotted underline on the baseline so that you can see better.

Screenshot 2023-06-21 at 10.31.54
Screenshot 2023-06-21 at 10.31.542462×1766 235 KB

Another example of a different feature (smcp+c2sc) shows that the values don’t interpolate (in previous example the value is the same throughout all weights). The regular and bold ordinals went too low:

pos [A.ordn D.ordn E.ordn H.ordn N.ordn O.ordn R.ordn S.ordn S.ordn.ss02 T.ordn ordnlink]' 
				 <0 -170 0 0 (wght:70 opsz:65) 0 -155 0 0 (wght:140 opsz:65) 0 -145 0 0 
(wght:20 opsz:12) 0 -225 0 0 (wght:70 opsz:12) 0 -210 0 0 (wght:140 opsz:12) 0 -200 0 0>;

Screenshot 2023-06-21 at 10.43.47
Screenshot 2023-06-21 at 10.43.472462×1516 209 KB

And finally when I mix weights in one text, everything goes crazy:

Screenshot 2023-06-21 at 10.45.03
Screenshot 2023-06-21 at 10.45.031456×810 35.6 KB

Is it a problem with my code, glyphs or indesign?

Thanks

10

Where are the screenshots from? InDesign?

If it is InDesign, does it make a difference if you switch composers?

Can you please send me the .glyphs file to . I will have a look.

11

Have you tried this with a static font first?

12

@mekkablue, I sent you the glyphs file via DM. Yes, the screenshots ae from InDesign. Thanks

@GeorgSeifert When I try to export static fonts, I get errors which send me to all the cases of my using pos in the code:

Screenshot 2023-06-22 at 13.37.19
Screenshot 2023-06-22 at 13.37.191480×958 158 KB

13

You need to add a #ifdef VARIABLE + #endif around the variable feature code.

I meant that you write the pos rues only for a single master font. That you know the syntax is correct.

14

I put the #ifdef VARIABLE and #ifend around the pos code and then added the pos code in the export of a static font as a custom parameter ‘replace feature’. Now the static font exports normally, yet it still repositions text in a weird way.

Screenshot 2023-06-22 at 21.03.56
Screenshot 2023-06-22 at 21.03.561418×856 16 KB

The static feature code looks like this:

pos [A.ordn D.ordn E.ordn H.ordn N.ordn O.ordn R.ordn S.ordn S.ordn.ss02 T.ordn ordnlink]' <0 -155 0 0>;

15

@mekkablue, yes, the problem seems to occur only in World-ready composers. But then some contextual substitutions don’t work in traditional adobe composers.

Screenshot 2023-06-22 at 21.19.56
Screenshot 2023-06-22 at 21.19.562494×1598 313 KB

16

Why do you add the ' to the pos rule?

17

I don’t really know, to be honest, I think somebody told me to do so long time ago and I never questioned it, but it seems to make no difference with or without the '

18

also the pos thing seems to affect text that is typed after so I wanted to double make sure that the pos rule applies only to the glyphs I want it to :stuck_out_tongue: but it doesn’t make any difference

19

But the contextual pos rule might be handled differently by the different composers. The simple single pos rule should be much better supported.

If you need the underline to work properly in Indesign, you can’t use GPOS but you need to add alternate glyphs that are shifted down and replace them with GSUB.

20

@GeorgSeifert no no, I’m not worried about the underline. I added it only to show where the baseline is. It is only to show that in world-ready composers some glyphs are lifted above the baseline or under the baseline although they were not told to by any pos rule and those that should have been shifted down, stay where they were. Like in the screenshot several messages up with “1ST 2ND 3RD 4TH” where they go crazy when I use different weights.