Stupid Question: Kerning and monospaced fonts
Jeliza Patterson
I'm writing a paper which, for various reasons beyond my control, has
to be set in Courier. I noticed that kerning was turned on, and much
as I would like this paper to look better, that seemed antithetical to
me. So I guess my question is, can and should a monospace font be
kerned?
Jeliza
jpat...@tufts.edu http://www.tufts.edu/~jpatters/
Fineart Forum http://www.msstate.edu/Fineart_Online/home.html
Tsunami Gallery now accepting submissions for "Utopia/Dystopia"
http://www.tufts.edu/~jpatters/Tsunami/
Tiro TypeWorks
>I'm writing a paper which, for various reasons beyond my control, has
>to be set in Courier. I noticed that kerning was turned on, and much
>as I would like this paper to look better, that seemed antithetical to
>me. So I guess my question is, can and should a monospace font be
>kerned?
Insofar as a font ceases to be monospaced when it is kerned, no. It
doesn't matter whether kerning is turned on or off in your
application, as a monspaced font will not contain any kerning
information for the application to apply. Kerning information is built
into the metrics of a font, and is simply read by applications. One
could conceivably -- and perhaps someone already had -- build kerning
tables and even adjust sidebearings for Courier. It would still be
ugly, but it would no longer be monspaced.
John Hudson, Type Director
Tiro TypeWorks
Vancouver, BC
ti...@portal.ca
http://www.portal.ca/~tiro
Olivier RANDIER
Patterson) wrote:
> I'm writing a paper which, for various reasons beyond my control, has
> to be set in Courier. I noticed that kerning was turned on, and much
> as I would like this paper to look better, that seemed antithetical to
> me. So I guess my question is, can and should a monospace font be
> kerned?
>
You don't mention the soft you use, but I suppose it's PageMaker or
X-Press. In that case, those softs give you the ability to disable kerning
for fonts that DO have kerning pairs. That's the sense of the option in
type preferences. But no soft could give you kerning pairs for fonts that
don't have any, as Courier, for instance. So don't worry, Courier should
look the same way whether you kern it or not!
--
Olivier Randier -- Experluette
John Doherty
Sargent) wrote:
| The American Typewriter font, as its name suggests, is designed to look
| like typewriting, but it's proportionally spaced. Use that and just tell
| them that's the closest you could get to Courier. It looks a lot better.
Not if you really want or need a monospaced font for some reason (source
code is usually both my personal and our professional reason). I agree
that PostScript Courier isn't the world's best monospaced font, and that
this is one area where the available Type 1 library kinda falls short, but
I really don't want to start that thread again. :)
Alan Sargent
: In article <4ktsqe$g...@d2.tufts.edu>, jpat...@tufts.edu (Jeliza
: Patterson) wrote:
: Olivier Randier -- Experluette
QXP can add kerning pairs. Maybe someone did that to your Courier. These
are kept in a file attached to your document, rather than the font
itself. Check it out and kill it if that's what's happening.
Are you sure that it's kerned -- perhaps it's just proportionally spaced
(again, maybe someone hacked it).
CRAIG NICHOLS
>In article <4ktsqe$g...@d2.tufts.edu>, jpat...@tufts.edu (Jeliza
>Patterson) wrote:
>
>> I'm writing a paper which, for various reasons beyond my control, has
>> to be set in Courier. I noticed that kerning was turned on, and much
>> as I would like this paper to look better, that seemed antithetical to
>> me. So I guess my question is, can and should a monospace font be
>> kerned?
>>
>You don't mention the soft you use, but I suppose it's PageMaker or
>X-Press. In that case, those softs give you the ability to disable kerning
>for fonts that DO have kerning pairs. That's the sense of the option in
>type preferences. But no soft could give you kerning pairs for fonts that
>don't have any, as Courier, for instance. So don't worry, Courier should
>look the same way whether you kern it or not!
>
>Olivier Randier -- Experluette
I have two Courier Fonts on my computer -both are ugly, but one of them DOES
have kerning pairs: "Courier New" ttf. I think I got it with one of the MS font
packs. Check out your font list and make sure you don't have more than one
"Courier" font. MS Word and Wordperfect also have kerning control options, I'm
not sure about any other wordprocessor you might be using.
Craig Nichols --Interested Amateur
barry & Susan Stock
> : don't have any, as Courier, for instance
Well, actually, you could select a range of text in PM5 or 6 and run the
Expert Kerning filter at a reasonable text setting. Go and have lunch, and
when you come back, kerned Courier, if that's what you want.
J. Edward Sanchez
>Insofar as a font ceases to be monospaced when it is kerned, no. It
>doesn't matter whether kerning is turned on or off in your
>application, as a monspaced font will not contain any kerning
>information for the application to apply. Kerning information is built
>into the metrics of a font, and is simply read by applications. One
>could conceivably -- and perhaps someone already had -- build kerning
>tables and even adjust sidebearings for Courier. It would still be
>ugly, but it would no longer be monspaced.
Forgive for asking what may be a stupid question, but since kerning
information is in the font metrics itself (where else?), isn't it the
job of the font rasterizer to kern automatically?
There was a question a few days ago asking if kerning was
automatically applied by word processing programs. I naively assumed
that it was (it seemed logical to me), and answered in the
affirmative. The post was then followed up by another person who
stated that an app must explicitly turn on kerning. And sure enough, I
went into Word for Windows 7.0, and found that kerning was indeed a
toggle option, and defaults to off!
I stand corrected. What I'd like to know now is, how in the world does
an app inform the rasterizer (be it ATM or TrueType) whether to enable
automatic kerning (as specified by the kerning pairs in the metrics)?
And why don't the rasterizers just enable kerning 100% of the time so
that it doesn't become the headache of each app developer?
BCNya,
Edward
-----------------------------------------------------------
J. Edward Sanchez <je...@tridel.com.ph>
http://www.tridel.com.ph/softarts/ (The SoftArts Home Page)
http://www.tridel.com.ph/user/jess/ (Edward's Place)
-----------------------------------------------------------
Tiro TypeWorks
>Forgive for asking what may be a stupid question, but since kerning
>information is in the font metrics itself (where else?), isn't it the
>job of the font rasterizer to kern automatically?
>There was a question a few days ago asking if kerning was
>automatically applied by word processing programs. I naively assumed
>that it was (it seemed logical to me), and answered in the
>affirmative. The post was then followed up by another person who
>stated that an app must explicitly turn on kerning. And sure enough, I
>went into Word for Windows 7.0, and found that kerning was indeed a
>toggle option, and defaults to off!
>I stand corrected. What I'd like to know now is, how in the world does
>an app inform the rasterizer (be it ATM or TrueType) whether to enable
>automatic kerning (as specified by the kerning pairs in the metrics)?
>And why don't the rasterizers just enable kerning 100% of the time so
>that it doesn't become the headache of each app developer?
Someone more technically minded could probably explain exactly how
this works, and I'm only able to comment on Type 1 fonts, but I assume
that applications read metrics information directly from the installed
pfm file, while the rasteriser deals mainly with the information in
the pfb file. Some applications simply don't support kerning at all,
but there are only a few of these (eg. Photostyler), and these are
quickly dying out.
There is one instance I can think of in which one would want to turn
kerning off, but a designer would have to construct his font in a
particular way that I havn't encountered yet (although I'm thinking
about it). If monospaced figures were kerned to each other, so they
would be properly spaced in headings or text, one would need to turn
off the kerning in an application if one wanted to use them in tables.
This strikes me as a very sensible idea, weakened only by the
assumption that the end-user is bright enough to work this out.
Lawrence D'Oliveiro
>jpat...@tufts.edu (Jeliza Patterson) wrote:
>
>>I'm writing a paper which, for various reasons beyond my control, has
>>to be set in Courier. I noticed that kerning was turned on, and much
>>as I would like this paper to look better, that seemed antithetical to
>>me. So I guess my question is, can and should a monospace font be
>>kerned?
>
>Insofar as a font ceases to be monospaced when it is kerned, no.
Why should a font cease to be monospaced when it is kerned?
By the way, I've got news for you: Courier (at least the Mac version)
isn't even a monospaced font to begin with! Thus, it doesn't cease to be a
non-monospaced font when it is kerned.
Ambrose Li
>Forgive for asking what may be a stupid question, but since kerning
>information is in the font metrics itself (where else?), isn't it the
>job of the font rasterizer to kern automatically?
Since rasterizers include PostScript engines, the answer is no.
A PostScript engine, in fact, would normally have no access to kerning
information, which is outside its "universe": it is, literally, in a
different world, on a different computer (i.e., on your PC versus the
"printer", which is just actually another computer that knows how to
print). In this case, "automatic kerning" is not even meaningful.
--
Ambrose Li ~{@h>tHY~} A good style should show no sign of effort;
acli%byron...@io.org What is written should seem a happy accident.
ai...@freenet.toronto.on.ca - Somerset Maugham
Laurence Penney
>Why should a font cease to be monospaced when it is kerned?
>By the way, I've got news for you: Courier (at least the Mac version)
>isn't even a monospaced font to begin with! Thus, it doesn't cease to be a
>non-monospaced font when it is kerned.
This is outrageous! Kerning alters the spacing of particular letter
combinations! Courier is the archetype of monospace fonts! I'm appalled
that you should post such unorthodox statements without further
explanation!
Hanging on the edge of my seat,
-- Laurence Penney
Laurence Penney
>Someone more technically minded could probably explain exactly how
>this works, and I'm only able to comment on Type 1 fonts, but I assume
>that applications read metrics information directly from the installed
>pfm file, while the rasteriser deals mainly with the information in
>the pfb file. Some applications simply don't support kerning at all,
>but there are only a few of these (eg. Photostyler), and these are
>quickly dying out.
The chief function of the rasterizer is to create bitmaps on demand from
outline control point data stored in font files. Applications programming
interfaces typically return spacing information (i.e. advance width, with
side-bearings if you're lucky) along with the character bitmap, or simply
a series of metrics for characters that don't need to be rasterized. With
TrueType, it is the same rasterizer (or interpreter) that is able to
adjust spacing based on instructions in the font - with much finer control
than Type 1, for example - but this is only the standard advance width
that is so modified. TrueType kerning (non-GX) is similar to Type 1.
It strikes me that *advance width* might one day be an anachronism. With
expertly kerned metal fonts, there was not any single measurement you
could take that logically equates to the current notion of "advance
width". The sides of the piece of type could have bits chopped out, other
bits overhanging - handled currently only for certain (hopefully
well-chosen) character combinations by computer kerning. In other words,
kerning was a property of a *single* character, not of a *pair* of
characters.
Characters in "next-generation" fonts (whatever that means) should have a
"kern-edge" to the right and left, each defined as a series of beziers and
straight lines (with the proviso that the y-coordinate keeps increasing
when the edge is traversed from bottom to top). At the page-composition
stage, these edges would then nudge up as closely as possible to adjacent
kern-edges. The kern-edges could be manipulated by clever font scaling
technologies to adjust for optical scaling, making big letters kern
closer. Performance would be a lot slower than current methods, but of
course you could compensate with a "kern-cache", or even pre-computed
"kern-tables" for common combinations...
-- Laurence Penney
Unknown
> je...@tridel.com.ph (J. Edward Sanchez) wrote:
>
> >Forgive for asking what may be a stupid question, but since kerning
> >information is in the font metrics itself (where else?), isn't it the
> >job of the font rasterizer to kern automatically?
>
> >automatically applied by word processing programs. I naively assumed
> >that it was (it seemed logical to me), and answered in the
> >affirmative. The post was then followed up by another person who
> >stated that an app must explicitly turn on kerning. And sure enough, I
> >went into Word for Windows 7.0, and found that kerning was indeed a
> >toggle option, and defaults to off!
>
> >I stand corrected. What I'd like to know now is, how in the world does
> >an app inform the rasterizer (be it ATM or TrueType) whether to enable
> >automatic kerning (as specified by the kerning pairs in the metrics)?
> >And why don't the rasterizers just enable kerning 100% of the time so
> >that it doesn't become the headache of each app developer?
>
> Someone more technically minded could probably explain exactly how
> this works, and I'm only able to comment on Type 1 fonts, but I assume
> that applications read metrics information directly from the installed
> pfm file, while the rasteriser deals mainly with the information in
> the pfb file. Some applications simply don't support kerning at all,
> but there are only a few of these (eg. Photostyler), and these are
> quickly dying out.
>
> kerning off, but a designer would have to construct his font in a
> particular way that I havn't encountered yet (although I'm thinking
> about it). If monospaced figures were kerned to each other, so they
> would be properly spaced in headings or text, one would need to turn
> off the kerning in an application if one wanted to use them in tables.
> This strikes me as a very sensible idea, weakened only by the
> assumption that the end-user is bright enough to work this out.
>
> John Hudson, Type Director
>
> Tiro TypeWorks
> Vancouver, BC
> ti...@portal.ca
> http://www.portal.ca/~tiro
>
>
>>>>
is to be positioned, and that font glyphs are treated as a special kind of graphic
element. The application must tell the rasterizer where each element goes, so it is
the application that makes use of spacing information (character sidebearings,
exception pair kern values, tracking specifications) to position letters next to each
other and generate the instructions which are sent to the rasterizer.
What gets sent down the cable from the application to the printer's rasterizer (or
across the motherboard to ATM, which is a rasterizer) includes not only character
outlines (or calls to cached outlines) but also a tediously long list of other details,
including the XY co-ordinates of where each character is to be drawn. That is
one reason printing can take so much time.
Lawrence D'Oliveiro
Sanchez) wrote:
>Forgive for asking what may be a stupid question, but since kerning
>information is in the font metrics itself (where else?), isn't it the
>job of the font rasterizer to kern automatically?
Well, no. The font rasterizer just has the job of rendering the glyphs.
Their actual positioning is the job of the layout engine, which is a
slightly higher layer. Layout also involves choosing the right glyphs,
based on the text encoding and font-specific rules regarding contextual
substitutions etc.
For a good example of how to structure this sort of thing, look at
QuickDraw GX. There's some sample code in the developer kit that shows how
to make direct calls to the plug-in font rasterizers (or "font scalers",
as GX calls them) for different font formats.
>And why don't the rasterizers just enable kerning 100% of the time so
>that it doesn't become the headache of each app developer?
Applications based on QuickDraw GX (such as Lightning Draw
<http://www.larisoftware.com/Products/LightningDraw.html>) do in fact do
this.
Interesting: I'm looking at the GX structure which specifies various
parameters for each text run, and it's not just a simple matter of turning
kerning on and off: you have a "kerning inhibit factor", which I suppose
can take any value from 0.0 (normal kerning) to 1.0 (no kerning). Can you
specify negative values (exaggerated kerning)? I think you can...
Freek Wiedijk
>A PostScript engine, in fact, would normally have no access
>to kerning information, which is outside its "universe": [...]
Yes, yes, but...
Why didn't Adobe put the kerning information _in_ the Type 1
format as well? What was the reason to have it just in AFM
like files?
That's what I'm wondering about all the time. I would have
expected an AFM file to be the "public" part of a PF[AB]
file, but no...
Freek
Ambrose Li
>Why didn't Adobe put the kerning information _in_ the Type 1
>format as well? What was the reason to have it just in AFM
>like files?
I have no idea :-( Perhaps someone from Adobe can explain
this to us.
Alan Sargent
: >Forgive for asking what may be a stupid question, but since kerning
: >information is in the font metrics itself (where else?), isn't it the
: >job of the font rasterizer to kern automatically?
No. PostScript "show" prints the character and advances the currentpoint
by the width of the character. There is a "kshow" which seems to be there
to kern as well, but it requires further functions (ie implementing a
kerning table) to be defined by the user. Font metrics are never (AFAIK)
sent to the rasterizer, only the printer fonts (from the .pfb's or
whatever). It would be entirely possible to write an automatic layout
programme in PS that kerned text, but for WYSIWYG, the routines would have
to be duplicated in a different language (probably C) to produce the
screen image, so apps that kern text just send one char at a time to the
output device (screen or printer) and adjust the currentpoint as
necessary.
Perhaps there are DTP apps that use Display PostScript; then it might make
sense to send a PostScript prolog, including metrics, and have the
rasterizer kern streams of text, while using virtually the same code to
show it on screen.
Justified, but not kerned, text is simpler. When looking at the PS from
DOS Ventura, there is an operator defined that prints a string as a
justified line; but it goes to single characters when set to kern.
Unknown
> fr...@phil.ruu.nl (Freek Wiedijk) writes:
> Why didn't Adobe put the kerning information _in_ the Type 1
> format as well? What was the reason to have it just in AFM
> like files?
>
> That's what I'm wondering about all the time. I would have
> expected an AFM file to be the "public" part of a PF[AB]
> file, but no...
It's probably asking a lot of first-generation technology (like
PostScript fonts) to anticipate all the ways it will be put to use in
some unforseeable future. Lack of kerning data, unmentionably
ugly composite-accented characters, a frustratingly limited
character set optimized for typesetting computer manuals...there
are lots of reasons to find PostScript font technology weak.
That's because the technology for PostScript fonts, and the first
fonts themselves, were developed for use in typesetting by
people who didn't know enough about typesetting.
Remember, these were the people who thought an American
printer's point was 1/72 of an inch. These were the people who
included the French quotation marks in their fonts but named
them with the name of a seabird. These were the people who
decided ligatures, or bullets, or ballot boxes, were unnecessary,
but that every font just hadda have an omega, a logical not, a
delta, a mu, an infinity symbol... And we're still stuck with the
consequences of that ignorance.
It is sad that TrueType, which has the potential of addressing
many of these weaknesses, isn't being exploited more widely. If
some 1996 version of Jim Von Ehr (creator of Fontographer)
were to become gripped by the vision of a fully-featured,
inexpensive TrueType font editor, and then actually start
marketing it, the world of type might become a considerably
more rewarding place to work (Russ McCann, Ernie Brock, are
you listening?).
Imagine...optical scaling, all the ligatures, true fractions, tabular
and justifying numbers, all easily selected from a standard
keyboard, no arcane monkeying around with a creator
program...ah, well. It's all there in TrueType, but at the moment
it's just too complicated for anybody who isn't a largish
multinational with buckets of money for tools.
It is unfortunate that Adobe advanced beyond the limitations of
8-bit processors in all their technologies except fonts. The
ingenuity that went into producing multiple masters was aimed at
making PostScript a truly portable document technology, not at
making PostScript fonts more useful for quality typography. The
folks at Adobe produce excellent fonts today, but their font
technology is just prettier buggy whips.
Lawrence D'Oliveiro
In article <8301828...@truetype.demon.co.uk>,
Lo...@truetype.demon.co.uk (Laurence Penney) wrote:
What I mean is, with the old (QuickDraw, non-GX) Mac font architecture,
there is a flag bit that indicates whether a font is monospaced or not.
And the one time I looked, I couldn't find a single font that had this bit
set! Certainly not Courier or Monaco. And I believe that I found
characters in both these fonts that were a different width from the
others.
Which is probably why I can find no sign of a corresponding flag bit in my
GX "sfnt" definitions...
John Doherty
In article <ldo-260496...@godot.cc.waikato.ac.nz>,
l...@waikato.ac.nz wrote:
| What I mean is, with the old (QuickDraw, non-GX) Mac font architecture,
| there is a flag bit that indicates whether a font is monospaced or not.
| And the one time I looked, I couldn't find a single font that had this bit
| set! Certainly not Courier or Monaco. And I believe that I found
| characters in both these fonts that were a different width from the
| others.
Not in Courier you didn't. All the characters have 600-unit widths. Check
the AFM.
David Lemon
In article <4lpdu7$6...@imsai.canuck.com>, David Foy (df...@canuck.com) wrote:
> It's probably asking a lot of first-generation technology (like
> PostScript fonts) to anticipate all the ways it will be put to use in
> many of these weaknesses, isn't being exploited more widely.
I guess it's worth speaking up about this. Sorry I'm a bit late in
responding; I've relocated my residence, and the chaos is enormous.
David Foy's post repeats an unfortunately common misconception. The
limitations listed (many of which were imposed by Apple, not Adobe) apply
equally to Type 1 and TrueType in their older instantiations. And both
formats have been developed to get beyond those limitations.
> It is unfortunate that Adobe advanced beyond the limitations of
> 8-bit processors in all their technologies except fonts. The
> ingenuity that went into producing multiple masters was aimed at
> making PostScript a truly portable document technology, not at
> making PostScript fonts more useful for quality typography.
The chronology would argue otherwise. Adobe released multiple master fonts
(on the Mac) years before they wre used for font substitution in Acrobat.
Their intent was indeed to improve the quality of typography by bringin
together the best of new and old capabilities.
- David Lemon
type nerd
The exodus of jazzy pigeons is craved by squeamish walkers.
Unknown
> type...@slip.net (David Lemon) writes:
> I guess it's worth speaking up about this. Sorry I'm a bit late in
> responding; I've relocated my residence, and the chaos is enormous.
>
> David Foy's post repeats an unfortunately common misconception. The
> limitations listed (many of which were imposed by Apple, not Adobe) apply
> equally to Type 1 and TrueType in their older instantiations. And both
> formats have been developed to get beyond those limitations.
Agreed. Apple's dead hand is everywhere in PostScript font technology. Yes,
some progress has been attempted; the question is how much progress has
been made. At the present state of Adobe's font technology, not much has
been and little is possible. At the present state of TrueType, there is at least the
possiblity of some worthwhile development. This is not a misconception.
> > It is unfortunate that Adobe advanced beyond the limitations of
> > 8-bit processors in all their technologies except fonts. The
> > ingenuity that went into producing multiple masters was aimed at
> > making PostScript a truly portable document technology, not at
> > making PostScript fonts more useful for quality typography.
>
> The chronology would argue otherwise. Adobe released multiple master fonts
> (on the Mac) years before they wre used for font substitution in Acrobat.
> Their intent was indeed to improve the quality of typography by bringin
> together the best of new and old capabilities.
The chronology would appear to be a subject for legitimate debate. Let me
explain why I made that statement:
I remember the Sebold conference where MM technology was introduced.
Acrobat may have been far in the future, but portable document technolgy
(PDT) was very much on John Warnock's mind at that time, and Adobe has
always been quite clear that PDT is a high priority (as well it should be). I submit
that if quality typography was a priority, some other, more fundamental upgrades
to font technology might have been their choice. MM works wonderfully as a
PDT solution, and makes a nice toy for designers, but only incidentally
addresses quality and productivity issues from a typographer's viewpoint (at
least, from this typographer's viewpoint).
Lawrence D'Oliveiro
>Apple's dead hand is everywhere in PostScript font technology.
...
> At the present state of TrueType, there is at least the
>possiblity of some worthwhile development.
What a bizarre statement. Who do you think developed TrueType?