I'm a newbie working through the Visualizing Data book by Ben Fry, and am having
some trouble working through fonts. I created a simple program to isolate the
problem and code.

sample code
void setup(){
size(640, 400);
PFont font;
font = loadFont("Arial-Black-12.vlw");
textFont(font);

}

void draw(){
background(255);
smooth();
fill(192, 0, 0);
noStroke();
text("hi!!!");
}

Error Log
java.lang.RuntimeException: use textFont() before text()
at processing.core.PGraphics.text(PGraphics.java:2511)
at processing.core.PGraphics.text(PGraphics.java:2574)
at processing.core.PGraphics.text(PGraphics.java:2499)

at processing.core.PApplet.text(PApplet.java:7674)
java.lang.RuntimeException: use textFont() before text()

at processing.core.PGraphics.text(PGraphics.java:2511)

at processing.core.PGraphics.text(PGraphics.java:2574)

at Temporary_9665_9631.draw(Temporary_9665_9631.java:15)
at processing.core.PGraphics.text(PGraphics.java:2499)

at processing.core.PApplet.text(PApplet.java:7674)

at Temporary_9665_9631.draw(Temporary_9665_9631.java:15)

at processing.core.PApplet.handleDisplay(PApplet.java:1465)

at processing.core.PGraphics.requestDisplay(PGraphics.java:690)

at processing.core.PApplet.run(PApplet.java:1562)

at java.lang.Thread.run(Unknown Source)


at processing.core.PApplet.handleDisplay(PApplet.java:1465)
at processing.core.PGraphics.requestDisplay(PGraphics.java:690)
at processing.core.PApplet.run(PApplet.java:1562)
at java.lang.Thread.run(Unknown Source)

I am running Windows Vista 64 bit for business. I am using Processing 0135 Beta. I
have tried loading different fonts from the create font tool menu and the createFont
command within the code.

I read through the reported bugs and saw some things like this, but they either were
fixed in the next release or fixed with the createFont command.

Any ideas?

sorry to hear you're having trouble. the quick fix is to place the
textFont(font) inside draw(), and declare the PFont outside setup():

PFont font;

void setup(){
size(640, 400);
font = loadFont("Arial-Black-12.vlw");
}

void draw(){
background(255);
smooth();
fill(192, 0, 0);
noStroke();
textFont(font);
text("hi!!!");
}

does that work?

