No need

Posted Oct 16, 2009 3:18 UTC (Fri) by rahulsundaram (subscriber, #21946)
In reply to: No need by mikov
Parent article: Monomania (Tux Deluxe)

OpenJDK in Fedora is certified by TCK to be 100% compliant. So if there are problems with applications, either the application is buggy or tck needs more tests

http://java.dzone.com/news/red-hats-icedtea-project-power

No need

Posted Oct 16, 2009 4:17 UTC (Fri) by mikov (guest, #33179) [Link] (17 responses)

I remember seeing two problems. One was related to SSL, and the other to font rendering. The latter is understandable, naturally, but it still should be acknowledged. The former is a bit more troublesome - alas I didn't have time to investigate it, but I noted that the application wouldn't work.

No need

Posted Oct 16, 2009 4:42 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (16 responses)

Perhaps you can file bug reports or let me know the application names.

No need

Posted Oct 17, 2009 2:30 UTC (Sat) by mikov (guest, #33179) [Link] (15 responses)

The font rendering is obvious in Swing applications, in IntelliJ IDEA specifically. It looks different and arguably worse when run under OpenJDK. As I said, that is understandable and perhaps even desirable because it is more consistent with font rendering in native apps, but it does look visibly different from Java applications on Windows. Arguably, that breaks Java's promise of portability.

The more serious SSL problem was seen in an app developed by our company. I am not an expert in SSL or its Java implementation so I can't make head or tails of it. It is in a straight forward call to HttpURLConnection.connect(). This is the stack trace:

javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error:
    java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1611)
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1574)
    at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1557)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1150)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1127)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
    .....
Caused by: java.lang.RuntimeException: Unexpected error: 
   java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:75)
    at sun.security.validator.Validator.getInstance(Validator.java:178)
    at sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:129)
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:225)
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:270)
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:973)
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:142)
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:533)
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:471)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:904)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1116)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143)
    ... 31 more
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
    at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120)
    at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104)
    at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:73)
    ... 42 more

No need

Posted Oct 22, 2009 9:01 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (14 responses)

Java font rendering is crap (probably one of the main reasons it never went anywhere on the desktop). The sooner the openjdk people manage to extirpate all traces of the old SUN font code from openjdk, and switch to normal font libraries (fontconfig, pango, cairo, which *have* proven themselves in major desktop apps like Firefox), the better it will be.

Right now most Linux font bugs read like "it works great in GNOME, so-so in KDE/QT (because it lags pango/cairo in adoption of new font features), it is broken in OO.o (because it inherited from SUN custom text rendering libs, and has not finished migrating to cairo yet), and hopeless in Java"

No need

