See the recent follow-up on the changes to the font family name on Catalina and changes needed at the JRE level to support proper kerning.
Starting from OS X El Capitan (10.11), there’s a new default system font in town – San Francisco. And it came with a very big underlying change, as detailed by Craig Hockenberry:
Apple has started abstracting the idea of a system font: it doesn’t have a publicly exposed name. They’ve also stated that any private names are subject to change. These private names all begin with a period: the Ultralight face for San Francisco is named “.SFNSDisplay-Ultralight”. To determine this name, you need to dig around in the font instances returned by NSFont or UIFont; it’s not easy by design.
The motivation for this abstraction is so the operating system can make better choices on which face to use at a given weight. Apple is also working on font features, such as selectable “6” and “9” glyphs or non-monospaced numbers. It’s my guess that they’d like to bring these features to the web, as well.
Even though the underlying .otf files are still in /System/Library/Fonts, San Francisco is no longer exposed via the regular APIs that web and desktop developers have grown used to. Specifically for Swing developers (of which there may not be many, so at some point it will kind of take care of itself), passing “San Francisco” to the Font constructor ends up using the previous default – Lucida Grande.
JavaFX is already doing the right thing, using San Francisco as the default UI font on El Capitan and Sierra. Swing’s legacy is to have each look-and-feel decide which font to use, and I was expecting the “System” look-and-feel which maps to Aqua to be using the right font family on the latest OS releases. That is not the case as I’m writing this entry, and Swing apps on both El Capitan and Sierra are still using Lucida Grande on both 8u112 and 9-ea.
Last week Phil Race pointed me to this issue that tracked syncing up the internal implementation details of glyph mapping between JavaFX and AWT. That issue has been fixed in early access builds of JDK 9, and is slated to be available in JDK 8 u152 scheduled for October 2017. At the present moment there is no public API to get either a name or a font instance itself that will be mapped to Lucida Grande on 10.10 and earlier, and to San Francisco on 10.11 and 10.12. The only available solution is quite brittle as it depends on the internal naming conventions exposed by the underlying OS:
- .Helvetica Neue DeskInterface on El Capitan (10.11)
- .SF NS Text on Sierra (10.12)
Note that you need a leading dot in both cases, and that this only works on early access builds of JDK 9 at the moment:
In this screenshot the second button is using new Font(“.SF NS Text”, Font.PLAIN, 24) while the rest are rendered with Lucida Grande. The most noticeable differences are in the curvy strokes of “e”, “g”, “5” and “9”, as well as the straight leg of “a”.
Ideally, there’d be an officially supported way to use the right font on OS X / macOS, either in a form on some kind of a static Font API or a synthetic font family that maps to the underlying system font on all supported platforms. Phil has filed a bug to track the progress on that front.
The latest weekly drop of JDK 7 (b57) has finally exposed the functionality of translucent and shaped windows as publicly supported APIs on the java.awt.Window class. Bug 6802853 has tracked the progress of exposing these APIs previously available in 6u10+ in the internal com.sun.awt.AWTUtilities class, and it’s time to update the examples to use the new public APIs.
To recap, here are the previous entries that used the AWTUtilities class:
All the source files referenced in these examples have been updated to use the new Window APIs, and here is a brief overview of the relevant API signatures:
- AWTUtilities.isTranslucencySupported(Translucency) is now GraphicsDevice.isWindowTranslucencySupported(WindowTranslucency).
- AWTUtilities.isTranslucencyCapable(GraphicsConfiguration) is now GraphicsConfiguration.isTranslucencyCapable().
- AWTUtilities.setWindowShape(Window, Shape) is now Window.setShape(Shape).
- AWTUtilities.setWindowOpacity(Window, float) is now Window.setOpacity(float).
- AWTUtilities.setWindowOpaque(boolean) is superceded by Window.setBackground(Color). Passing the new Color(0, 0, 0, 0) achieves the old effect of installing per-pixel translucency.
You can see the Javadocs of the new Window methods in the corresponding Mercurial diff, or in the source archive bundled with the b57 installer.
Note that the com.sun.awt.AWTUtilities class is still there, and calling its API methods still produces the correct visuals. A quick look at the implementation reveals that the AWTUtilities methods do not (yet) go directly to the new Window methods, perhaps converging deeper in the AWT internals.
Following the announcement of Google App Engine for Java, it’s interesting to see how Sun and Google differ in their analysis of market trends. Traditionally, Sun has three main “versions” of Java:
- Java Standard Edition (SE) for desktop applications
- Java Enterprise Edition (EE) for server side
- Java Mobile Edition (ME) for phones
With JavaFX, the new (and perhaps belatedly rediscovered) focus on client side market has three versions:
- Desktop profile
- Mobile profile
- TV profile
with a common profile that aims to write an application once, and have it run on all three types of displays – and the history will tell how well that will be supported and used in practice.
What about Google? This is how i see it:
- GWT is Java Web Edition (WE)
- Android is Java Device Edition (DE)
- App Engine is Java Cloud Edition (CE)
and no stated goal (at least yet) to provide a common edition for GWT and Android.
A few hours ago an interesting changelist has made its way into the JDK 7 Swing branch. It definitely looks like the Nimbus designer will be available as part of JDK 7.
Unfortunately, it does look like this changelist does not contain all the files that are part of Nimbus designer (see below for the walkthrough), but hopefully this will be amended in the following days. In the meanwhile, here is what i’ve been able to do:
- Click on the zip link on the changelist page and extract the contents of the zip file. I’ve saved it in the C:\JTools\jdk7-src folder.
- Create a new Eclipse project. Point to C:\JTools\jdk7-src\jdk-c5cd40f1f596\make\tools\swing-nimbus\classes as source, and add all the jars in C:\JTools\jdk7-src\jdk-c5cd40f1f596\make\tools\swing-nimbus\libs as external jars.
As i said before, it looks like the changelist is not complete, and i haven’t been able to find the main class to run the designer itself. However, you can run the partial generation of Nimbus painters to get the feel of how that phase is working. Here are the steps:
Run the org.jibx.binding.Compile class passing the following two program arguments:
- C:\JTools\jdk7-src\jdk-c5cd40f1f596\make\tools\swing-nimbus\classes\org\jdesktop\swingx\designer\Designer.jibx.xml
- C:\JTools\jdk7-src\jdk-c5cd40f1f596\make\tools\swing-nimbus\classes\org\jdesktop\synthdesigner\synthmodel\SynthModel.jibx.xml
Copy the three .template files from C:\JTools\jdk7-src\jdk-c5cd40f1f596\src\share\classes\javax\swing\plaf\nimbus to C:\JTools\jdk7-src\jdk-c5cd40f1f596\make\tools\swing-nimbus\classes\org\jdesktop\synthdesigner\generator\resources
Run the org.jdesktop.synthdesigner.generator.Generator class passing the following arguments:
- -full false
- -skinFile C:\JTools\jdk7-src\jdk-c5cd40f1f596\src\share\classes\javax\swing\plaf\nimbus\skin.laf
- -srcDir c:\temp\nimbus
- -buildDir c:\temp\nimbus
- -packagePrefix org.nimbus
- -lafName Nimbus
At this point, the c:\temp\nimbus should have the generated painter classes. Note that if you pass the -full true, the generation will fail since some of the template files (such as LookAndFeel.template) are not part of this changelist.
