No need
No need
Posted Oct 15, 2009 20:20 UTC (Thu) by ncm (guest, #165)In reply to: Re: Only Novell will get sued by AlexHudson
Parent article: Monomania (Tux Deluxe)
Posted Oct 15, 2009 20:48 UTC (Thu)
by drag (guest, #31333)
[Link] (20 responses)
Luckily the next java version will be fully open source, I believe.
Posted Oct 16, 2009 1:34 UTC (Fri)
by mikov (guest, #33179)
[Link] (19 responses)
Posted Oct 16, 2009 3:18 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (18 responses)
Posted Oct 16, 2009 4:17 UTC (Fri)
by mikov (guest, #33179)
[Link] (17 responses)
Posted Oct 16, 2009 4:42 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (16 responses)
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:
Posted Oct 22, 2009 9:01 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (14 responses)
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"
Posted Oct 22, 2009 16:47 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
Posted Oct 22, 2009 17:50 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link]
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)
Posted Oct 22, 2009 16:58 UTC (Thu)
by mikov (guest, #33179)
[Link] (11 responses)
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.
Posted Oct 22, 2009 17:28 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
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.
Posted Oct 22, 2009 18:27 UTC (Thu)
by mikov (guest, #33179)
[Link]
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.
Posted Oct 22, 2009 17:44 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (8 responses)
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.
Posted Oct 22, 2009 18:16 UTC (Thu)
by mikov (guest, #33179)
[Link] (7 responses)
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)
Posted Oct 22, 2009 18:54 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (6 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)
> Speaking about Linux font rendering: in the case I described the
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
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
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/
> About the Java font rendering bugs - I am not aware of those, but I
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.
Posted Oct 22, 2009 19:48 UTC (Thu)
by mikov (guest, #33179)
[Link] (5 responses)
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
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
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
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.
Posted Oct 22, 2009 20:28 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (4 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
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
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
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
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
The AA settings let you choose a point between the two curbs on
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)
Posted Oct 23, 2009 0:48 UTC (Fri)
by mikov (guest, #33179)
[Link] (3 responses)
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
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
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
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
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
You are missing my point, perhaps because we are talking about two separate issues. These are conflicting goals:
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.
Posted Oct 23, 2009 1:13 UTC (Fri)
by mikov (guest, #33179)
[Link] (1 responses)
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?
Posted Oct 23, 2009 6:04 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
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.
Posted Oct 23, 2009 6:16 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
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
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)
No need
No need
BTW, I am have found some minor incompatibilities, but it is almost certainly good enough.
No need
No need
No need
No need
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
No need
No need
No need
No need
No need
No need
No need
No need
> 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.
> with disabled anti-aliasing and compare. These are facts.
> 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?
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_...
> 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
> 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)
> proved subjective time and time again
>> 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.
> 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).
No need
> any desktop-related problems are non essential.
http://www.stixfonts.org/
> 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.
> by definition subjective then there is nothing to discuss.
> a small two-color display should be a solved problem.
> of anti-aliasing.
http://damieng.com/blog/2007/06/13/font-rendering-philoso...
No need
> 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]
> the level expected today, or it isn't, and comparisons of font rendering
> are irrelevant
> rendering you think is obviously better is not acceptable either. So
> don't pretend it's an objective statement.
> 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.
> 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.
> 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)
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.
No need
http://antigrain.com/research/font_rasterization/
No need
No need
> samples in a blog post. I don't care what they say. I am talking about
> delivering working products to paying customers... :-)
> 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.