<div class="gmail_extra">2012/11/12 Phil Race <span dir="ltr"><<a href="mailto:philip.race@oracle.com" target="_blank">philip.race@oracle.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Well this seems like a really narrow use case for an extremely rare system<br>
misconfiguration. It wouldn't help the 99.999% of apps which expect to<br>
kick off AWT or Swing.<br>
<br>
And can you ensure that nothing in the app, or in the implementation makes<br>
the (reasonable) expectation that there are other fonts installed ?<br>
The most you could do is render to a BufferedImage or similar using the explicitly<br>
loaded font. The default logical font installed on a SG2D will be backed by a non-existent<br>
physical font, so you'd need to swap that in sooner rather than later.<br>
<br>
At some point you have to say that if JRE or system components are missing,<br>
then the source of the problem is what you should fix rather than make the<br>
JRE work around it.<br>
<br>
If you do want to try something, then in this case you get a much more usable<br>
runtime by providing a default font that the JRE can ensure is available so<br>
that the other 99.999% of apps can get by.<br>
<br>
The "Oracle" JDK gets by in this case precisely because it has a real physical font<br>
to fall back on.<br>
<br>
-phil.<br><div class="im"></div></blockquote><div><br><br>Hi Phil,<br><br>I'm thinking here of Headless or embedded devices where the full Swing/AWT support may not be needed. <br><br>Anyway, I see your point that those cases are definitely the minority and if OpenJDK doesn't want to work on those system, then I can only say that whoever is going to have such use case can just apply this patch and live with it.<br>
<br>I totally agree however that if this comes from a misconfiguration rather than a conscious decision the JDK should probably protect itself by failing earlier (it will fail anyway, as you noted though).<br><br>Perhaps a better patch would be to allow this to be configurable, by still introducing this new FontManager but making it a named class and allow this as an option, defaulting on the old behaviour, and at the same time giving a better error message.<br>
<br>Also, like you suggest, ship a fallback in jre/lib/fonts sound a better idea in most cases.<br><br>Cheers,<br>Mario<br> <br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
On 11/12/2012 12:29 PM, Mario Torre wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
Hi Phil,<br>
<br>
I believe that the underlying problem here is that it should be legal to create a font from a file, even if the FontManager doesn't have any fonts installed.<br>
<br>
So, code like the one in the example:<br>
public class Test {<br>
public static void main(String[] args) throws Exception {<br>
Font.createFont(Font.TRUETYPE_<u></u>FONT, new File("example.ttf"));<br>
}<br>
}<br>
<br>
When passed a real, valid font (example.ttf in this case) would still fail with the old code, and instead would work with the given patch (at least, I think this is the idea here, Jiri can probably explain in more details his intentions?).<br>
<br>
Cheers,<br>
Mario<br>
<br>
<br></div>
2012/11/12 Phil Race <<a href="mailto:philip.race@oracle.com" target="_blank">philip.race@oracle.com</a> <mailto:<a href="mailto:philip.race@oracle.com" target="_blank">philip.race@oracle.com</a><u></u>>><div>
<div class="h5"><br>
<br>
Hello Jiri,<br>
<br>
Doesn't this just move the point of failure to a bit later ?<br>
I can't see how having zero fonts on the system is survivable for an<br>
app that uses fonts. That's the principal reason we haven't tried<br>
to do something like this already.<br>
<br>
When facing system configuration issues maybe we just need to<br>
print a better message for the exception such as<br>
throw new InternalError("Can't find any fonts installed on this<br>
system.");<br>
<br>
Or make the default font more configurable and distros could ship<br>
one in jre/lib/fonts.<br>
<br>
BTW it appears you are only trying to solve the problem for<br>
Linux/Unix.<br>
Nothing for Windows or OS X.<br>
<br>
-phil.<br>
<br>
<br>
On 11/12/2012 10:07 AM, Jiri Vanek wrote:<br>
<br>
Hi!<br>
<br>
This is attempt to fix<br>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=862355" target="_blank">https://bugzilla.redhat.com/<u></u>show_bug.cgi?id=862355</a><br>
The patch is introducing new exception<br>
src/share/classes/sun/font/<u></u>NoFontsFoundException.java, which<br>
is thrown from<br>
/src/solaris/classes/sun/awt/<u></u>X11FontManager.java instead of<br>
null pointer exception when no fonts are found on system.<br>
Exception is then catch in<br>
src/share/classes/sun/font/<u></u>FontManagerFactory.java, and in<br>
this case it returns (and not caching the instance of it)<br>
dummy font manager instead of continue in failure.<br>
the dummy manager do nothing, except that it is able to create<br>
java.awt.Font in same way as SunFontManager is doing, but is<br>
not doing any caching.<br>
<br>
To avoid duplicate code with<br>
src/share/classes/sun/font/<u></u>SunFontManager.java, i have<br>
extracted code from method createFont2D to new method here -<br>
prepareFont2D - which is responsible for creating font until<br>
caching..<br>
<br>
Best regards,<br>
J.<br>
<br>
webrev<br>
<a href="http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/fontProperties/" target="_blank">http://jvanek.fedorapeople.<u></u>org/oracle/jdk8/webrevs/<u></u>fontProperties/</a><br>
with test (although it will probably need some tuning and I'm<br>
not sure where is the best place for it)<br>
<a href="http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/fontProperties/test/src/nofontsreproducer/" target="_blank">http://jvanek.fedorapeople.<u></u>org/oracle/jdk8/webrevs/<u></u>fontProperties/test/src/<u></u>nofontsreproducer/</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
pgp key: <a href="http://subkeys.pgp.net/" target="_blank">http://subkeys.pgp.net/</a> PGP Key ID: 80F240CF<br>
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF<br>
<br></div></div>
IcedRobot: <a href="http://www.icedrobot.org" target="_blank">www.icedrobot.org</a> <<a href="http://www.icedrobot.org" target="_blank">http://www.icedrobot.org</a>><div class="im"><br>
Proud GNU Classpath developer: <a href="http://www.classpath.org/" target="_blank">http://www.classpath.org/</a><br>
Read About us at: <a href="http://planet.classpath.org" target="_blank">http://planet.classpath.org</a><br>
OpenJDK: <a href="http://openjdk.java.net/projects/caciocavallo/" target="_blank">http://openjdk.java.net/<u></u>projects/caciocavallo/</a><br>
<br>
Please, support open standards:<br>
<a href="http://endsoftpatents.org/" target="_blank">http://endsoftpatents.org/</a><br>
</div></blockquote>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>pgp key: <a href="http://subkeys.pgp.net/" target="_blank">http://subkeys.pgp.net/</a> PGP Key ID: 80F240CF<br>Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF<br>
<br>IcedRobot: <a href="http://www.icedrobot.org" target="_blank">www.icedrobot.org</a><br>Proud GNU Classpath developer: <a href="http://www.classpath.org/" target="_blank">http://www.classpath.org/</a><br>Read About us at: <a href="http://planet.classpath.org" target="_blank">http://planet.classpath.org</a><br>
OpenJDK: <a href="http://openjdk.java.net/projects/caciocavallo/" target="_blank">http://openjdk.java.net/projects/caciocavallo/</a><br><br>Please, support open standards:<br><a href="http://endsoftpatents.org/" target="_blank">http://endsoftpatents.org/</a><br>
</div>