Allow negative percents about font-line HOT 10 CLOSED

Hi Yunus!

Mind sharing the font-line report for the font that you are working with and more information about what you are trying to achieve?

The percent is taken on the units per em value and that does not change with line spacing adjustments. It would be uncommon to take the line spacing down to very low ranges or you end up clipping features or have collisions across features that sit high or low in the box (e.g. marks). Are you attempting to make outlines touch/overlap across lines?

from font-line.

Segoe UI. Not limited to that font though.

My main reason is to fit it into Android, as Roboto has less font line compared to Segoe UI because they're meant to work on different platforms.

Segoe UI, by nature, has a lot of vertical blank space, since it's meant to be used on Windows/PC. Roboto or any font Google designed to used in Android System or any Android apps, on the other hand, has less spacing because it's meant to be used on Android/mobile phone.
But, Segoe UI is actually shorter than Roboto. It's just that it has bigger line breaks. Thus, it breaks on Android.

from font-line.

Mind posting the font-line report on Segoe UI in this thread?

from font-line.

segoeui-report.txt
roboto-report.txt

from font-line.

It looks like both fonts use Win metrics. The line spacing on Segoe UI is wider but it also has much larger yMin and yMax values so there must be some glyphs in the set that are taller and deeper than are seen in Roboto. Tightening the line spacing has the potential to cause either (1) clipping (on MS platform if you tighten the Win metrics); (2) cross line collisions (if you convert to a non Win metrics approach and tighten too much, leaving win metrics where they are currently defined).

First and foremost, be aware of the Segoe UI license. I have no familiarity with how the fonts are licensed and will assume that what you are doing here is legit.

You can edit the font file with the following script. It converts the fonts to use typo metrics instead of win metrics and uses the Roboto Win metrics definitions (that is what you are seeing for both of the above fonts on the Win platform). Through trial and error you can modify the values at the head of the script to get the line spacing that you want. The font file writes to [ORIGINAL FONT PATH].adjusted

Run it with:

$ python3 linespacing.py [font path]

linespacing.py

# The MIT License (MIT)
# Copyright © 2021 Christopher Simpkins
#
# Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

import os
import sys

from fontTools.ttLib import TTFont

TYPO_ASC = 1946
TYPO_DESC = -512
TYPO_LINEGAP = 0


def main(argv):
    for fontpath in argv:
        try:
            tt = TTFont(fontpath)
            # Set OS/2.fsSelection bit 7 to use typo metrics
            # instead of Win metrics
            fs_selection_int = tt["OS/2"].fsSelection
            mask = 1 << 7
            tt["OS/2"].fsSelection = fs_selection_int | mask

            # adjust typo metrics
            tt["OS/2"].sTypoAscender = TYPO_ASC
            tt["OS/2"].sTypoDescender = TYPO_DESC
            tt["OS/2"].sTypoLineGap = TYPO_LINEGAP

            tt.save(f"{fontpath}.adjusted")
            print(f"Successful write to path {fontpath}.adjusted")

        except Exception as e:
            sys.stderr(f"Error during execution: {str(e)}{os.linesep}")
            sys.exit(1)


if __name__ == "__main__":
    main(sys.argv[1:])

Hope that it helps.

from font-line.

Btw, the script above requires the fontTools Python package. If you've previously installed font-line then you already have it.

from font-line.

It is legal to use Segoe UI unless you publish it, according to Microsoft. That aside, this is only for the test. There are multiple Google Fonts that has the same problem.

I am fine with colliding fonts as long as they share the same spacing with Roboto (though as seen in the screenshots, that'll happen once in a blue moon). The rest is irrelevant for me.

The script didn't help me, by the way. Neither on Windows or Android.
(it prints this error but continues nonetheless: fsSelection bits 7, 8 and 9 are only defined in OS/2 table version 4 and up: version 3)
You can see how the font-spacing messes up with Android layouts:

from font-line.

it prints this error but continues nonetheless: fsSelection bits 7, 8 and 9 are only defined in OS/2 table version 4 and up: version 3

Hmm... I do know that Android will use the typo metrics if you are able to set bit 7. But yeah these metrics will not work if you can't set fsSelection bit 7. We'll need to dive into the other metrics sets.

That aside, this is only for the test. There are multiple Google Fonts that has the same problem.

What are you testing? Is it what other fonts can be used as system UI fonts in place of Roboto/Noto Sans UI on the Android platform? The answer will be that the overall vertical metrics of the fonts, including the ymin and ymax metrics glyphs in the set influence this issue. Android has a very strict policy about v metrics in system UI fonts. You can read more about it in this document: https://github.com/googlefonts/noto-source/blob/main/FONT_CONTRIBUTION.md#document-vs-ui-fonts (note that the values in the doc are scaled to 1000 UPM, you can scale them to the 2048 UPM fonts here with a factor of 2048/1000)

from font-line.

Being able to use any font in Android as currently most phones break any Android layout.

Modifying fonts with other software didn't work before so I searched for something like Font-Line, which sadly didn't support negatives (FontForge was the only one allowing changing some values anyway and apply to a font, though it didn't affect Android).

from font-line.

Are you familiar with Python to work on a small font editing script based on the source in this project? The scripting is straightforward using the Python fonttools package to access the font's OpenType table data fields and you'll find the fields that you need in these source files. The script that I provided in #53 (comment) can be used as a model to start. There is support in other languages for similar OpenType table editing functionality. You can then edit any field that you'd like in the font to examine this problem.

It sounds like you want to change all metrics in one font to match those in another font. That, unfortunately, is out of scope for this project. This tool attempts to maintain the original font's metrics approach and modify it to reduce internal/external leading values. If this goes beyond a hobbyist project and you need a hand, contact me by email and we can discuss it further.

from font-line.