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?
True. There’s a bug in the script. Will upload a fix in a minute. Thanks for reporting!
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.
Thanks for clarifying the idea and the bug solving
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.
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.
One last Point
Just to make my own metrics.
if i encountered that i will make a notify.
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.
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)
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
Just to confirm: you can fix it with larger winAscent/winDescent values?
Will add an option to the script.
yes if manually increased winAscent/winDescent values, No more clipping/hidden diacritics.
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.
thank you very much for this option.
i’am so sorry for this:
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.
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.