[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-2d-dev
Subject: Re: [OpenJDK 2D-Dev] [PATCH FOR REVIEW] fix for fontmanager when no fonts are installed - RHBZ#86235
From: Jiri Vanek <jvanek () redhat ! com>
Date: 2013-03-14 7:43:22
Message-ID: 51417F9A.5040003 () redhat ! com
[Download RAW message or body]
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@redhat.com>
> To: Phil Race <philip.race@oracle.com>
> CC: 2d-dev <2d-dev@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@oracle.com \
> > > > > <mailto:philip.race@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@oracle.com \
> > > > > <mailto:philip.race@oracle.com> <mailto:philip.race@oracle.com \
> > > > > <mailto:philip.race@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/>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> >
>
>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic