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

[Mario Torre]

Yep, that makes sense indeed,

Cheers,
Mario
---
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

http://www.ladybug-studio.com

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/




Il giorno 09/ott/2011, alle ore 06:24, Phil Race ha scritto:

> On 10/8/11 8:43 AM, neugens.limasoftware at gmail.com wrote:
>> 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?
> 
> Well .. the ATS code may be instructive and depending on how we merge this
> OS X port into mainline it may be absent from the mercurial history unless textually
> present. If the ATS API goes way [I think I read it was deprecated], its largely moot except
> to the extent that it should be a guide to current APIs which I sincerely
> hope provide at minimum the same functionality.
> 
> -phil
>> 
>> 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.
>> >
>> >
>> 
>> 
>> 
>