Simplify font situation to make it possible to use vanilla JRE trees#4639
Simplify font situation to make it possible to use vanilla JRE trees#4639benfry merged 2 commits into
Conversation
This makes it easier to run Processing with a custom or globally installed copy of the the VM, where before Processing wouldn't start because of missing fonts (font sadness). This proposal would add a second copy of the fonts to the Linux tar-ball, and fall back to this one as a last resort. I have only tested registerFont() on Linux, where it seems to be working (Font in TextAreaPainter.updateAppearance does not fall back to monospaced). On OS X this does not seem to work currently (UnsatisfiedLinkError: sun.font.FreetypeFontScaler.initIDs).
|
Hopefully that "resetting" message is what I ran into before, and not realizing the source of the problem, I just backed out the |
Sorry, something went wrong.
|
Fingers crossed! |
Sorry, something went wrong.
|
Just checked in a change to ensure that the mono font loads. Can you try it and see if that gets rid of the "resetting" message? |
Sorry, something went wrong.
|
It does indeed. Thanks a ton! |
Sorry, something went wrong.
|
Great; that's a good sign, at least... |
Sorry, something went wrong.
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sorry, something went wrong.
This has only been lightly tested on OS X and ARM Linux. The createFont function could be also simplified in the future by mandating all custom files to be placed in shared/fonts.
Note: this still prints "Source Code Pro not available, resetting to monospaced" (and will change preferences.txt accordingly). This seems to be because the first
createFont("SourceCodePro-Regular.ttf")only comes after the call toupdateAppearance(). (The Source Sans Pro fonts are instead created & registered before theupdateAppearance()).Will be busy with real life the next week, but I can look some more into this next weekend!