FAQ
Cover
\
Build
\
Source
\
Bugs
\
Reference
\
Libraries
\
Tools
The bugs database has moved
here
.
Bug 920 : Font width calculation fails when using vectorfonts and PDF
Last modified: 2008-10-21 05:33
P
roject:
processing
trash
Version:
unspecified
Co
m
ponent:
android
book
core
libraries
pde
reference
tools
web
Status:
RESOLVED
Resolution:
INVALID -
Pr
i
ority:
P4
Severity:
normal
Platform
All
O
S:
All
Windows
Mac OS
Linux
Other
Reporter:
Ilu
Assigned To:
fry
Attachment
Type
Created
Size
Actions
Description
: Opened: 2008-09-18 02:05
fonts look look different when generated as bitmap (vlw) and when created
by createFont() from vector font information at startup/runtime.
please see discourse posting for already discussed symptoms and a linkt to
a exmaple PNG.
http://processing.org/discourse/yabb_beta/YaBB.cgi?board=Syntax;action=display;num=1220271870
I tried to create a simple example sketch.
I was not able to reproduce the behavior for "on screen rendering", but for
PDF rendering it is still true (see difference between window and
screenshot.pdf).
import processing.pdf.*;
String TEST = "This is a test of the emergency broadcast system";
PFont f;
void setup() {
size(640, 480);
f = createFont("Monaco",9);
}
void draw() {
background(0);
fill(255);
textFont(f);
int w = (int) textWidth(TEST);
text(TEST, 50, 50);
rect(50, 50, w, 10);
println("w = "+w);
beginRecord(PDF, "screenshot.pdf");
background(0);
fill(255);
textFont(f);
w = (int) textWidth(TEST);
text(TEST, 50, 50);
rect(50, 50, w, 10);
endRecord();
noLoop();
}
Additional Comment
#1 From fry 2008-09-24 15:18
that's because native fonts are used when possible (e.g. when running in
JAVA2D or PDF). i'm adding the following to the reference:
This function creates a bitmapped version of a font in the same manner as
the Create Font tool. It loads a font by name, and converts it to a series
of images based on the size of the font. When possible, the text() function
will use a native font rather than the bitmapped version created behind the
scenes with createFont(). For instance, when using the default renderer
setting (JAVA2D), the actual native version of the font will be employed by
the sketch, improving drawing quality and performance. With the P2D, P3D,
and OPENGL renderer settings, the bitmapped version will be used. While
this can drastically improve speed and appearance, results are poor when
exporting if the sketch does not include the .otf or .ttf file, and the
requested font is not available on the machine running the sketch.
Additional Comment
#2 From Ilu 2008-09-25 01:50
The problem is not the different look of the font but the WRONG width
calculation when using textWidth()!
I'm trying to create 'Objects' which where the size depends on the
contained text and when the width-calculation fails it all looks wrong...
Additional Comment
#3 From fry 2008-09-26 05:44
Ah, I see the problem... You can't use beginRecord() in this case, because
it's using the on-screen calculation of textWidth() rather than the width
found in the PDF renderer. The following works properly:
import processing.pdf.*;
String TEST = "This is a test of the emergency broadcast system";
PFont f;
void setup() {
size(640, 480, PDF, "output.pdf");
f = createFont("Monaco",9);
}
void draw() {
background(0);
fill(255);
textFont(f);
int w = (int) textWidth(TEST);
text(TEST, 50, 50);
rect(50, 50, w, 10);
exit();
}
On my machine it doesn't always set the font in the output to Monaco,
however, which you can get around by using textMode(SHAPE), or filing a
separate bug re: the fonts not getting picked up.
Additional Comment
#4 From Ilu 2008-10-21 02:45
the solution does not really work for me because i do onscreen rendering
but provide the user the possibility to "print" the current screen to a PDF...
any idea?
Additional Comment
#5 From fry 2008-10-21 05:33
use something like:
PGraphics pdf;
void setup() {
pdf = createGraphics(PDF, ...)
}
void draw() {
output(g); // draw to the screen
output(pdf); // draw to the pdf
}
void output(PGraphics gr) {
gr.blah();
gr.blahblah();
}
then do all the functions by using gr.xxxx(), either writing to the screen
or the pdf file.
you just can't use the same textWidth() call from one graphics context (the
screen) with another (a pdf output file).