Bug 1510 : in version 1.1 : PFont.szie not visible, bug or feature?
Last modified: 2010-06-05 03:55



Andreas F
Assigned To:

Attachment Type Created Size Actions

Description:   Opened: 2010-03-14 14:13
In 1.1 Pfont.size has become invisible while it was usable before. This
breaks a library which we are developing. I'd like to know whether this is
this a bug or a feature, so that
we can wait or change our code accordingly.

Example code:

PFont myFont;

void setup() {
myFont = createFont("FFScala", 32);

works in older versions, e.g. 1.0.8 but in 1.1 gives:
The field Pfont.size is not visible.
Additional Comment #1 From fry 2010-03-17 13:08
how are you using it? i can certainly add an accessor for it, though i
think we'll keep the variable hidden since PFont needs to be more generic
as we start expanding to other platforms (like android). for that matter,
what other parts of PFont do you need access to?
Additional Comment #2 From Andreas F 2010-03-17 14:58
This has affected our library (coming soon at:
http://www.gwoptics.org/processing/gwoptics_p5lib/) as well as the G4P library by Peter
Lager. In our case we use the font size to compute the size/distance of tick marks and labels
in a graph. Peter Lager suggested to use '_font.getFont().getSize()' to replace the formerly
used '_font.size' for obtaining the size of the currently used font.

one example use:
_parent.text(String.valueOf(_label), 0, 0.25f * _font.getFont().getSize(), 0);

That seems to work if the fonts are created with createFont(), however, I noticed that (at
least in my example) when the the font is loaded with loadFont(), the getFont() method
returns null (while _font is not null and can be used correctly with textfont). I don't understand
this, but it worries me a bit.

In summary, an accessor, without the need for using the getFont() method, would be nice.
Additional Comment #3 From fry 2010-03-22 14:43
getFont() is just for when a native version of the font is available. if
processing is able to match the native name of the font, and
hint(ENABLE_NATIVE_FONTS) is set, then it'll try to use the native version.

in that particular example, you should be using textAscent(), since it
refers to something that will be closer to the optical height to be used
for sizing. whereas the 'size' is a nebulous term that's not very useful
for typography or layout.

but are there other fields that you need access to?
Additional Comment #4 From Andreas F 2010-03-29 08:30
Sorry for the late reply. Yes, I have seen textAscent() and though about
using it in a future version for this particular line of code. Still, it
would be good to be able to get the size of the font. For the moment I
cannot think of other accessors which would be required/useful. Thanks!
Additional Comment #5 From PaulC 2010-04-26 14:05
I just compiled the latest sources and fell over problem this as well.

I was using the old attributes to pre-calculate the bounding box for some
text labels which should be mouse sensitive. If I define the size()
accessor method then I can replace my old code that calculates the text height:

return font.ascent + font.descent;


return (font.ascent() + font.descent()) * font.size();

I can do this calculation in a helper method that only has a reference to
the font. Passing in a reference to the applet so that I can set the font
and use the textAscent() and textDescent() methods would make this code a
little bit harder to follow, and using the PFont interface in this way
seems to work.

One thing that I noticed is that the textMode setting affects the
textAscent() and textDescent() calculation. If I _were_ to change my code
to use these methods then I would also need to change my width calculation
code to call textWidth(str), but the PGraphics.textWidthImpl() method
doesn't seem to take the textMode into account. Is there another problem
lurking there?
Additional Comment #6 From fry 2010-04-26 14:12
but that won't be consistent based on particular textMode() settings, or
when the renderer changes. using textAscent() (and textDescent() if
necessary) through the renderer is the only way to ensure consistent results.

if textMode(SCREEN) or one of the others is sending bad results, please
file a new bug and i'll fix it.