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