Typesetting/Font Fit

Drawing Fonts

Here are different methods of drawing text at different points sizes with varying success of achieving precise positioning.

Direct Drawing

The script allows to select a font and renders text fragments ranged in size containing the font name and size. Each fragment is framed in a rectangle of the height of 4%3 of the current font size.

Note: 4%3 is the ratio of Windows standard DPI 96 and 72, the number of points in inch. On Mac with DPI of 72 the font will be smaller and the rectangle will appear larger.

Scaling and Antialiasing

To achive more precise rendering as in Print Preview try fontscale.ijs. The page is painted at a larger resolution (x2) on an off-screen context, and then scaled down by 2 using average. It will also produces a nice antialising effect. Note how fonts now look like PDF or Mac, which has a PDF engine called Quartz. Even Courier New has the same notorious skinny look.

The issue with with methods is that it is memory thirsty and large array operations are getting slow, though it could be improved JForum:programming/2006-August/002940.

The improved method using a separate form was suggested by Eric Iverson JForum:beta/2006-August/001743.

Using Vector Image and Metafile

Looking on how Wordpad does Preview, another idea that may improve glyph positioning comes around.

If you zoom or scale the window of Wordpad Preview, you notice that the ratio of glyphs does not change as opposed to what we saw with changing the point size. This means that they are not redrawing the picture at scale, but rather have the same vector image, which is drawn at different sizes. The facility to provide such frozen vector image is the Metafile, which is available in J for Windows: glfile, glemfopen, glemfclose, glemfplay.

So you could populate the Metafile with larger font sizes, which do not have the artifacts and then play it at reduced sizes for zooming, etc. See fontmeta.ijs for an example.

Windows Fonts Artifact

There is an artifact in default font rendering, which is only cured in applications with advanced type setting engines like Acrobat Reader or Word. If you compare fontfit.rtf

in Word 2003 it shows smooth transition of sizes
in Wordpad it gives the same uneven jumps as in J
In HTML (below) in IE it shows it unevenly

6	xxxxxxxxxx
7	xxxxxxxxxx
8	xxxxxxxxxx
9	xxxxxxxxxx
10	xxxxxxxxxx
11	xxxxxxxxxx
12	xxxxxxxxxx

printer or pdf show smooth transition of sizes File:Printerfontfit.pdf

Windows made this typograhy choice to compromise rendering fidelity not of sheer oversight. Their TrueType fonts are actually superior in quality for the specific purpose: on-screen readability at small sizes even without smoothing. Plus they have this unique subpixel smoothing called ClearType, but again it is focused on readability, such as web pages and Word documents as well as GUI controls rather than reproduction of printed quality. Wait for Vista and XPS (XML Paper Specification).