Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Font load not detected depending on check() test string #17

Closed
ghost opened this issue Apr 23, 2015 · 7 comments
Closed

Font load not detected depending on check() test string #17

ghost opened this issue Apr 23, 2015 · 7 comments

Comments

@ghost
Copy link

ghost commented Apr 23, 2015

I'm having some trouble detecting load of the Interstate Pi fonts from Font Bureau. They have really bizarre character sets with very spotty coverage of the alphabet.

It seems that the load detection is very sensitive to the test string provided to check(). If font doesn't contain some of the test chars, its load tends to not get detected. However I've found that even in many "normal" fonts, if you set the string to something like "abdef" many fonts won't be detected with that either.

Do you have any recommendations for what kinds of test strings are most effective? I assume a mix of widths and perhaps some kerning pairs would usually be effective.

@ghost ghost changed the title Font load not detected if some check() chars aren't in font Font load not detected depending on check() test string Apr 23, 2015
@bramstein
Copy link
Owner

Thanks for the report. We've had good results with the default test string BESbswy. If the font is metric compatible with the fallback fonts it becomes harder to detect (though I've only seen a handful cases like this). Could you list a couple of fonts that are having difficulty with "abdef"? That sounds worth looking into.

I can see why Interstate PI might be troublesome. What unicode code points are those glyphs mapped to? As long as the default fallback for that code point has a very different width it should work.

@ghost
Copy link
Author

ghost commented Apr 26, 2015

I work for Font Bureau, and I haven't been able to find anyone who knows of an official charset listing for these fonts! So I had to pull them out of the fonts themselves.

Ignoring punctuation, these are the charsets for Interstate Pi:

  • One: BDEFGHILNOPQRUZ0123456789abcdefghijklmnopqrstuvwxyz
  • Two: FGHJ0123456789abdefghijklmnopqrstuwxyz
  • Three: CDEGHJKOPRXZ0123456789abcdefghijklmnopqrstuvwxyz
  • Four: Z0123456789abcdefghijklmnopqrstuvwxyz

You can see what I'm talking about. There's no set of capital letters that is in all four!

When I tried "abdef", Interstate Pi One loaded but the other three didn't.

Thanks for reminding me about the fallbacks, I had totally forgotten to set those smartly. I'll let you know what I find.

@bramstein
Copy link
Owner

Let me know how it goes. Interstate Pi does not appear to be on Webtype, so short of buying the typeface it is difficult for me to test :)

@ghost
Copy link
Author

ghost commented Apr 26, 2015

Tried it with Adobe Blank fallback and still no love. Incidently, this is BESbswy in IP One:
image

Obviously the Pi metrics should not have a problem being confused with any standard font. I can send you a copy if you want to experiment on it.

@bramstein
Copy link
Owner

That would be great, thanks!

@ghost
Copy link
Author

ghost commented Apr 26, 2015

I have had better luck with the string "aeiou" — so this is not the end of the world, but I am still curious why missing characters in the font seems to kill it.

@ghost ghost closed this as completed Apr 26, 2015
@ghost
Copy link
Author

ghost commented Apr 26, 2015

I must not have cleared my cache or something, because the fonts I thought weren't loading now do. So when used as designed, with a test string that is well supported by the font in question, it seems to be reliable. Sorry to bother you.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant