Does Vertical Metrics Manager Consider Highest & lower points with anchors positions?

[Mohanak]

Does “Vertical Metrics Manager” script Consider Highest and lowest points even after anchors positions?
Just used it and it leaves marks out of the Metrics boundaries.

and also the “Apply to Font” button does not apply negatives values to the custom parameters. so you have to manually write it for Typo & hhea Descenders in custom parameters.

see the pictures:

before Vertical Metrics Manager:

After applying script but Without manual correcting Values:

After manual correcting hhea & Typo to Minus:

All Descenders left some marks not contained within metrics. so it is susceptible to be Cropped or hidden on different Platforms.

Marks is repositioned with anchors. why “Vertical Metrics Manager” does not take that into account?

Is there a Glyphs command or script to Find out the topmost and lowermost points. If “Vertical Metrics Manager” Does not?

[mekkablue (Rainer Erich Scheichelbauer)]

@Mohanak

and also the “Apply to Font” button does not apply negatives values to the custom parameters

True. There’s a bug in the script. Will upload a fix in a minute. Thanks for reporting!

Marks is repositioned with anchors. why “Vertical Metrics Manager” does not take that into account?

I don’t think this is necessary. What should count is the point coordinates. Can you show a case where changing a vertical metric has influence on the display of marks placed with mark-to-base and mark-to-mark positioning?

The problem is that, while mark-to-base may still be doable for measuring, mark-to-mark is endless since you can stack any number of marks.

[Mohanak]

@mekkablue
Thanks for clarifying the idea and the bug solving

@mekkablue

Can you show a case where changing a vertical metric has influence on the display of marks placed with mark-to-base and mark-to-mark positioning?

Actually I dont Know if i Get this question well.

I Know that mark to mark is gonna go stack beyond metrics anyway. but the important first mark written is mark-to-base anchor and it is still out of typo & hhea descender as shown in the last picture above.

[mekkablue (Rainer Erich Scheichelbauer)]

Yes. What is wrong with that? Do you fear clipping? I believe that shouldn’t occur in modern renderers with metrics that simply catch all glyphs as they are. I could add an option if that is not the case, but please show me a real life case that shows clipping.

The script only measures existing glyphs as a reference. Its main intention is to write the same metrics in all masters of perhaps more than one font file. You can set your own of course.

[Mohanak]

@mekkablue thanks

One last Point
Just to make my own metrics.

@Mohanak

Is there a Glyphs command or script to Find out the topmost and lowermost points?

@mekkablue

I could add an option if that is not the case, but please show me a real life case that shows clipping.

if i encountered that i will make a notify.

[Mohanak]

@mekkablue

The problem is that, while mark-to-base may still be doable for measuring, mark-to-mark is endless since you can stack any number of marks.

the problem is on MS office on both-platforms (2019 in my case),
no issue with mkmk as they wouldn’t stack on MS office, but mark-to-base (first diacritic) needs this solution.

@mekkablue

I could add an option if that is not the case

this would be a very helpful option.
if Vertical Metrics Manager considers a space above the highest & lowest (diacritics) anchors, that equals distance between longest top to _top (for winAscent. and longest _bottom to bottom (for winDescent) among diacritics anchors.

(good solution for the first mark-to-base diacritic)

@mekkablue

I believe that shouldn’t occur in modern renderers with metrics that simply catch all glyphs as they are. I could add an option if that is not the case, but please show me a real life case that shows clipping.

@mekkablue

the clipping is there on office 2019 Mac & office 2019 Win

on mac both winAscent & winDescent is affected

on windows the problem is appearing with winAscent only

[mekkablue (Rainer Erich Scheichelbauer)]

Just to confirm: you can fix it with larger winAscent/winDescent values?
Will add an option to the script.

[Mohanak]

@mekkablue

Just to confirm: you can fix it with larger winAscent/winDescent values?

yes if manually increased winAscent/winDescent values, No more clipping/hidden diacritics.

thanks man.

[mekkablue (Rainer Erich Scheichelbauer)]

Very good. Thanks for your research, update should be up soon.

Update: just uploaded a new version with the new option:

It respects the Limit to Script setting. May be a good idea because otherwise it calculates the offset for an Arabic mark on a Latin letter.

[Mohanak]

@mekkablue

thank you very much for this option.
i’am so sorry for this:

@Mohanak

yes if manually increased winAscent/winDescent values, No more clipping/hidden diacritics.

previous info was my trying on windows.

to be clear, on mac i’ve just tried all possible values for metrics (9 times exported font with 9 different family names)

then, i found on mac that clipping is based on hhea value wether fsSelection is applied or not.
regardless of usWin & sTypo values.

[Mohanak]

@mekkablue

@Mohanak

to be clear, on mac i’ve just tried all possible values for metrics (9 times exported font with 9 different family names)

results:

[mekkablue (Rainer Erich Scheichelbauer)]

@Mohanak

i found on mac that clipping is based on hhea value wether fsSelection is applied or not.

That is a bug in Office for Mac. The hhea values are not intended for clipping. Ramping them up will lead to huge distances between lines, and display discrepancies between Windows and Mac.