... definitions of function vary ...
An important point.
Type designers have two clients/users -- the typographer and the reader.
Fonts have to work as tools for the typographer, as well as possessing an innate functionality of readability.
Other constraints informing type design: market forces, cultural trends, technological capabilities.
... make it ... bigger...
Words often associated with size features.
Make it bigger but fit it into a smaller space is often the cry of the client.
David: I’m sure you can not draw the line between aesthetic and function so clearly in either the old or new design paradigms, or in the confluencial format/devices we today employ. E.g I’m not just making the x smaller, the spacing and width narrower and the strokes lighter to be Mr. Elegant — I’m out to fit more on a headline, or make it useful bigger, or both. That sounds functional to me.
Yes, it's functional, but it is functional within the context of particular kinds of typography, e.g. newspaper headline, not functional in the context of readability in the way that the decisions we make in the design of small type are.
As I suggested earlier, what is interesting is what happens at the point where the functionality of readability gives way to the functionality of typography that is possible at larger sizes. This point is design-dependent and not merely size dependent, although I think it is generally around typical text sizes, and hence one of the reasons why those sizes are typical: they solve the challenges of readability and begin to make richer typographic layouts possible.
Newspaper headline type is a good example to look at, because it is generally heavier as well as more condensed than the text face, unlike a book titling face which will tend to be lighter. So this is an example of what I was talking about above: different kinds of large size typography that are independent of what is happening in the type at small sizes.
John: "...what happens at the point where the functionality of readability gives way to the functionality of typography..."
This is a made-up point.
John:"... different kinds of large size typography that are independent of what is happening in the type at small sizes."
I think of the big bold condensed sans as an optically sized version of the text, serif or sans; that the choice of whether to use a slight serif, or a bold sans is not usually independent of what is happening in the type at small sizes; and that this is something inherently functional to readability and not what you are here calling 'typography.'
As soon as you have a situation in which text type X is combined with display type Y in one situation and display type Z in another situation, you have to look at what is different in the situations -- in the typography -- rather than what is different in the types, in order to understand why Y or Z is appropriate to that situation. To say that a display type is ‘an optically sized version of the text' when there are no stylistic similarities between the text and display types, when, indeed, the typographic style may be based on deliberate contrast of the style of these types, makes no sense. The display type is optically sized, to be sure, but it is not ‘a version of the text'.
And my central point remains: the decisions in the process of type design that are necessary to make small type readable are of a different kind from the decisions that result in a variety of different display types. Let's imagine starting with a typical text face, designed for use at around 11pt. Then let's say that one needs to make a version of that type for use at 6pt. This is a need that is only addressable by making the new design stylistically related to the text type; otherwise, the word ‘version' has no meaning, and one might as well use some other type already optimised for 6pt. My argument is that, at 6pt, the kind of things that one has to do to that 11pt design to make it work at the smaller size, are so constrained by requirements of readability as to be essentially deterministic (complicated, to be sure, and not programmatic in a way that is readily automated for optimum results, although one can get a good distance quickly with Tim Ahren's RMX tools). But heading in the opposite direction -- making a display version of the same text type (again with the word ‘version' actually meaning something) -- one is not faced with constrained decisions about what one must do to make the type readable, but with options as to what one can do to make the type serve different kinds of typographic layout (condensed headlines or elegant book titling; direct linear similarity (real or apparent) or deliberate distinctiveness (à la Caslon's big types)).
Put it another way: for the same 11pt text type, one might produce a variety of display versions for use in different typographic situations, and they will all be readable; but if you want your 6pt version to be readable, then it is going to look one particular way.
if you want your 6pt version to be readable, then it is going to look one particular way.
There is no reason that there can't be several "readable" text versions of a typeface developed from a display original.
Versions for book and news text may be quite different, in the length of descenders, notably.
For instance, compare 6 pt. Linotype Scotch and Linotype Scotch No.2 (I'm looking at a 1950s specimen book). The latter has longer extenders, presumably for book work, whereas the former is more suitable for cramming agate.
So as David says, it is the requirements of the document, and the particular medium, that are the constraining criteria, not a generalized and abstract notion of "readability".
It is good old "immersive" typographism to privilege body text as the basic and pure form of reading, with display text considered to be decorated with aesthetic glosses. But there is no difference for the reader, she doesn't see the so-called typographic qualities of display sizes any more than similar qualities in small type. What are these qualities? Sidebearing width, stroke weight, x-height, extender length, counter size -- all these things are incrementally variable across the full range of type size, and visually significant to the experience of reading.
It's not like you read small text and that's it, but when you read big text you also see aesthetics.
People read documents, not fonts.
> So as David says, it is the requirements of the document, and
> the particular medium, that are the constraining criteria, not
> a generalized and abstract notion of “readability”.
I think he said that's one of the constraints. I hope he doesn't in fact subscribe to your denialism of readability - that would be very disappointing.
These days I don't deny readability, but situate it primarily as a function of the document, not the typeface.
(Nonetheless, I do advertise the readability of certain of my typefaces, according to general wisdom.)
> primarily as a function of the document, not the typeface.
Certainly. But for a person who makes type, the readability of fonts must be a big chunk of his world. No matter what the market wants.
Nick, in the Latin script, ascender and descender length is pretty flexible regardless of the type size, because with the exception of the g they are usually very simple forms. And as you note in comparing different cuts of 6pt Scotch types, extenders of different length are a quick and cheap way to vary the appearance and hence usefulness of otherwise similar or identical types. I don't think this affects my argument significantly, though, because the same thing may be done to the extenders at any size, so this is not a factor in the decisions that need to be made to make the letters readable at small sizes.
John you are a cleavin' a single issue in two with private semantics. Making type "attractive" let's say, in the most literal use of that word, whether large or small, is in a single set of variables up and down the size spectrum. Choice in these variables is informed, in the best case, by reaching for a proper aesthetic, executing with a proper economy, and for a given environment attached to the needs of that reader.
Obviously there are fewer choices in smaller sizes because of their aesthetic preconceptions of those wee spaces, and obviously there are more choices in larger sizes because of their aesthetic preconceptions of those less wee spaces. But it is a single spectrum of variables, aesthetics and economies for all readers.
When I said that those big thick clunky Sans were the optically sized version of text serif, I was informed by historical fact and by practice. Why John is cleaving a single issue into two parts with semantics may only be answered, later.
Nick: "There is no reason that there can’t be several “readable” text versions..."
That's for sure.
> So as David says...
>I think he said that’s one of the constraints.
John: "Nick, in the Latin script, ascender and descender length is pretty flexible regardless of the type size,..."
If you say so, but foot space and headspace are usually dictated rather strictly by the x-ht's proportion of the Em, making the rest not particularly flexible unless built-in leading is summoned, or the face is scaled on the body. If this is not a factor in the decisions that need to be made to make the letters readable at small sizes, I'm not sure what is.
Donald Knuth’s concept of the metafont, stroke-based rather than outline-based, would seem to offer more potential as a means of creating typography that is amenable to digital processes.
I’d agree, but sadly -and hopefully much more significantly- it’s very anti-reader.
@hrant: care to elaborate on what you mean by "anti-reader"? :)
Please let me know if my review of Legato* is enough.
If not I can find more elaborations on-site.
* Best current place to read it: http://typophile.com/node/55783
David: Obviously there are fewer choices in smaller sizes because of their aesthetic preconceptions of those wee spaces, and obviously there are more choices in larger sizes because of their aesthetic preconceptions of those less wee spaces. But it is a single spectrum of variables, aesthetics and economies for all readers.
At this point, I think we're just looking at the same thing in two different ways. To me, variables are only significant if they are ‘in play’, so when you talk about fewer or more ‘choices’ being available at smaller or larger sizes, that to me means simply fewer or more variables being in play. As an example, let's consider x-height as a variable: x-height is a variable that can be taller or shorter. A 6pt type needs an x-height of a minimum size relative to the em, below which it cannot function; at the same time, it can't get so large that it diminishes the significance and effectiveness of the ascenders. So the x-height variable in 6pt type is severely constrained and, in effect out of play. 72pt type, on the other hand, might have a tiny x-height or a relatively huge one, depending on style, intended use, etc., so x-height is a variable that is in full play in 72pt type. You think about this in terms of fewer or more choices at different sizes; I think about it in terms of few or more variables being in play. Ultimately, we probably mean something pretty similar, but have found it useful to think about it in different ways.
David: If you say so, but foot space and headspace are usually dictated rather strictly by the x-ht’s proportion of the Em, making the rest not particularly flexible unless built-in leading is summoned, or the face is scaled on the body. If this is not a factor in the decisions that need to be made to make the letters readable at small sizes, I’m not sure what is.
Nick was the one who cited two 6pt Scotch types, one with short extenders and one with long extenders. Yes, that implies decisions about how to proportion the whole relative to the em, but obviously there are technical solutions, even at 6pt.
Perhaps it would have been more appropriate to say that, in the Latin script, ascender and descender length is pretty flexible regardless of the relative height of the non-extending letters, independent of specific technologies; i.e. it is a feature of the script not of font formats and typesetting technologies.
> Donald Knuth’s concept of the metafont, stroke-based
> rather than outline-based, would seem to offer more
> potential as a means of creating typography that
> is amenable to digital processes.
Right. Only that so far, nobody presented an attractive and workable (i.e. not ugly and not overloaded with untolerable compromises) solution using that concept :)
I suspect that is because they were trying to imitate type made with old media.
Of course, that's a requirement of new type technolgy.
But wouldn't a monoline cursive script be reasonably free of compromise, and suited to metafont technology?
I wouldn't call it a requirement.
Monoline? That has its own difficulty, since the modulation necessary to make it appear monoline is exactly something that stroke-based design sucks at. (Plus, a monoline cursive script is low readability.)
I'm not that fond of strokes either. You have to encode a lot of extra information into the weight modulation, and then (to my eye, anyway), joins and corners never look exactly right. There are some technical advantages (they're easier to hint than outlines), but I don't think that outweighs their drawbacks.
In particular, I don't think they're that much better suited to optical scaling than outlines. Yes, it's easy to just crank up the pen nib, but for outlines, you can accomplish pretty much the same by adding a stroke outline - and that's historically accurate to what ATF did (not forgetting to also pay attention to spacing, width, and vertical proportions).
Kalliculator is of course interesting, and I'm pretty sure there are some compressed CJK fonts for mobile applications based on strokes, but I'm happy to stick with outlines even into the Star Trek future. I just want them to be spiro curves instead of Beziers :)
I was thinking the FontChameleon technology would have its patent expire soon (US patent #5949435), and would be of interest in this discussion. But it turns out the patent wasn't filed until 1997, and doesn't expire until 2017. Oh well.
"...in the Latin script, ascender and descender length is pretty flexible regardless of the relative height of the non-extending letters, independent of specific technologies;"
Yes. And if it were not for this huge planet in the way, one could sky-dive forever.
FontChameleon technology? Thomas, do you know how that works(ed)?
Yeah, I know a lot about it... but.
Before I chat much about it, I'd have to read the patent carefully to determine how much is public knowledge, and maybe talk to my former management as well, to see their thoughts. Adobe isn't currently doing much with it, but I'm mindful of my NDA.
A good general description of how FontChameleon worked can be found in the prior art discussion of Agfa's font compression patent (5754187, 1998):
The FONTCHAMELEON product incorporates one or more "master fonts" and more than 200 typeface design descriptors that reshape the master font to simulate popular typeface designs such as TIMES and HELVETICA. Each master font comprises outlines containing as control points all those required to define any of the typeface design style variations supported by the master. For Latin alphabets, at least two master fonts are required: one for non-italic and the other for italic styles. The individual typeface design descriptors define only those required for a given typeface, leaving the remainder unused as redundant points. Each master font requires about 200 KB of storage, and each typeface design descriptor uses about 3 Kbytes of disk space.
The above methods in the prior art have in common the compression of font data by content information compaction to a varying degree. The INFINIFONT and FONTCHAMELEON systems both replace individual typeface design-dependent character outlines with one or more master outline data or procedural descriptions from which approximations of character outlines are constructed on-the-fly by typeface design- and character-dependent descriptors.
"I’d have to read the patent carefully to determine how much is public knowledge..."
You do that! We made three of four hundred 'descriptors' for Adobe so I can tell you, if no one has upgraded the tools since OS 8, fuggetaboutit!
David B: The Chameleon descriptor dev tool "ChamEdit" hasn't been touched since OS 8 days, no. There was a last-gasp effort to write a manual for ChamEdit, though, which could be helpful.
I had dinner with David Lemon last night, and just as he was dropping me off at Paul Hunt's afterward I asked about the possibility of getting at least the Chameleon editor out of Adobe in some fashion. He thought it was a pretty oddball request, but not necessarily out of the question.
I think the above descriptions give a decent idea of how the Chameleon tech works. The patent is pretty clear, too. Basically, you've got a "master outline" with lots of points on it. Each "descriptor" stores only the transformations to that outline. Wherever possible, those transformations are done globally: things like lower-case vertical stem standard thickness, etc. That's also how they work in ChamEdit: you set a variable like this and it is automatically applied everywhere it's needed. Then you do overrides where necessary.
What am I thinking?
I have long thought that for many kinds of typeface designs, the Chameleon editor would make a really handy rapid prototyping tool. A great way to quickly define the basic characteristics of the typeface. It could export Type 1 fonts....
On the downside, the natural tendency of working with such an environment would be to create a more bland and homogenized font. Instead of starting with lots of personality and trying to tame it (my usual type design problem), you'd be facing the opposite problem.
this sounds like the Font Chameleon principle is not much different from TrueType Variations as implemented in Skia GX/AAT (the gvar table), in which the variations are described using deltas of point coordinates, and which could be edited, AFAIR, using the GX Mutator tool.
Unfortunately, I've never seen ChamEdit or GX Mutator "in action". I would like to, and I would happily talk with my colleagues at FontLab about possibilities to implement such an approach in our applications.
Alternatively, people should have a look at Erik van Blokland's Superpolator which implements a similar approach as the one which was used in TrueType Variations.
Well, *kind* of. But first you have a bunch of info about deltas for global stuff, and then only gradually get more specific. Depending on the typeface, some (or many) glyphs might not have *any* "glyph-specific" info at all!
And you only worry about the key points you need... all the many "unnecessary" points from the master design get interpolated....
The execution, in terms of the actual *code* and stability thereof kinda sucks. But the concepts and UI are pretty great.
Of course remember that many aspects of this are patented for another eight years. :/ Of course, you could always approach Adobe about licensing the patent.
Oh, and to bring this back around to optical size, one of the nice things about ChamEdit is that one could easily tweak parameters like serif thickness, contrast, and x-height, with corresponding global effects on glyphs. That was part of what brought it to mind here.
In technical principles, TrueType Variations used an open format for input, defined with a free and open tool, stored it in a few open tables, and output as open TT, while Chameleon didn't use any standards. In design principles Font Chameleon is much like a corral, go play anywhere, but don't leave. Variations and Superpolations are a wide open field with posts that have signs telling you what's in each direction, and it's all up to the designer or user to wander the space, or in fact leave it. So I'm not sure what common principles there are among these formats, except that one can twiddle input and effect output.
"...one of the nice things about ChamEdit is that one could easily tweak parameters..."
This is true, after a very long preprocess. And in the end, all these brilliances have to return to the puny-human formats and caved-in menus of the dummy-world where none of these multiple mastered formats are installable.
I located a FontChameleon box gathering dust here. It specifies System 7 for Mac and Windows 3.1 for Windows - although it's possible things would run on a modern OS too. I haven't tried it, because I'm too lazy to try to find a floppy disk drive that will connect to my MacBook.
I think David B's comments are on target here. The master font predetermines what range of possibilities is available. The shrinkwrap version of FontChameleon comes with a canned master font, and 47 descriptors "similar to" various popular faces, crafted for FontChameleon by The Font Bureau. (The clone aspect is the main reason Adobe promptly buried the product.)
Adobe did use the technology for a while, but it required extensive (and expert) work on the master font to make it useful for our purposes. I believe there were something like five people who ever knew how to do it. I suspect that's the kind of work David B is recalling so fondly...
I do think Thomas' idea is attractive in its way. If one had a programmer available to set up & tune the master font to one's spec's, one could indeed use the Chameleon tools to do parametric tweaks as a means of design exploration. But that's an enormous "if". Of course one can get similar results on a much smaller (but more doable) scale by setting up appropriate multiple masters.
The guys who created FontChameleon did see type design potential in it. They were thinking that a designer might want to start out a new project by creating outlines that were, say 70% Bodoni and 30% Palatino, and then adjust parameters from there. Personally, I have trouble seeing a serious designer being interested in such an approach, but maybe that's just me.
David L, you're looking at the FontChameleon retail product. It's an amusing toy, but not very interesting (to me, anyway) for developing new fonts. I don't see much use in starting out with something that's 70% Bodoni and 30% Palatino, either.
But I was thinking about the ChamEdit application, that was used by FB and others to create the "descriptor" files (a.k.a. Chameleon fonts). Although I never completed a typeface with it, I did get pretty far along in that direction while reviewing the newly-written documentation.
I was thinking that for prototyping a brand new design, from scratch, the ChamEdit app would be pretty handy. I'd have loved to use it that way. Instead of using it to duplicate an existing font, you'd be using it to develop a new one. Heck, if I'd been on a Mac, I probably would have used it for the early stages of Hypatia Sans development. No programmer required. :)
Of course, I would have run up against limitations of the master font pretty quickly, just in terms of it not supporting Greek, Cyrillic, and some of the extended Latin I was doing. But other than that, it seems like a reasonably workable approach to start.
I do wonder if it might interact poorly with trying to do a real multiple master or Superpolator approach, though. Hmmm.
DavidL: "The shrinkwrap version of FontChameleon comes with a canned master font, and 47 descriptors “similar to” various popular faces, crafted for FontChameleon by The Font Bureau. (The clone aspect is the main reason Adobe promptly buried the product.)"
Ooops! to make clear what Mr. Lemon is casually portraying in an unclear, borderline yikes! fashion: The term 'clone' in the usual context @Typophile, means to make a copy of something that someone else made which the cloner has no right to. Chameleon descriptor files, by contrast and by contract, were only made from template fonts to which Adobe had legal license. With Adobe tools, at Adobe expense this was instead a format conversion for the purpose of file compression for cheaper PostScript printer boards for faster printing at a time where such things were thought by Adobe to be concerns to Adobe's customers.
I was always of the opinion, that dumber and cheaper and crisper and blacker were all you could ask for in a printer, (a bad idea for printer royalty junkies), and the cpu should do All The Font Work. The market agreed, and that, I believe, is the actual size main reason Adobe eventually buried the product. I remember nothing prompt in it at all, but I may be corrected.
Thomas: "I was thinking that for prototyping a brand new design, from scratch, the ChamEdit app would be pretty handy. "
Prototyping a brand new design, from scratch, (type design) is best handled otherwise in my experience. One would only need to use CE a few days to argue your self back to reality. Compared to the upfront work involved in making what did get made, this product was only handy for what it was made to do. Or, if FC had been applied to some kind of fine output tuning, like to shorten a text artistically .998%, or weight a text meticulously for a particular production path, or help type on screen or in print to survive a background, or hop long descenders over caps and descenders, it might have lived.
"Of course, I would have run up against limitations of the master font pretty quickly... [and]...I do wonder if it might interact poorly with trying to do a real multiple master or Superpolator approach"
Both MM and FC are subsets of SP to the skilled and patient. And, since one is the master of one's own SP master, one would run up against no limitations in the master quickly and forever. Look Ma, no Ernie!