JavaFX always choose monospace font - possible bug?
I'm using a redhat 6 system with jdk 1.8u40 where the only font available is "Liberation" in all its variants, bold, italic, mono, serif, sans-serif etc. /usr/share/fonts/liberation /usr/share/fonts/liberation/LiberationSerif-Regular.ttf /usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf /usr/share/fonts/liberation/fonts.dir /usr/share/fonts/liberation/LiberationMono-Italic.ttf /usr/share/fonts/liberation/LiberationSans-Bold.ttf /usr/share/fonts/liberation/LiberationSerif-Bold.ttf /usr/share/fonts/liberation/LiberationMono-Regular.ttf /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf /usr/share/fonts/liberation/LiberationSerif-Italic.ttf /usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf /usr/share/fonts/liberation/fonts.scale /usr/share/fonts/liberation/LiberationSans-Regular.ttf /usr/share/fonts/liberation/LiberationSans-Italic.ttf /usr/share/fonts/liberation/LiberationMono-Bold.ttf When I run up a app, even without custom CSS, all the controls, textfields, buttons etc are displayed in monospaced liberation. I've debugged this using -Dprism.debugFonts Loading FontFactory com.sun.javafx.font.freetype.FTFactory Subpixel: enabled Freetype2 Loaded (version 2.3.11) LCD support Enabled Time spent accessing fontconfig=4ms. FC font sans:regular:roman maps to Liberation Mono in file /usr/share/fonts/liberation/LiberationMono-Regular.ttf 0) Family=Liberation Mono, Style=Regular, Fullname=Liberation Mono, File=/usr/share/fonts/liberation/LiberationMono-Regular.ttf 1) Family=Liberation Sans, Style=Regular, Fullname=Liberation Sans, File=/usr/share/fonts/liberation/LiberationSans-Regular.ttf 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif, File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf FC font sans:bold:roman maps to Liberation Mono Bold in file /usr/share/fonts/liberation/LiberationMono-Bold.ttf 0) Family=Liberation Mono, Style=Bold, Fullname=Liberation Mono Bold, File=/usr/share/fonts/liberation/LiberationMono-Bold.ttf 1) Family=Liberation Sans, Style=Bold, Fullname=Liberation Sans Bold, File=/usr/share/fonts/liberation/LiberationSans-Bold.ttf 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif, File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf FC font sans:regular:italic maps to Liberation Mono Italic in file /usr/share/fonts/liberation/LiberationMono-Italic.ttf 0) Family=Liberation Mono, Style=Italic, Fullname=Liberation Mono Italic, File=/usr/share/fonts/liberation/LiberationMono-Italic.ttf 1) Family=Liberation Sans, Style=Italic, Fullname=Liberation Sans Italic, File=/usr/share/fonts/liberation/LiberationSans-Italic.ttf 2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf FC font sans:bold:italic maps to Liberation Sans Bold Italic in file /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf 0) Family=Liberation Sans, Style=Bold Italic, Fullname=Liberation Sans Bold Italic, File=/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf 1) Family=Liberation Mono, Style=Bold Italic, Fullname=Liberation Mono Bold Italic, File=/usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf 2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf FC font serif:regular:roman maps to Liberation Mono in file /usr/share/fonts/liberation/LiberationMono-Regular.ttf 0) Family=Liberation Mono, Style=Regular, Fullname=Liberation Mono, File=/usr/share/fonts/liberation/LiberationMono-Regular.ttf 1) Family=Liberation Sans, Style=Regular, Fullname=Liberation Sans, File=/usr/share/fonts/liberation/LiberationSans-Regular.ttf 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif, File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf FC font serif:bold:roman maps to Liberation Mono Bold in file /usr/share/fonts/liberation/LiberationMono-Bold.ttf 0) Family=Liberation Mono, Style=Bold, Fullname=Liberation Mono Bold, File=/usr/share/fonts/liberation/LiberationMono-Bold.ttf 1) Family=Liberation Sans, Style=Bold, Fullname=Liberation Sans Bold, File=/usr/share/fonts/liberation/LiberationSans-Bold.ttf 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif, File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf FC font serif:regular:italic maps to Liberation Mono Italic in file /usr/share/fonts/liberation/LiberationMono-Italic.ttf 0) Family=Liberation Mono, Style=Italic, Fullname=Liberation Mono Italic, File=/usr/share/fonts/liberation/LiberationMono-Italic.ttf 1) Family=Liberation Sans, Style=Italic, Fullname=Liberation Sans Italic, File=/usr/share/fonts/liberation/LiberationSans-Italic.ttf 2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf FC font serif:bold:italic maps to Liberation Sans Bold Italic in file /usr/share/fonts/liberation/LiberationS
Re: Enhancements to 3D for JFX9?
> > this may mean, people who do this must work with a patched JDK in the > future. > Right. But I think that's going to be more and more common in future. If you rely on people installing proprietary stuff like JWS or applets then it's a bleak future, as the way forward is clearly bundled JREs. At some point I suspect someone will make a kind of "WebStart Next Generation" without Oracle and start distributing a custom build of OpenJDK + their own platform/distribution stuff. For example, a JRE that updates itself via Omaha on Windows would clearly be superior to Oracle's solution: https://code.google.com/p/omaha Combined with a more modern app store like approach rather than JNLP or applets and that'd be a winner, I think.
Re: Enhancements to 3D for JFX9?
On Fri, Apr 24, 2015 at 1:16 PM, Mike Hearn wrote: > this may mean, people who do this must work with a patched JDK in the >> future. >> > > Right. But I think that's going to be more and more common in future. If > you rely on people installing proprietary stuff like JWS or applets then > it's a bleak future, as the way forward is clearly bundled JREs. > > > patched != bundled. For us this would be quite a step back, having to maintain our JDK patches/builds. Bundling itself is fine in our business cases.
Re: Enhancements to 3D for JFX9?
Did you read the reply from Phil in the other thread? > There will be a -XX flag in JDK 9 that jigsaw provides to aid in the > transition. So you will not have to maintain a JDK9 build but only start with this thread to still access private APIs and this is something you can clearly control if you install the JDK with your app! Tom On 24.04.15 14:05, Robert Krüger wrote: > On Fri, Apr 24, 2015 at 1:16 PM, Mike Hearn wrote: > >> this may mean, people who do this must work with a patched JDK in the >>> future. >>> >> >> Right. But I think that's going to be more and more common in future. If >> you rely on people installing proprietary stuff like JWS or applets then >> it's a bleak future, as the way forward is clearly bundled JREs. >> >> >> > patched != bundled. For us this would be quite a step back, having to > maintain our JDK patches/builds. Bundling itself is fine in our business > cases. > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Enhancements to 3D for JFX9?
On Fri, Apr 24, 2015 at 2:19 PM, Tom Schindl wrote: > Did you read the reply from Phil in the other thread? > > > There will be a -XX flag in JDK 9 that jigsaw provides to aid in the > transition. > So you will not have to maintain a JDK9 build but only start with this > thread to still access private APIs and this is something you can > clearly control if you install the JDK with your app! > Excellent news! How could I miss that, sorry.
Re: Enhancements to 3D for JFX9?
Yes, but then read the rest of the thread. You really must not rely on the theoretical possibility of an XX flag that magically kicks all your problems down the road a year or two. The best time to get all this nailed correctly is now. That flag is not likely to be as extensive and durable as everyone is imagining. - Don On 24/04/2015 8:19 AM, Tom Schindl wrote: Did you read the reply from Phil in the other thread? There will be a -XX flag in JDK 9 that jigsaw provides to aid in the transition. So you will not have to maintain a JDK9 build but only start with this thread to still access private APIs and this is something you can clearly control if you install the JDK with your app! Tom On 24.04.15 14:05, Robert Krüger wrote: On Fri, Apr 24, 2015 at 1:16 PM, Mike Hearn wrote: this may mean, people who do this must work with a patched JDK in the future. Right. But I think that's going to be more and more common in future. If you rely on people installing proprietary stuff like JWS or applets then it's a bleak future, as the way forward is clearly bundled JREs. patched != bundled. For us this would be quite a step back, having to maintain our JDK patches/builds. Bundling itself is fine in our business cases.
Re: Enhancements to 3D for JFX9?
I agree and we are hesitant. However, if that buys you three or more years of time to either see if Oracle is making good decisions regarding things we now build using private APIs as a last resort or if all (for us) showstopping JFX bugs are fixed by then, this can be a valid option in the real world, where you have to deliver a product as opposed to now rushing into a decision to move to a different technology, because Java/JFX cannot deliver now but YMMV. It's just balancing risks on a case-by-case basis. People with complex, successful products like IntelliJ Idea are doing the exact same thing: https://github.com/JetBrains/intellij-community/search?utf8=%E2%9C%93&q=%22com.sun%22 On Fri, Apr 24, 2015 at 5:15 PM, wrote: > Of course, that flag could easily disappear in JDK10. > > Personally, I would be hesitant to rely on a feature that goes against the > direction that Oracle is taking Java. > > > Neil > > > > > From:Robert Krüger > To:"openjfx-dev@openjdk.java.net" , > Date:04/24/2015 09:36 AM > Subject:Re: Enhancements to 3D for JFX9? > Sent by:"openjfx-dev" > -- > > > > On Fri, Apr 24, 2015 at 2:19 PM, Tom Schindl > wrote: > > > Did you read the reply from Phil in the other thread? > > > > > There will be a -XX flag in JDK 9 that jigsaw provides to aid in the > > transition. > > > > So you will not have to maintain a JDK9 build but only start with this > > thread to still access private APIs and this is something you can > > clearly control if you install the JDK with your app! > > > > Excellent news! How could I miss that, sorry. > > > > > NOTICE *from Ab Initio: This email (including any attachments) may > contain information that is subject to confidentiality obligations or is > legally privileged, and sender does not waive confidentiality or privilege. > If received in error, please notify the sender, delete this email, and make > no further use, disclosure, or distribution. * -- Robert Krüger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com
Re: Enhancements to 3D for JFX9?
On Fri, Apr 24, 2015 at 5:27 PM, Donald Smith wrote: > Yes, but then read the rest of the thread. You really must not rely on > the theoretical possibility of an XX flag that magically kicks all your > problems down the road a year or two. The best time to get all this nailed > correctly is now. I understand why you are writing this and in principle I agree. But please understand that this is not about fixing sloppy programming in a college project but affects whether we can use a technology for the next few years where the problems that stop us now may have gone away or otherwise not to be able to continue our product using Java (at least until we know where Java/JFX is going) and move to something native instead throwing away huge investments. The world is just not that simple. > That flag is not likely to be as extensive and durable as everyone is > imagining. > > OK, so having to patch the JDK to access private API in Java 9 is still a possible outcome?
Re: JavaFX always choose monospace font - possible bug?
FX should just be asking fontconfig what your set up is. What do you get if you run the fontconfig command line app ? $ fc-match sans:regular:roman Vera.ttf: "Bitstream Vera Sans" "Roman" -phil. On 4/24/15 1:30 AM, Adam Granger wrote: I'm using a redhat 6 system with jdk 1.8u40 where the only font available is "Liberation" in all its variants, bold, italic, mono, serif, sans-serif etc. /usr/share/fonts/liberation /usr/share/fonts/liberation/LiberationSerif-Regular.ttf /usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf /usr/share/fonts/liberation/fonts.dir /usr/share/fonts/liberation/LiberationMono-Italic.ttf /usr/share/fonts/liberation/LiberationSans-Bold.ttf /usr/share/fonts/liberation/LiberationSerif-Bold.ttf /usr/share/fonts/liberation/LiberationMono-Regular.ttf /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf /usr/share/fonts/liberation/LiberationSerif-Italic.ttf /usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf /usr/share/fonts/liberation/fonts.scale /usr/share/fonts/liberation/LiberationSans-Regular.ttf /usr/share/fonts/liberation/LiberationSans-Italic.ttf /usr/share/fonts/liberation/LiberationMono-Bold.ttf When I run up a app, even without custom CSS, all the controls, textfields, buttons etc are displayed in monospaced liberation. I've debugged this using -Dprism.debugFonts Loading FontFactory com.sun.javafx.font.freetype.FTFactory Subpixel: enabled Freetype2 Loaded (version 2.3.11) LCD support Enabled Time spent accessing fontconfig=4ms. FC font sans:regular:roman maps to Liberation Mono in file /usr/share/fonts/liberation/LiberationMono-Regular.ttf 0) Family=Liberation Mono, Style=Regular, Fullname=Liberation Mono, File=/usr/share/fonts/liberation/LiberationMono-Regular.ttf 1) Family=Liberation Sans, Style=Regular, Fullname=Liberation Sans, File=/usr/share/fonts/liberation/LiberationSans-Regular.ttf 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif, File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf FC font sans:bold:roman maps to Liberation Mono Bold in file /usr/share/fonts/liberation/LiberationMono-Bold.ttf 0) Family=Liberation Mono, Style=Bold, Fullname=Liberation Mono Bold, File=/usr/share/fonts/liberation/LiberationMono-Bold.ttf 1) Family=Liberation Sans, Style=Bold, Fullname=Liberation Sans Bold, File=/usr/share/fonts/liberation/LiberationSans-Bold.ttf 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif, File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf FC font sans:regular:italic maps to Liberation Mono Italic in file /usr/share/fonts/liberation/LiberationMono-Italic.ttf 0) Family=Liberation Mono, Style=Italic, Fullname=Liberation Mono Italic, File=/usr/share/fonts/liberation/LiberationMono-Italic.ttf 1) Family=Liberation Sans, Style=Italic, Fullname=Liberation Sans Italic, File=/usr/share/fonts/liberation/LiberationSans-Italic.ttf 2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf FC font sans:bold:italic maps to Liberation Sans Bold Italic in file /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf 0) Family=Liberation Sans, Style=Bold Italic, Fullname=Liberation Sans Bold Italic, File=/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf 1) Family=Liberation Mono, Style=Bold Italic, Fullname=Liberation Mono Bold Italic, File=/usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf 2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf FC font serif:regular:roman maps to Liberation Mono in file /usr/share/fonts/liberation/LiberationMono-Regular.ttf 0) Family=Liberation Mono, Style=Regular, Fullname=Liberation Mono, File=/usr/share/fonts/liberation/LiberationMono-Regular.ttf 1) Family=Liberation Sans, Style=Regular, Fullname=Liberation Sans, File=/usr/share/fonts/liberation/LiberationSans-Regular.ttf 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif, File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf FC font serif:bold:roman maps to Liberation Mono Bold in file /usr/share/fonts/liberation/LiberationMono-Bold.ttf 0) Family=Liberation Mono, Style=Bold, Fullname=Liberation Mono Bold, File=/usr/share/fonts/liberation/LiberationMono-Bold.ttf 1) Family=Liberation Sans, Style=Bold, Fullname=Liberation Sans Bold, File=/usr/share/fonts/liberation/LiberationSans-Bold.ttf 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif, File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf FC font serif:regular:italic maps to Liberation Mono Italic in file /usr/share/fonts/liberation/LiberationMono-Italic.ttf 0) Family=Liberation Mono, Style=Italic, Fullname=Liberation Mono Italic, File=/usr/share/fonts/liberation/LiberationMono-Italic.ttf 1) Family=Liberation Sans, Style=Italic, Fullname=Liberation Sans Italic, File=/usr/share/fonts/liberation/LiberationSa
Re: Enhancements to 3D for JFX9?
Hi, I never proposed to rely on this feature forever but to relax the concerns raised that JDK9 is the end for useing JavaFX in new not yet explored ways and people stop using it today because it is already sure today that you won't get the API you require in your app. I've already outlined in our EclipseCon meeting with Mark and Alex how one could go for allowing none global access to not yet finished APIs without useing the big hammer -XX - Eclipse with its @noimplement and @noextend and Equinox with it's private-package exports show you ways how this could be address so that eg JavaFX could expose some of its internal stuff in JKD9. I think something like that is essential for young modules like javafx. Tom On 24.04.15 17:27, Donald Smith wrote: > Yes, but then read the rest of the thread. You really must not rely on > the theoretical possibility of an XX flag that magically kicks all your > problems down the road a year or two. The best time to get all this > nailed correctly is now. That flag is not likely to be as extensive and > durable as everyone is imagining. > > - Don > > > On 24/04/2015 8:19 AM, Tom Schindl wrote: >> Did you read the reply from Phil in the other thread? >> >>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the >>> transition. >> So you will not have to maintain a JDK9 build but only start with this >> thread to still access private APIs and this is something you can >> clearly control if you install the JDK with your app! >> >> Tom >> >> On 24.04.15 14:05, Robert Krüger wrote: >>> On Fri, Apr 24, 2015 at 1:16 PM, Mike Hearn wrote: >>> this may mean, people who do this must work with a patched JDK in the > future. > Right. But I think that's going to be more and more common in future. If you rely on people installing proprietary stuff like JWS or applets then it's a bleak future, as the way forward is clearly bundled JREs. >>> patched != bundled. For us this would be quite a step back, having to >>> maintain our JDK patches/builds. Bundling itself is fine in our business >>> cases. >>> >> > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
In(Sanity) Testing Mondays
Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks, Vadim
JDK 1.8.0 33/40, diacritics and file problems
Ok, I've run into many problems in the past with diacritics, as there were some JDK problems, but I supposed they were all fixed today. But perhaps there's something I'm not understanding. I've several files with diacritics in their name, let's say e.g. "La Cathédrale Engloutie.m4a". A catalog contains their names, and it has been prepared on Mac OS X, JDK 1.8.0_40 and saved with UTF-8 encoding. The catalog is read, of course specifying UTF-8 as encoding, on the Raspberry PI Rasbian with JDK 1.8.0_33. Everything is correct as I see the proper characters in the UI and logfiles. The problem arises when I try to open a file with diacritics (this doesn't happen with all files with diacritics in their name, only with some): I get an exception because the file name is not found (both with io and nio). Thanks to some suggestions, I made it work by passing the file name through Paths.get(Normalizer.normalize(path.toString(), NFD)). This transforms the initial encoding for the é from c3 a9 (doesn't work) to 65 cc 81. Now, first I don't understand why I have to take care of this. I'm aware that different file systems use different encodings, but I supposed that all the conversions were done by the JVM. BTW, both systems are configured with: LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 The Java system properties are: file.encoding: UTF-8 file.encoding.pkg: sun.io sun.io.unicode.encoding: UnicodeLittle (ARM) sun.io.unicode.encoding: UnicodeBig (Mac) sun.jnu.encoding: UTF-8 The files on the ARM were rsynced from the Mac. I'm not sure that LC_ALL/LANG/whatever were already set when the rsync was performed. If it's correct that I have to deal with it, is there any official documentation I can reference? BTW, I'm not aware of why the NFD normalisation is the one who works, and not one of the other three. Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it