After reading all the comments I think it is best to release the code we have
already (RT-30861) and file a jira for deriveFont().
Agreed ?
On Jun 3, 2013, at 12:11 PM, Phil Race wrote:
> On 6/3/2013 11:40 AM, Richard Bair wrote:
>> 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.
>
>
> deriveFont methods are useful and interesting and eventually required, but
> came up here only to be sure that wasn't what was being asked for.
> They are somewhat more work than the simple syntactic sugar of
> font(20.0) and font("Verdana")
>
>>
>> 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"…
>
> It won't be doing the wrong thing per the proposed spec which is clear enough
>>
>> 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.
>
> I think its fine.
>
> -phil.
>
>>
>> Richard
>>
>> On Jun 3, 2013, at 11:26 AM, David Grieve <[email protected]> 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.
>>>
>>> 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 <[email protected]>
>>> 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
>>>>
>
