Freetype and subpixel rendering

So you’re saying that the FreeType amalgamation doesn’t build under Android? I’d like to fix that if possible. It would need to be fixed in the official FreeType distribution, and then re-amalgamated. If you submit a separate pull request that patches the amalgamation inside the VFLib repository (make a new branch for this) I can look at it and try to get it into FreeType.

Yes, i commented out line 152282

#if !defined(MACOS) && !defined(TARGET_OS_MAC) //typedef unsigned char Byte; /* 8 bits */ #endif

Wait, what am I thinking…

The correct fix for Android is to use the FreeType that is built in to the operating system, rather than the amalgamation! This is probably true for iOS as well, and certainly Linux.

I didnt know there was one already in Android. I dont know how to access it. If you find out, please post.

also, here’s another problem with FT & JUCE,

When using the Font' object, it tries to hold on to itsTypeface’. This means if you’re really using a hinted font underneath and do something like.

it doesn’t always work (depending on the underlying reference counting). You have to purge out the old typeface pointer. There’s no public api for this, however, i usually put my fonts in a `Style’ object. so i have now:

[code] void Style::setFontHeight(int h)
{
if (_font.getHeight() != h)
{
_font.setHeight(h);
Typeface* tf = _font.getTypeface();

        if (!tf->isSuitableForFont(_font))
        {
            _font = Font(_font.getTypefaceName(), h,
                         _font.getStyleFlags());
        }
    }
}[/code]

When the font is no longer suitable, it gets replaced. Then the cache will pick up the correct hinted version or create a new one as required.

– hugh.

That looks like a bug in Juce…your change should have been made in Font::setHeight().

Yes, almost. Although `Font::setHeight’ shouldnt immediately demand the typeface, in case you want to set the height and style one line at a time. What you need is Font::getTypefaceIfSet (or something).

nevertheless, if the changes were inside the Font class, it could do the right thing.

yes, bug in Juce. agreed :slight_smile:

I made a separate post regarding the defect:

http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=9923

This problem seems to be bigger than just setHeight()…it would come up when ANY attribute of the font changed.

How does my fix look?

My brute force method of creating a different typeface for each font height I use gets around this problem at least. Still can’t help wishing we didn’t have to resort to using FreeType though!

Jules applied this change, would you like to give it a whirl and let me know how it works out?

Thanks

JUCE is a wonderful framework. Jules deserves all the credit he can get for creating such a masterpiece.

My only beef I've ever had with JUCE... is the font rendering ;) Seriously, even with Vinn's freetype stuff, which is better but not that much, there is a LOT more to be wanted. Take this as an example:

http://www.antigrain.com/research/font_rasterization/index.html#toc0014

That example renders text even better than Photoshop (!), and it is so pretty that I almost start to cry. I don't see the reason why this should not be achievable with JUCE, and frankly I don't know where the font rendering is messed up.

To me, the difference between a great product and a professionally looking great product, has a lot to do with the font rendering quality. And if I didn't have to resort to other libraries for this, I'd be over the top :)

Best wishes for the new year!