Font Forum

Hello,

So, I've recently discovered that one can force a line break in the preview window, to view characters on a second line, or to help view characters that may be set beyond the ascender values. While this is useful, it gets tiresome to have to enter "/newline" everytime.

As I am working on a font that has a lot of vertical CCP movement for its glyphs, I could really benefit from a movable baseline in the OTD's preview window (something like the mock-up image below). I don't necessarily need to see the grid line, although an option to view it at all times would be fine. However, it would be really nice if you could see the grid line only as you move the slider up and down; a temporary toggle, if you will (again, perhaps as an option). Lastly, being able to auto-fit and auto-move the baseline according to the vertical data might provide further benefit.

Unless there's a current setting in FC that already allows the baseline to be repositioned in the preview window (other than using the /newline break), I think this feature would be very useful.

Thank you

Is there a reason why your need to exceed the WinAscent? If you just do Settings, Metrics, Calculate that will ensure that no glyphs are clipped. There is already some white space in the Preview Toolbar above WinAscent. Recalculating WinAscent, in effect, moves the baseline down.

A button to insert a new line might be easier to implement.

Saving preview texts is already available so you can save a few presets to suit your needs.

I found that Anchored-based positioning often causes a problem with Sacutedotaccent
exceeding WinAscent, so I have saved a preview text string to quickly locate and fix this and other problematic glyphs:

Hello Bhikkhu,

Bhikkhu Pesala wrote: ↑Tue Aug 04, 2020 10:07 pm Is there a reason why your need to exceed the WinAscent?

In the program I'm applying the font for, raising the WinAscent (and Ascender) too high will effectively raise the input caret box from which the user enters their data. So, I'm playing a balancing act where lowering these values keeps the input box at a reasonably comfortable level. The font's routine that raising my characters are still visible once the input window is closed. Otherwise, I would have surely raised the WinAscent and Ascender values and called it a day.

If you just do Settings, Metrics, Calculate that will ensure that no glyphs are clipped. There is already some white space in the Preview Toolbar above WinAscent. Recalculating WinAscent, in effect, moves the baseline down.

Your suggestion to recalculate the WinAscender from within FC does not provide satisfactory results because I am purposely raising characters' positions with CCP routines that puts them well above the baseline and above their cap height. However, manually raising the WinAscender value does indeed bring the baseline down in the preview window. This can work, but it becomes something I need to remember to set back to its original value before exporting the font.

Thank you

The problem with drawing above 'Win Ascent' or below 'Win Descent' is that these are the limits where Windows stops drawing the glyph. These are not the same as 'Typo Ascender' and 'Typo Descender' which are limits within font creator and can be exceeded quite happily without problems.

If you exceed 'Win Ascent' then you will probably find that Windows will only draw the parts of the glyph between 'Win Ascent' and 'Win Descent'.

PJMiller wrote: ↑Wed Aug 05, 2020 8:57 am The problem with drawing above 'Win Ascent' or below 'Win Descent' is that these are the limits where Windows stops drawing the glyph. These are not the same as 'Typo Ascender' and 'Typo Descender' which are limits within font creator and can be exceeded quite happily without problems.

If you exceed 'Win Ascent' then you will probably find that Windows will only draw the parts of the glyph between 'Win Ascent' and 'Win Descent'.

Thanks PJ,

I'm still working my way around the Win Ascent values and will probably leave it till the end of my final font coding. It seems, at least in the font's target application, the Win Ascent has more relevance on the program's input box and its vertical positioning than on the resulting set position of text (after exiting input mode, subs, CCP's and all). To this, I've given the Win Ascent a comfortable value so as to not have the input box jump too high. It's really just a quirk in the application that I have to deal with.

Coding joy all around!

...apologies for altering the topic of this thread.