Re: Should ATS APIs used for Font.creatFont() be dropped ?

[neugens.limasoftware@gmail.com]

Hi Phil,

This sounds a great idea (go for simplification!)

I would personally avoid to keep the code commented out though, I find this always very confusing, what about just deleting it and adding the rationale in the bug entry?

Mario

----- Reply message -----
Da: "Phil Race" <philip.race at oracle.com>
Data: ven, ott 7, 2011 20:24
Oggetto: Should ATS APIs used for Font.creatFont() be dropped ?
A: <macosx-port-dev at openjdk.java.net>

PS. In the absence of any informed view to the contrary, I suggest we should
delete the calls to loadFileFont so that created fonts go via the 
cross-platform rasteriser
which is what I think happens on Windows too,  but keep the native code 
loadFileFont itself,
commented out, so that it can be seen and resurrected as necessary.

-phil.

On 10/7/11 3:22 PM, Phil Race wrote:
> I just looked at
> http://java.net/jira/browse/MACOSX_PORT-365
>  GraphicsEnvironment.registerFont() returns 'false'
>
> The basic reason for the failure is that the font is already
> registered by createFont() .. so explicitly registering it
> fails as already registered.
>
> That's easy enough to fix for the PFB font but for a TTF font
> there's the wrinkle that unlike the PFB font its being successfully
> loaded via a native call to ATS. That also somehow causes the font to be
> registered.
>
> I suppose we could try to fight whatever makes that automatically
> registered.
>
> But I also think we'd need to make sure that fonts used in this way
> but not registered are properly GC'd .. I am not sure if that is
> happening right now.
>
> But is the ATS code worth keeping? loadFileFont() only used for
> Font.createFont()?
>
> -phil.
>
>