[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: STREAM-INFO (Version 5)
- To: Scott.Fahlman@B.GP.CS.CMU.EDU
- Subject: Issue: STREAM-INFO (Version 5)
- From: masinter.pa@Xerox.COM
- Date: 6 Oct 88 16:16 PDT
- Cc: email@example.com (Richard C. Waters), CL-Cleanup@sail.stanford.edu
- In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Tue, 27 Sep 88 10:23:46 EDT
I have a stream that prints characters to a printer-independent file format
(think Postscript). I run in a system that admits 16-bit characters. The
character widths are cached, and loaded on demand. Character widths are
expressed in rationals. In advance of printing, I don't know what the
widths will be. Different type faces will have different units of
As with postscript, the widths are expressed in absolutes independent of
the resolution of the printer -- the printer will perform "best effort" to
print things the same sizes as specified.
Suppose that I am using a style in which most characters are size R (where
R is an integer), but there are a few special symbols that are of size
R*732/539 . I'd prefer to normally use a scale where R is a small integer
rather than have to reduce everything to a scale where, in order to
accomodate the possibility of an unusual character, the scale has to bloat
to be unusually large.
Allowing sizes to be rational instead of integer is a performance
improvement; in a world where there are fairly arbitrary outline-defined
characters of arbitrary sizes, it might be necessary to resort to bignums
to accomodate the least common denominator of all of their sizes.
Rational numbers might drive some users insane, but I think for the most
part you want to allow the implementation to pick the appropriate scale.
My only thought is that, having thought that far, there is no reason to not
extend the range of character widths to allow for floating point, i.e., the
results is a (non-complex) number.