No need

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.