Ok.
One other thing about deriveFont() from the CSS perspective. If Font had a
FontWeight getFontWeight() and a FontPosture getFontPosture(), then I wouldn't
need deriveFont(). One of the problems is dealing with font-weight: bolder and
font-weight: lighter, and getFontWeight() would go a long way to solving that.
I'd appreciate knowing the dervieFont bug number, or please add me as a watcher.
On Jun 3, 2013, at 6:35 PM, Felipe Heidrich <felipe.heidr...@oracle.com> wrote:
> 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 <david.gri...@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.
>>>>
>>>> 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.heidr...@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
>>>>>
>>
>
