[OpenJDK 2D-Dev] [PATCH FOR REVIEW] fix for fontmanager when no fonts are installed - RHBZ#862355,

Jiri Vanek jvanek at redhat.com
Thu Mar 14 07:43:22 UTC 2013 

ping?


> -------- Original Message --------
> Subject: Re: [OpenJDK 2D-Dev] [PATCH FOR REVIEW] fix for fontmanager when no fonts are installed - RHBZ#862355,
> Date: Wed, 30 Jan 2013 12:48:18 +0100
> From: Jiri Vanek <jvanek at redhat.com>
> To: Phil Race <philip.race at oracle.com>
> CC: 2d-dev <2d-dev at openjdk.java.net>
>
> Ugh, sorry for delay, I had to find some free-time to attempt 2:)
>
>
> I have kept NoFontsFound exception which is thrown out of the Win32 or x11 font manager.
> It is then cough in SunFontMAnager and fallback font is provided for OpenJDK. I must admit that my
> win32 hacks were not completely tested yet.
>
> This fallback font consists just from substitute character, and source file is maintainable via
> fontofrge. During build of jdk tff font is generated by fontforge and deployed to LIBDIR/fonts
>
> I have chosen this approach because it is providing source file. And so it can be properly tracked
> and have "opens source" (and thus avoiding possible comunity issues) and.. it can grow..
> I'm quite affraid that fontoforge dependence will be unacceptable for openjdk:( If so, then direct
> tff file can be provided.
> The "just substitute character" font should avoid any license issues, but if acceptable - on
> fontforge page are several BSD-like licensed - fonts http://fontforge.org/sfds/
> Some of those fonts can be used instead if license is ok.
>
> Makefile changes are not complete as I will continue work on them according to your wishes.
>
> http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/noFontsFound/v2/webrev/
> http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/noFontsFound/v2/webrev.zip
>
> Still some work awaiting, and I'm looking forward for feedback!
>
> Best regards
> J.
>
>
> On 11/27/2012 01:26 AM, Phil Race wrote:
>> 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/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>
>
>

More information about the 2d-dev mailing list