Score's PT command (for creating exact point sizes for text strings) is flawed. The point sizes created with the PT command are slightly larger than the point sizes other applications create. The difference is small (and arguably neglible), but it is noteworthy nonetheless.
To explain what Score is doing probably requires a bit of background information on the history of the point size system.
The History of the Printer's PointSimon Fournier proposed a standardized system of 72 points per inch in 1737, and published a printed scale for reference. The published tract created confusion among printers because as the printed pages dried, the printed scale shrank in size! The published scale was unfortunately used as a reference, and therefore printers and font makers suffered from the creation and use of inconsistent tools and measures from that time on.
In 1770 Francois Didot proposed a solution to this problem by defining a point as exactly 1/72 of a French inch. (The French inch and the English inch are not the same—a French inch is equal to 1.0638 English inches.) This measurement quickly gained popularity in France and across Europe, and until the 20th century the Didot point remained the standard continental measurement.
Things weren't as clear-cut in Britain and in the United States. Standardization in those countries didn't come about until after the Chicago fire of 1871, which destroyed the foundry of Marder, Luse & Co. The foundry was forced to rebuild all of its molds from scratch, and commissioned Nelson Hawks to size their types. Hawks fixed the point at .013838 inch (basing his measurement on a popular pica type of the day); this became the standard typographer's point until the development of computerized typography.
If one Hawks point equals .013838 inch, then 72 Hawks points equals .996336 inch—not an elegant sum for computerized graphics. When PostScript was created by Warnock and Geschke in the 1980's, a point was defined as exactly 1/72 of an inch (.013888"), which is a much better value for computations. The PostScript point has since become the standard point size for all computer graphics applications, except Score!
Score's PointHere's a quick review before we get to Score's point system:
Guess what Score uses as a point?
This is a value close to but smaller than the Didot point. Why .0142234" has been adopted by Score for point size calculations is not clear.
Regardless of the reason, it means that if you set something at 72pt in Score using the PT command, its actual point size when printed will be 73.734422pt.
How To Get Standard Points in Score
If you want true PostScript point sizes in Score, you shouldn't use the PT command. Instead, set p6 of the text to a value using this formula:
p6 = ((DesiredPointSize / 13.885955) / StaffSize)
The reality is that Score's points are so close to actual PostScript points that in most cases the difference is negligible (if you set the point size to 7.2pt using the command PT7.2, then the text will actually be set at 7.373pt, a difference that is hardly noticeable.) However, if you need text in Score to match the point size of text that is being prepared using another DTP program, the size difference may be important, in which case the point size in Score should be calculated with the p6 formula stated above.
The Proof, and a Working Example
The RECT.PS file that ships with Score (and usually resides in the LIB directory) discloses that Score uses an internal point system of 4000 points per inch in its PostScript output for graphics. (This is a different use of points than the text-size points discussed above, so please don't be confused.) Since PostScript defines a point as 1/72 of an inch, Score must calibrate its 4000ppi (point-per-inch) output to that of PostScript's.
72 divided by 4000 is .018; this is the amount by which the graphics are to be resized to work with PostScript, and this is the exact value of the SIZE definition found in Score's EPS files.
Try setting a single Code16 item in a Score file without any other items; the text can be "_00Hello" or anything—it doesn't really matter. Don't put a staff or anything else in the file—just a Code16 text item. If you select the text and type PT72, it should report that a new point size of 72pt has been created. So far so good. Now print the Score file to an EPS file and open the EPS file in a text editor. About halfway down you'll see:
/size .01800 def
This is the multiplier of 72/4000, and is what is used to scale Score's graphic points (not the same as Score's text-size points) to PostScript's 72ppi coordinates.
Further down the file you should see
/Times-Roman f [ 4096.357 0 0 4096.357 0 0] mkf sf
0 -24525 m save (Hello) show
This is the PS code that displays the text. Here Score is using a matrix for sizing text, and is what allows Score to shrink and enlarge text to any size imaginable. The value 4096.357 repeated twice represents the respective p6 and p7 size factors for the text.
At 4000ppi, a size of 4096.357 is not 1 inch (which is what we'd want when setting text to 72pt), but 1.0240892 inches! Thus Score's PT command has sized the text at 73.734422pt.
What we want to see is 4000 for the two size factors in the matrix, like this:
/Times-Roman f [ 4000.000 0 0 4000.000 0 0] mkf sf
0 -24525 m save (Hello) show
This would be true 72pt at 72ppi. To get this result, reopen the original Score file and select the text item for editing. Use the formula given above for p6 instead of the PT command:
p6 = ((DesiredPointSize / 13.885955) / StaffSize)
Substitute 72 for DesiredPointSize and 1 for StaffSize. Thus:
p6 = (( 72 / 13.885955) / 1)
p6 = 72 / 13.885955
p6 = 5.1850952
Set p6 = 5.1850952, save the file, and print to an EPS file. Open the EPS file in a text editor; the print routine should now read:
/Times-Roman f [ 4000.000 0 0 4000.000 0 0] mkf sf
0 -24525 m save (Hello) show
Voila! True 72pt type, measured in standard PostScript points.
This page last updated 8 March 2005
Webpage Copyright © 2001–2005 Thomas Brodhead
Back to home page of Brodhead Music Typography