SDK font filenames

SDK Bug Reports
,
1

I was tinkering around with fonts inside \resources\Fonts and noticed that fonts aren't following a single naming scheme. It isn't critical, of course, but those who'd want to select fonts dynamically would need to do renaming by themselves.

A few things i propose to be addressed:

  1. The reason i put this into Bug subforum, and not the Feature Requests. For some fonts the number after the family name doesn't seem to represent the cap height (checked against the height of the digit "0"). I believe it should, as it would conform to design doc.
    Examples: "Roobert-11-Medium" (height of "0" - 14), "font-pedallica-fun-14" (12), "font-pedallica-fun-16" (14), "Roobert-10-Bold-Halved" (11), "Roobert-11-Bold" (15), "Roobert-11-Medium-Halved" (15), "Roobert-11-Medium-Numerals" (15), "Roobert-24-Medium-Halved" (23*).
    * This one may be considered 24, i guess, but since every other pixel row of "halved" variants is empty, they can only be of odd sizes (also, "1" seems to be 2 pixel shorter than other digits for some reason).
  2. Some fonts have a multiplier ("-2x", "-3x") instead of size. While a nice indicator, it wouldn't work well for dynamic font access.
  3. Some fonts are missing font size in the filename. Seems like it wasn't added to fonts that don't have size variants nor added to fonts with multipliers, but it'd be helpful to have it for dynamic access.
  4. "Asheville-Mono-Light-24-px" and "Asheville-Rounded-24-px" have "-px" after the size, other fonts do not. A lot of fonts start with "font-" prefix, but, again, not all. These prefix and suffix should be either removed or added to all fonts. Personally, don't see much need for both.
  5. Some filenames are capitalized, some aren't. Three options here:
    1. Capitalize all words;
    2. Capitalize font family name only;
    3. Keep everything lowercase.
2

I feel like the issue with this would be that it could break backwards compatibility.

3

Would it, though?

I mean, it's not like this should affect existing apps, nor i am suggesting any edits to the fonts themselves (well, aside from, maybe,"Roobert-24-Medium-Halved"'s "1", but even with that it would be up to developers to update or not).
As for currently in-development projects, while, technically, there is always a possibility that someone made some kind of automation on the font directory/font paths, it doesn't seem like robust setup in the first place. And it would just require a one-time fix.