04.04.2013 Views

Processing: Creative Coding and Computational Art

Processing: Creative Coding and Computational Art

Processing: Creative Coding and Computational Art

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Typography<br />

<strong>Processing</strong> utilizes multiple approaches to rendering typography in your sketches, including<br />

both raster- <strong>and</strong> vector-based solutions. Historically for graphic designers, typography<br />

on the Web has required a cost-benefit analysis between using common but ubiquitous<br />

fonts (i.e., native fonts, which are likely to be installed on most users’ systems) <strong>and</strong> using<br />

more involved, memory-intensive, or unpredictable solutions. <strong>Processing</strong> sketches are<br />

widely distributed as applets on the Web, so there are some similar trade-offs when using<br />

typography in your sketches.<br />

The Typography section is divided into four sections:<br />

PFont<br />

PFont<br />

Loading & Displaying<br />

Attributes<br />

Metrics<br />

PFont is <strong>Processing</strong>’s custom font data type. When using type in <strong>Processing</strong>, you first need<br />

to declare a PFont object. This object is then assigned a reference to a specific font. For<br />

example, assuming you have a font named Verdana-24.vlw in the data directory of your<br />

current sketch, you can render type in <strong>Processing</strong> using the following:<br />

PFont f = loadFont("Verdana-24.vlw");<br />

textFont(f);<br />

text("Hello", 19, 55);<br />

<strong>Processing</strong>’s VLW format is a custom bitmapped font format, which relies on a brute-force<br />

approach to incorporating typography into sketches—characters are described as images,<br />

rather than with a scalable vector format. The benefit of this arrangement is that fonts not<br />

installed on a user’s system can still be rendered in <strong>Processing</strong>, which would not be the<br />

case if <strong>Processing</strong> depended only upon installed native fonts.<br />

Although the VLW format solves the missing typeface problem, it is not without its own<br />

challenges. When a typeface is converted to the VLW format, it should be specified at the<br />

exact point size it will be rendered at or it may not render clearly. This means that if you<br />

use the same font at varying sizes throughout your sketch, you’ll want to create a number<br />

of separate VLW fonts for the different sizes (even though it’s the same font). Sketch performance<br />

is also negatively impacted when the VLW fonts are not created at the specified<br />

rendering sizes in your sketch.<br />

Before you completely write off typography in <strong>Processing</strong>, you should note that it’s possible<br />

to use vector-based typography in <strong>Processing</strong> as well. You can ask <strong>Processing</strong> to use<br />

native (scalable vector) fonts, assuming the user has the specific font installed on their system,<br />

by including the following comm<strong>and</strong> in your sketch:<br />

hint(ENABLE_NATIVE_FONTS);<br />

PROCESSING LANGUAGE API<br />

737<br />

A

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!