(In reply to comment #1)

(In reply to comment #1)
> Additional Comment #1 From fry 2008-02-14 11:25 [reply] sorry to hear you're
having trouble. the quick fix is to place thetextFont(font) inside draw(), and declare
the PFont outside setup():PFont font;void setup(){size(640, 400);font = loadFont
("Arial-Black-12.vlw");}void draw(){background(255); smooth();fill(192, 0,
0);noStroke();textFont(font);text("hi!!!");}does that work?

That did it. I had tried moving textfont inside Draw but I had not moved PFont
outside of setup. Thanks for the quick response!

John

ok, your original code that you posted should have worked--i'm still
checking into why it did not and will get a fix in for a future release.
thanks for the heads up.

Hey Ben,

Infact that happened to be an issue in the applets uploaded to
OpenProcessing.org, too.
see these two:
<iframe width="128" height="180" scrolling="no" frameborder="0"
src="http://www.openprocessing.org/visuals/iframe.php?visualID=153&width=100&height=100"/>

<iframe width="128" height="180" scrolling="no" frameborder="0"
src="http://www.openprocessing.org/visuals/iframe.php?visualID=152&width=100&height=100"/>

The working one includes the PFont before setup, and textFont is called
again in draw(). Non-working one includes PFont and textFont in setup.
The interesting part is that they work in their regular applet export, but
not when applet is in a subfolder and accessed via codebase, as in
OpenProcessing.

to be clear about the links:
working one:
http://www.openprocessing.org/visuals/?visualID=153
processing export and source:
http://www.openprocessing.org/visuals/applets/visualb9df2d0eec1392b252213a6384afde35/

non-working one:
http://www.openprocessing.org/visuals/?visualID=152
processing export and source:
http://www.openprocessing.org/visuals/applets/visualdefe87858fcdc512e671c5460e7f2555/

also see:
http://www.openprocessing.org/visuals/?visualID=150
this works with a global PFont but no textFont() in draw.
(In reply to comment #4)
>
>
>
> Additional Comment #4 From
>
> msinan
> 2008-03-31 19:58
>
> <!--
> addReplyLink(4); //-->[reply]
>
>
>
>
> Hey Ben,
>
> Infact that happened to be an issue in the applets uploaded to
> OpenProcessing.org, too.
> see these two:
> <iframe width="128" height="180" scrolling="no" frameborder="0"
>
src="http://www.openprocessing.org/visuals/iframe.php?visualID=153&width=100&height=100"/>
>
> <iframe width="128" height="180" scrolling="no" frameborder="0"
>
src="http://www.openprocessing.org/visuals/iframe.php?visualID=152&width=100&height=100"/>
>
> The working one includes the PFont before setup, and textFont is called
> again in draw(). Non-working one includes PFont and textFont in setup.
> The interesting part is that they work in their regular applet export, but
> not when applet is in a subfolder and accessed via codebase, as in
> OpenProcessing.
>
>

We worked with shiffman, and found that the reason was the applet size
being different from the original width and height defined in size().
Actually many things get broken when there is such difference, so it is the
best practice (for me) to have the same width and height while calling an
applet..

I deleted the pieces from openprocessing (so the links will not work).

Thanks anyway.

(In reply to comment #5)
>
>
>
> Additional Comment #5 From
> msinan
> 2008-03-31 20:02
>
> <!--
> addReplyLink(5); //-->[reply]
>
>
>
>
> to be clear about the links:
> working one:
> http://www.openprocessing.org/visuals/?visualID=153
> processing export and source:
>
http://www.openprocessing.org/visuals/applets/visualb9df2d0eec1392b252213a6384afde35/
>
> non-working one:
> http://www.openprocessing.org/visuals/?visualID=152
> processing export and source:
>
http://www.openprocessing.org/visuals/applets/visualdefe87858fcdc512e671c5460e7f2555/
>
> also see:
> http://www.openprocessing.org/visuals/?visualID=150
> this works with a global PFont but no textFont() in draw.
> (In reply to comment #4)
> >
> >
> >
> > Additional Comment #4 From
> >
> > msinan
> > 2008-03-31 19:58
> >
> > <!--
> > addReplyLink(4); //-->[reply]
> >
> >
> >
> >
> > Hey Ben,
> >
> > Infact that happened to be an issue in the applets uploaded to
> > OpenProcessing.org, too.
> > see these two:
> > <iframe width="128" height="180" scrolling="no" frameborder="0"
> >
>
src="http://www.openprocessing.org/visuals/iframe.php?visualID=153&width=100&height=100"/>
> >
> > <iframe width="128" height="180" scrolling="no" frameborder="0"
> >
>
src="http://www.openprocessing.org/visuals/iframe.php?visualID=152&width=100&height=100"/>
> >
> > The working one includes the PFont before setup, and textFont is called
> > again in draw(). Non-working one includes PFont and textFont in setup.
> > The interesting part is that they work in their regular applet export, but
> > not when applet is in a subfolder and accessed via codebase, as in
> > OpenProcessing.
> >
> >
>
>
>
>

i got the same error message and resolved it in the way you described. but the
application worked fine 3 month ago and now i started it again with this error. whats
that?

(In reply to comment #7)
>
>
>
> Additional Comment #7 From
> ItsMe
> 2008-04-02 06:45
>
> <!--
> addReplyLink(7); //-->[reply]
>
>
>
>
> i got the same error message and resolved it in the way you
described. but the
> application worked fine 3 month ago and now i started it again with this
error. whats
> that?

oh i derno.. a bug?

*** Bug 785 has been marked as a duplicate of this bug. ***

Ok, I did a little looking, and the issue is that PGraphics.defaults() is
sometimes being called an extra time after drawing starts.

To me, it looks like the likely culprit is line 134 of PGraphicsJava2D.java
- in the corresponding section of PGraphics2D that "defaultsInited = false"
statement is commented out. There's still a comment there explaining that
you "can't un-set this because this may be only a resize (Bug #463)"

I assume there's some reason you decided to re-enable that line, probably
to fix another bug - happen to remember which one?

eric, what sort of setup are you using to get this to reproduce reliably?
i'm trying to figure out why it's trying to reallocate again; i have a
general idea of what's going on, but i've fixed and re-fixed this issue
several times and really wanna squash this properly.

or in your version, can you check to see what width/height it's
re-allocating at, to see if it does so twice with the same w/h?

Well, I'm not getting it to reproduce reliably - I'm just running and
quitting many, many times until it crashes (or works, depending what I'm
trying to see - whichever one I want is always the one that it doesn't want
to do, it seems). It's pretty random, sometimes I'll have to run it
several dozen times to see it, and sometimes just once or twice.

I'm on MacBook Pro, OS X 10.5.3 with (I think) an NVidia GeForce 8600M GT
256 MB card, if that matters.

I have a log of the output on that computer, but I can't get on the
internet with it right now, when I get to a wireless spot I'll post it.
It's definitely a threading issue, every time I get a crash the allocate
method is getting interleaved with the drawing stuff (I enabled
THREAD_DEBUG), and the defaults() call doesn't happen until after the draw
stuff has started. I'll try to make sure to upload that later today.

And yup, size is definitely getting called several times, varying between
100,100 and the desired resolution, and there is always an extra call in
there when it crashes. The log will be more informative, I'll send that soon.

right, all that THREAD_DEBUG stuff is in there because this is so hairy and
i've had to debug it several times. last time i worked on that section it
was working "well enough" and i had to move on. most of it needs to be
ripped out and reworked so that we can use the accurate timing stuff found
in 1.5, and then do properly thread blocking for the rest of it.

if we can find a quick fix (e.g. just copying the internal settings in
allocate(), instead of setting defaultsInited back to false) that'll at
least get us to the next rev, but sometime this summer i'll be tearing all
of this out.

come to think of it, since this is a threading issue, let's do remaining
discussion over in bug #511... i don't want loddod's inbox getting
overflown with random updates re: synchronization and the bowels of
processing.

(i'd like to encourage bug reporters, not punish them with inboxes full of
technical details)

*** Bug 802 has been marked as a duplicate of this bug. ***

*** Bug 848 has been marked as a duplicate of this bug. ***

*** Bug 870 has been marked as a duplicate of this bug. ***

fixed for release 0145.