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. 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 >> >