API review "RT-30861: Add simple Font factory method for a default font of a different size"
Richard.Bair at oracle.com
Mon Jun 3 11:40:55 PDT 2013
I agree these would be useful. The reason I filed this particular issue is that whenever I'm writing some code it seems like I'm always reaching for Font.font(size) and when I don't find it there I have to figure out what to pass as the family (it turns out I could have passed null but didn't know it, so I had the longer incantation). Having to always derive is also just an extra level of oomph that in many cases I don't really want to do.
Unless Font.font(size) is one day going to be "the wrong thing" and by baking it in I'm creating a new error mode, I'd just add it as it will add no weight and would at least be there when I reach for it. As long as one day it won't be "the wrong thing"…
Anyway, if it is going to take more than a few minutes to figure out, best to punt on this rather than soak up Felipe's precious time.
On Jun 3, 2013, at 11:26 AM, David Grieve <david.grieve at oracle.com> wrote:
> 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.
> 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:
>> 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
>> Phil Wrote
>>> I keep having to type this:
>>> text.setFont(Font.font(Font.getDefault().getFamily(), 81));
>>> I would prefer just:
>>> 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:
>> 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).
More information about the openjfx-dev