Closed felipesanches closed 1 month ago
Wouldn't that sometimes weaken the documentation of the checks?
For instance, here we are performing two very small checks, but their reasoning is detailed in their respective rationales:
Some older text-handling tools sometimes misbehave if the last line of data
in a text file is not terminated with a newline character (also known as '\n').
We know that this is a very small detail, but for the sake of keeping all
DESCRIPTION.en_us.html files uniformly formatted throughout the GFonts
collection, we chose to adopt the practice of placing this final linebreak
character on them.
and the other one:
The DESCRIPTION.en_us.html file is intended to provide a brief overview of
the font family. It should be long enough to be useful to users, but not so
long that it becomes overwhelming.
We chose 200 bytes as a minimum length because it suggests that someone has
taken the time to write "something sensible" about the font.
@simoncozens I've just pushed a port of googlefonts/name/rfn. This seems to work. But it still gets me dizzy to access these strings in such a convoluted way. I feel that I may be writing dumb code here and that there must be a simpler, more elegant way of doing it.
Now I'm working on starting to port code-tests.
@simoncozens I've just pushed a port of googlefonts/name/rfn. This seems to work. But it still gets me dizzy to access these strings in such a convoluted way. I feel that I may be writing dumb code here and that there must be a simpler, more elegant way of doing it.
No, the Skrifa interface to name table strings is just very boring. read-fonts and skrifa are both very low-level and close to the binary for speed reasons, but it is a pain in the neck for users. We should just add a utility method on TestFont
to turn the name table entry into a string.
yes, I noticed that this was running very slow when I ran some tests.
@simoncozens please take a look at my initial drafting of code-test helper functions at https://github.com/simoncozens/fontspector/pull/10/commits/f8570eaa589c20a86db6744a286f313e350eeeac
I'll later refactor them out into a helper CodeTesting class.
I would really like to reduce the overall number of checks by combining things which check the same thing. e.g. while we're looking at the description string, we can also look if it has a line break at the end.