Posted Oct 22, 2009 16:47 UTC (Thu) by nye (subscriber, #51576) [Link] (1 responses)

I can't recall ever noticing any difference in font rendering between GTK and Qt apps, besides perhaps the choice of default font (so not actually a rendering issue). In what way might the fonts in Qt applications be worse?

No need

Posted Oct 22, 2009 17:50 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

Typically, support of new OpenType features and Unicode processing in languages that use non-trivial scripts (ie not English). QT usually lags some behind gtk/cairo.

Rendering is only a very small part of text/font support. Since both GTK and QT use freetype for rendering (but differ higher up in the stack) you won't see rendering differences on the same system (with the same system-wide freetype)

No need

Posted Oct 22, 2009 16:58 UTC (Thu) by mikov (guest, #33179) [Link] (11 responses)

Java font rendering looks fine to me, and anyway the really important thing is that it looks the same everywhere.

Secondly, font rendering in Linux, with what you call "normal libraries" has some pretty serious problems. For example it looks absolutely horrible without anti-aliasing and small font sizes.

I understand why Sun's font rendering has to be replaced, but we can't pretend that the above two problems don't exist.

No need

Posted Oct 22, 2009 17:28 UTC (Thu) by nye (subscriber, #51576) [Link] (1 responses)

>For example it looks absolutely horrible without anti-aliasing and small font sizes.

That's not so much the rendering, as the fonts (and the patent issue, in cases where you have well-hinted fonts but are stuck with the autohinter). Open-source fonts are all designed to be heavily anti-aliased, so they aren't well hinted.

I use Microsoft fonts and enable antialiasing for point sizes < 8 and > 14, and I'm very happy with the result as long as I blacklist a handful of fonts that I hate but can't uninstall for silly package dependency reasons.

If you're hoping for better rendering at size 6 with no anti-aliasing, then you'd better have some extraordinarily well-hinted fonts I think, and the patented bytecode interpreter enabled.

No need

Posted Oct 22, 2009 18:27 UTC (Thu) by mikov (guest, #33179) [Link]

I am not really complaining about regular desktop usage - my Linux desktop actually looks fine to me; although perhaps some of that is force of habit. I don't deal with visual design, so I am OK as long as it is just acceptable.

But occasionally I notice problems:

- Even though I have the Microsoft fonts, web pages in Firefox look different in Windows (and arguably better, although it is naturally subjective).

- If I disable anti-aliasing completely in the desktop it becomes really horrible. Of course there is no reason to do it, except as an experiment. But it is still depressing. Windows 2000 really looks beautiful and crisp by comparison. As I said, depressing...

- Changing the anti-aliasing settings affects page formatting. I find that very strange.

Back to my initial point, Java's proprietary font rendering exhibits none of these problems, so replacing it with Freetype, while unavoidable, nevertheless could be viewed as a disadvantage in some contexts.

No need

Posted Oct 22, 2009 17:44 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (8 responses)

The it must look the same everywhere motto is another big reason SUN desktop efforts failed. No user wants one app to look the same as on some other system he's not using. He wants it to look (and behave) the same as the other apps it uses alongside it (as another example of this judgment error, see the old pre-firefox Netscape themes that were created by marketeers that thought their widgets needed to be synched with the Netscape web site look and feel). Using -insert-other-country-name- conventions in -insert-this-country-name- is not brilliant it's incredibly stupid.

Moreover looks absolutely horrible is a subjective judgement as proved time and time again when someone posts this kind of message on a list (does not matter if it's a pro-AA or anti-AA message) and discovers half the audience disagrees with his obvious statement.

Lastly when I say crap I mean actual font rendering bugs, as in respecting Unicode rules and using OpentType fatures present in the font files.

No need

Posted Oct 22, 2009 18:16 UTC (Thu) by mikov (guest, #33179) [Link] (7 responses)

For sure Java's desktop failure was not caused by its font rendering. Memory consumption, slow app startup, non-native widgets, lack of desktop API integration, and so on, and so on. By virtue of its intrinsic design Java can never work well on the desktop.

Once you realize that Java is not primarily aimed at the desktop, having the same pixel-accurate result everywhere becomes very important again.

Speaking about Linux font rendering: in the case I described the qualification "absolutely horrible" is not subjective. It is a fact. Try rendering a small font on a black&white embedded LCD display. Or you can simply try disabling all anti-aliasing on your Linux desktop - you will also see something which is also objectively bad. Now go to Windows 2000 with disabled anti-aliasing and compare. These are facts.

Or try another experiment that always amazes me: change the anti-aliasing settings and observe the text in your browser being re-formatted :-) WTF? I am no font expert, but shouldn't the same text occupy the same space visually regardless of anti-aliasing settings?

Yes, I know, as Nye commented too, that some of this is probably mostly caused by the patented algorithm and lack of hinting, but it doesn't change the unfortunate end result.

About the Java font rendering bugs - I am not aware of those, but I believe you. Theoretically it would be best if those were simply fixed instead of replacing the entire implementation. (I realize that it is impossible due to licensing and other crap, etc)

No need

Posted Oct 22, 2009 18:54 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (6 responses)

> non-native widgets

Part of the non-native feel is non-native font rendering. Also try to explain to users why an .otf fonts that works perfectly well in other apps is rejected by the java app. At last count there were ~ 400 TTF (plain TrueType or OpenType TT) files and ~ 100 OTF (OpenType CFF) files in Fedora, with OpenType TT growing fast (TrueType is years older than OpenType CFF, so it had a lot more time to create a big font pool)

> Speaking about Linux font rendering: in the case I described the
> qualification "absolutely horrible" is not subjective. It is a fact. Try
> rendering a small font on a black&white embedded LCD display. Or you can
> simply try disabling all anti-aliasing on your Linux desktop - you will
> also see something which is also objectively bad.

This is exactly the kind of test which people think is objective and is proved subjective time and time again

> Now go to Windows 2000
> with disabled anti-aliasing and compare. These are facts.

The fact is that they are different. Which one is better is 100% subjective. Windows achieves some bitmappy effect at the cost of distorting the glyphs shapes more, and people will like it or not depending if they attach more importance to the first or the second part.

> Or try another experiment that always amazes me: change the
> anti-aliasing settings and observe the text in your browser being
> re-formatted :-) WTF? I am no font expert, but shouldn't the same text
> occupy the same space visually regardless of anti-aliasing settings?

You're not a font expert. The pixel density of a typical computer screen is not sufficient to render a vector font accurately, so the rendering algorithm needs to perform rounding on pixel lines (it is worse for CJK glyphs than for Latin, CJK computer screen rendering is horrible no matter what rendering tech you use, the pixel density is just too low. People have forgotten but before 300dpi+ laser printers it was the same mess print-side, and today's computer screens usually target ~ 100 dpi).

If you do too much rounding the glyphs lose their shape. If you don't do enough they are blurry. The AA settings let the user choose the compromise they prefer. If the computer never tried to round you'd never see the reflow you complain of. Ironically this rounding process is why you like Windows rendering so much (Microsoft uses it more heavily than Linux, and Apple less).

http://people.redhat.com/otaylor/grid-fitting/
http://damieng.com/blog/2007/06/13/font-rendering-philoso...
http://www.codinghorror.com/blog/archives/000884.html
http://typophile.com/node/34393?from=50&comments_per_...

> About the Java font rendering bugs - I am not aware of those, but I
> believe you. Theoretically it would be best if those were simply fixed
> instead of replacing the entire implementation. (I realize that it is
> impossible due to licensing and other crap, etc)

Gratuituously reimplementing stuff that was already available in perfectly fine libs instead of working on new features no one had is another reason Java failed desktop side. Anyway the point is moot, SUN does not own all the code they use for font processing (bought the rights to some piece of crap some years ago and then forgot about it), so they can't open-source it, it will never be part of openjdk, and they'll have to replace it their side too if they don't want to pay engineers to manage two different implementations.

No need

Posted Oct 22, 2009 19:48 UTC (Thu) by mikov (guest, #33179) [Link] (5 responses)

> Part of the non-native feel is non-native font rendering. Also try to
> explain to users why an .otf fonts that works perfectly well in other
> apps is rejected by the java app. At last count there were ~ 400 TTF
> (plain TrueType or OpenType TT) files and ~ 100 OTF (OpenType CFF) files
> in Fedora, with OpenType TT growing fast (TrueType is years older than
> OpenType CFF, so it had a lot more time to create a big font pool)

That is unimportant. As I said, Java is not suitable for the desktop, so any desktop-related problems are non essential. Also, I contend that the "non-native feel" of font rendering is one of the smallest problems for desktop Java. For one, Java's rendering looks very similar to Windows to my eyes, and that is where the desktop is. If everything else was fine, this would not prevent Java desktop usage.

> This is exactly the kind of test which people think is objective and is
> proved subjective time and time again

I am sorry, but that is rubbish. I am talking of a specific engineering problem - rendering text on a small embedded B&W LCD display. The output generated by the Linux standard libraries when using True Type fonts is not acceptable. There is nothing subjective there.

>> Now go to Windows 2000
>> with disabled anti-aliasing and compare. These are facts.
>
> The fact is that they are different. Which one is better is 100%
> subjective. Windows achieves some bitmappy effect at the cost of
> distorting the glyphs shapes more, and people will like it or not
> depending if they attach more importance to the first or the second
> part.

It makes no sense to press on here. Since according to you anything is by definition subjective then there is nothing to discuss. Further, if you insist on believing that non-hinted+non-antialiased _screen_ rendering in Linux is in any way superior to non-antialised _screen_ rendering in Windows (emphasis on screen, not high-DPI printer!), then there is no common ground.

However, if you try to deliver a product using that supposedly superior rendering (non-hinted, non-antialiased, small fonts), I don't expect many people would like it.

I am not talking about high quality typography here. Displaying text on a small two-color display should be a solved problem.

> You're not a font expert. The pixel density of a typical computer screen
> is not sufficient to render a vector font accurately, so the rendering
> algorithm needs to perform rounding on pixel lines (it is worse for CJK
> glyphs than for Latin, CJK computer screen rendering is horrible no
> matter what rendering tech you use, the pixel density is just too low.
> People have forgotten but before 300dpi+ laser printers it was the same
> mess print-side, and today's computer screens usually target ~ 100 dpi).
>
> If you do too much rounding the glyphs lose their shape. If you don't do
> enough they are blurry. The AA settings let the user choose the
> compromise they prefer. If the computer never tried to round you'd never
> see the reflow you complain of. Ironically this rounding process is why
> you like Windows rendering so much (Microsoft uses it more heavily than
> Linux, and Apple less).

Yes, I am familiar with the big hoopla about Apple's fonts being more blurry and the associated discussions.

I am not convinced that it is acceptable to perform reflow as a result of anti-aliasing. I am pretty sure Adobe Acrobat doesn't do that. IIRC, Apple wouldn't do that either since they are simply rendering precisely and letting anti-aliasing take care of the rest (thus the blurriness).

Also, I should note that this is not about me liking Windows rendering. It is about calling a spade a spade. Microsoft has probably invested tens of man-years into this, so it is no surprise that they would produce better results. (And licensing the patents doesn't hurt either).

I also agree that on high-DPI displays with anti-aliasing this is not an issue.

No need

Posted Oct 22, 2009 20:28 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (4 responses)

> That is unimportant. As I said, Java is not suitable for the desktop, so
> any desktop-related problems are non essential.

Do you really want to argue there is nothing wrong with java font processing when it can not even parse the default format of most new font projects? Even giant multi-year efforts such as
http://www.stixfonts.org/

Be consistent: either font processing is required, and Java is not on the level expected today, or it isn't, and comparisons of font rendering are irrelevant

> I am sorry, but that is rubbish. I am talking of a specific engineering
> problem - rendering text on a small embedded B&W LCD display. The output
> generated by the Linux standard libraries when using True Type fonts is
> not acceptable. There is nothing subjective there.

And many people commented on the links I posted that the Windows font rendering you think is obviously better is not acceptable either. So don't pretend it's an objective statement.

> It makes no sense to press on here. Since according to you anything is
> by definition subjective then there is nothing to discuss.

That windows achieves "crispness" at the cost of distortion its not subjective it's a fact that can easily be checked (and has been by many people). What's subjective is the right balance between "crispness" and "no distortion". It's a compromise ie there is no 100% good solution.

> I am not talking about high quality typography here. Displaying text on
> a small two-color display should be a solved problem.

It should be but it is not. Even MS continues to invest heavily in font processing tech. So obviously they disagree with you on the "solved" part.

The only solution everyone agree would work would be to increase pixel density just like happened video-side for hd video.

> I am not convinced that it is acceptable to perform reflow as a result
> of anti-aliasing.

The AA settings let you choose a point between the two curbs on
http://damieng.com/blog/2007/06/13/font-rendering-philoso...

Of course it will cause reflow. That's obvious math. If you don't want reflow do not allow changing the settings (your font processing won't be any better quite the contrary but you'll have hidden an un-obvious, for laymen, side-effect of grid-fitting)

No need

Posted Oct 23, 2009 0:48 UTC (Fri) by mikov (guest, #33179) [Link] (3 responses)

> Do you really want to argue there is nothing wrong with java font
> processing when it can not even parse the default format of most new
> font projects? Even giant multi-year efforts such as
> http://www.stixfonts.org/[1]

No. As I said, I believe you when you you say that there are problems. I thought we agreed that it is a moot point because it _has_ to be replaced anyway.

I am pointing out that the move to Freetype, while necessary and unavoidable, and while improving some things (as you are saying), worsens others.

I see a kind of complacency with the state of Linux font rendering, while it has clear shortcomings in some aspects.

> Be consistent: either font processing is required, and Java is not on
> the level expected today, or it isn't, and comparisons of font rendering
> are irrelevant

I am consistent. For my purposes (mostly embedded development) the current state of closed source Java font rendering works better than Freetype. Additionally, since I believe that Java has no future on the desktop, the problems you are describing are not that critical.

> And many people commented on the links I posted that the Windows font
> rendering you think is obviously better is not acceptable either. So
> don't pretend it's an objective statement.

I am not talking about random people commenting on random font rendering samples in a blog post. I don't care what they say. I am talking about delivering working products to paying customers... :-)

Windows font rendering is objectively and undeniably better at low resolutions without anti-aliasing. To deny that fact out of misguided open source loyalty is to prevent improvement in that same open source.

> That windows achieves "crispness" at the cost of distortion its not
> subjective it's a fact that can easily be checked (and has been by many
> people). What's subjective is the right balance between "crispness" and
> "no distortion". It's a compromise ie there is no 100% good solution.

No one is arguing with that. However you seem to assume that typographically correct rendering is always required or even preferable on a computer screen. When that screen is low DPI and low color, crispiness is all that matters.

Secondly, while there is no 100% good solution, it is enough to try reading this very page without anti-aliasing on Windows and Linux, to become convinced which solution is at least better. And I am saying this after having worked exclusively with a Linux desktop for many years - so my brain has been trained to like the Linux kind of rendering. Believe me, I eally want to like Linux better :-) But for now the path for that is to really make it better, rather than convince myself that wrong is right...

> It should be but it is not. Even MS continues to invest heavily in font
> processing tech. So obviously they disagree with you on the "solved"
> part.
>
> The only solution everyone agree would work would be to increase pixel
> density just like happened video-side for hd video.

I hear you... I am typing this on a huge monitor with huge fonts and I have to say the fonts in Linux look lovely...

> The AA settings let you choose a point between the two curbs on
> http://damieng.com/blog/2007/06/13/font-rendering-philoso...
>
> Of course it will cause reflow. That's obvious math. If you don't want
> reflow do not allow changing the settings (your font processing won't be
> any better quite the contrary but you'll have hidden an un-obvious, for
> laymen, side-effect of grid-fitting)

You are missing my point, perhaps because we are talking about two separate issues. These are conflicting goals:
a) Crisp rendering without anti-aliasing at small sizes. It is by definition typographically incorrect, but more readable.
b) Accurate sub-pixel rendering, even at the expense of readability (typically at smaller sizes). Since it is accurate, it will not affect reflow. For example, Adobe Acrobat works this way.

I want and need both a) and b), with a way to control when I get which. The problem is in Linux out of the box I get neither! I get both ugly fonts without anti-aliasing, and I get inconsistent reflow with anti-aliasing.

No need

Posted Oct 23, 2009 1:13 UTC (Fri) by mikov (guest, #33179) [Link] (1 responses)

Sorry for replying to myself, but I think this article is a worthwhile complement to my point:
http://antigrain.com/research/font_rasterization/

It show how the current state of Linux font rendering is not particularly good, and how it can be improved. Has anything been done in that direction?

No need

Posted Oct 23, 2009 6:04 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

To the contrary it shows that the Linux font rendering is not as bad as people pretend, and that using the patented hinting process as windows does would be no silver bullet. It also points to ways to make freetype even better (according to the author).

Anyway the freetype devs are definitely aware of this article, if it's not implemented yet that's either because there is some legal problem, or xorg is missing the infra (typically xorg is terrible at color correction so gamma tricks are un-implementable on its current state), there is some other point missed in the article (for example, it would make desktop rendering unbearably slow with current drivers), or people just do not have the time to finish it up (I don't remember which case it is).

But anyway if you're interested in it I'm sure they would welcome patches.

And (to repeat myself) rasterization is only a very small part of font processing.

No need

Posted Oct 23, 2009 6:16 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

> I am not talking about random people commenting on random font rendering
> samples in a blog post. I don't care what they say. I am talking about
> delivering working products to paying customers... :-)

Typophile is not random people it's the web lair of professional font creators that need too deliver working fonts to paying customers

> No one is arguing with that. However you seem to assume that
> typographically correct rendering is always required or even preferable
> on a computer screen. When that screen is low DPI and low color,
> crispiness is all that matters.

And I contend that's a user preference, as proved by all the OMG how can I remove ugly crispy bitmap fonts post that happen every time bitmap fonts are accidentaly activated for a large user base

> I want and need both a)

BTW people seem to assume no-AA is "better", in large part because it's supposed to be faster. With modern font libs and GFX drivers, since everyone optimizes the general case users want (AA), AA rendering will be faster.

Also if you push your customers in small text at low-dpi land you'll just make non-i18n apps. Latin scripts are relatively resistant to low-dpi situations, compared to asian ones (because an ideogram for example needs higher detail density than a latin letter)