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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

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!