API review "RT-30861: Add simple Font factory method for a default font of a different size"

[David Grieve]

I would rather see the deriveFont methods, but not as factory methods.

public Font deriveFont(double size)
public Font deriveFont(String family)

The subtle difference being that these wouldn't use "default" sizes or family names but would use whatever the font is to find the closest matching font. If there isn't a close match, then the same font would be returned. 

e.g., 
    text.setFont(Font.getDefault().deriveFont(18));
and 
    Font myFont = new Font("Verdana", 18);
    text.setFont(myFont.deriveFont("Comic Sans MS");

On Jun 3, 2013, at 2:07 PM, Felipe Heidrich <felipe.heidrich at oracle.com> wrote:

> Moving API discussion to the mailing:
> 
> Proposal:
> Add:
> Font#font(float)		- creates new font using default font family name and given font size
> Font#font(String)		- creates new font using given font family and default font size
> 
> 
> Comments:
> Phil Wrote
>> I keep having to type this:
>>   text.setFont(Font.font(Font.getDefault().getFamily(), 81));
>> I would prefer just:
>>   text.setFont(Font.font(81));
>> which would use the default font.
> 
> I think that last line was meant to be "default font family".
> All the font(..) factory methods are family based and we should
> keep it that way.
> So the new API Font.font(-81) as specified and implemented here
> is using the default family but its not necessarily getting the same
> style as the default font. Nor would it inherit any other (theoretical)
> attributes of the default font. In practice it'll all work out
> the same until the day that some platform has a bold default font
> or has something else different about the default font that can't
> be communicated solely through family.
> So some day we also need to add Font.deriveFont(..).
> 
> Felipe wrote:
> Right, the problem you pointed out would be better solved using the derive pattern:
> 
> Font.getDefault().deriveFont(newSize);
> 
> That said, the two new methods don't exclude the option of adding derive in the future.
> They are consistent with the javadoc, other factory methods, and probably good enough to make Richard happy for now.
> 
> Anyway, I will let him be the judge for that. 
> 
> Personally I would go with the 2 new methods for now and worried about derive in the future (at which time we can consider the implication of different style options such as stretch and advance typographic features).
> 
> 
> 
> Felipe
>