[OpenJDK 2D-Dev] [PATCH FOR REVIEW] fix for fontmanager when no fonts are installed - RHBZ#862355,
Phil Race
philip.race at oracle.com
Tue Nov 27 00:26:47 UTC 2012
I'd like to find something to make this more survivable, but
my main point is that having only Font.createFont() work and not system
fonts
is a configuration not worth supporting. Its too fragile.
Your suggestion below makes it less fragile, but its still not widely
useful.
If no one calls Font.createFont() in time, none of this will help.
If the problem is "just" fontconfig then perhaps we can add a filesystem
search of well known locations as a fallback. Once upon a time that was
more or less all we had .. before fontconfig came along. This is independent
of Font.createFont() as a solution. That code is still there but I'm not
sure if its still being kicked in if fontconfig is present and fails.
Also its list of locations to search may have become dated ..
But if there are absoutely zero fonts - and no one calls Font.createFont()
early, there's still a problem.
Shipping a default font with the JRE is the only answer to that.
Seems like that's going to be awkward in the short term as we'd
need to find a font that could be stored in the OpenJDK repo to
be included automatically by the build and it would have to be
one that satisfies Oracle's lawyers as OK to include.
But distros could do whatever makes sense and the missing piece
is to have the JRE look for this default font. The logic in
SunFontManager needs to have something in the isOpenJDK() branch
to check for a system property (perhaps) to fill in defaultFontFileName etc.
-phil.
On 11/19/2012 3:47 AM, Jiri Vanek wrote:
> Not sure if last email was final refuse ;) - I would like to continue
> in fixing this. From current "trialogue" I guess I have several
> possible ways of fixing it -
> - Add another font-manager, which will be possible to enable via
> sun.font.fontmanager
> - add command line switch which will "enable" "my fix"
>
> Or what about this approach:
> - when createFont(f) is called, and no fonts are found, then use this
> font as default font.
>
>
> Do you have any preferences for any of above approaches or do you
> really want idea behind this patch to be scratched away from table?
>
> Thank you very much for already given feedback,
> Best regards,
> J.
>
> On 11/13/2012 03:47 PM, Jiri Vanek wrote:
>>
>> Thank you both for valuable feedback,
>>
>> Yes, this was very straight-forward fix, but also the less harmful. I
>> tested it quite heavvily, and
>> it does not move failure to "just later". Jre is working pretty find
>> (as all calls to
>> FontManagerFactory are returning this stub, which is making its job
>> quite fine:)
>> This fix was really intended for small (but maybe bigger then we
>> think) group of headless devices,
>> where openjdk have its place. Such a device can have pretty good
>> output eg via html, but no need for
>> fonts at "server" at all. This headless device will definitely have
>> no need for fonts at all.
>> Except eg generating captcha which can be exactly the usage you have
>> described.
>>
>> However your contra-usecase with misconfigured system or JRE is more
>> then true, and I agree with
>> it. The workaround for user, to provide his ttf as default font can
>> be maybe best solution.
>>
>> The approach of OracleJDK is well known to me - It have its default
>> fonts. In world of opensource
>> the fonts were always little bit painful topic, but still this
>> solution may be working to.
>>
>> Anyway both solution above are workarounds and does not fix the
>> issue that createFont(or even most
>> of jre) should work no meter what fonts are installed.
>>
>>
>> Another suggested patch was make it configurable - but then it
>> already is, as one can easily provide
>> custom font manager via sun.font.fontmanager property. Then we can
>> maybe make life little bit more
>> easier by adding such "improved" fontmanager implementation.
>>
>>
>> I'm sorry for providing just linux implementation, but linux is
>> probably target platform in such a
>> devices. It was also serving as proof of concept. I'm definitely
>> going to implement this also for
>> win/mac when possible solution will be clarified.
>>
>> Currently I'm definitely for adding NoFontsFound exception (better
>> then NullPointException, and
>> maybe extend it also for case that this Array have 0 length[just idea
>> during writing]?), and think
>> little bit more about it.
>> Although I still like "my approach" the most, I'm going to obey
>> yours advice but I still believe
>> this issue is worthy to be fixed.
>>
>> Best regards,
>> J.
>>
>>
>>> 2012/11/12 Phil Race <philip.race at oracle.com
>>> <mailto:philip.race at 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.race at oracle.com
>>> <mailto:philip.race at oracle.com>
>>> <mailto:philip.race at oracle.com <mailto:philip.race at 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>
>>> <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 <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/
>>>
>>> Please, support open standards:
>>> http://endsoftpatents.org/
>>
>
More information about the 2d-dev
mailing list