General Puncuation - Spacing Glyphs - Why do some fonts but not others have them?

Richard Fink
31.Mar.2010 1.00pm
Richard Fink's picture

I've noticed that some fonts contain the following spacing characters (presented with various encodings for them) and some don't:

1) I am wondering why some fonts have them and some fonts don't.
2) I'd like to know what the deciding factors might be for either including them or not including them.
3) Is there a script for Fontlab or another tool that will add these automatically?

oldnick
31.Mar.2010 1.36pm
oldnick's picture

Fixed spaces are handy if you're doing a lot of complex tabular work; otherwise, most folks can live without such a dizzying array of options.


sii
31.Mar.2010 2.08pm
sii's picture

These were never in any of the standard character sets, and only became interesting when the Web "embraced" Unicode. We added them to the core fonts for that reason...


kentlew
31.Mar.2010 4.29pm
kentlew's picture

Rich — Since these spaces are relative to font size and easily calculable, most professional layout and typesetting applications provide for [many of] these spaces without the need for their presence within a font. (The possible exceptions are figurespace and punctuationspace, but even these are often fudged by the software.)

This has historically been the case, that the typesetting mechanism provides for these, not the specific font, such that I don’t think that most font makers give it any consideration.

So, as Si implies, until Unicode encoded these, it was a non-issue.


James Puckett
31.Mar.2010 5.35pm
James Puckett's picture

Ok, so now that we know why they’re rarities, does anyone actually use them? And has anyone ever wanted to use them but been unable to because they’re not usually in a font?


sii
31.Mar.2010 5.39pm
sii's picture

I've seen them in real-world HTML markup - we had bugs related to "square boxes" logged against various fonts.


dezcom
31.Mar.2010 5.56pm
dezcom's picture

.


John Hudson
31.Mar.2010 6.00pm
John Hudson's picture

Ditto what Si and Kent said.

The principal benefit I can think of to handling set-width spaces at the glyph level in fonts, rather than in distance offsets in layout software, is that these glyphs are then available for inclusion in OpenType Layout lookups. I can think of situations in which it might be appropriate, for example, for a contextual substitution that takes places across a standard word space to also be triggered across other kinds of spaces.


charles_e
31.Mar.2010 6.47pm
charles_e's picture

I suppose if you take the view that the comp is just lucky to have your type at all, you can ask this question. If, on the other hand, you take the comp's point of view -- that the type designer's job is to furnish tools -- you should include them.

Put rather pointedly, I'll allow.

For many years I was use to a typesetting program (TeX) where the comp could specify any needed space on the fly. InDesign doesn't provide for this; I find I miss it. I do use the figure space and punctuation space routinely when setting tables. Yes, I know you can use ID's decimal alignment, but fairly often you get a longish column where only one or two numbers need "padding" with white space, and it is just easier to add them & center the whole thing with the column head.

BTW, there is a bug, apparently in InDesign CS4, Windows only, where if nine of these spaces (uni 2000-200B) occur on a line, and if "show hidden characters" is switched on, the program crashes. Miguel has tested this, and assures us it will not occur in the CS5. Got to be one of the worlds oddest bugs.


k.l.
31.Mar.2010 7.09pm
k.l.'s picture

sii -- I've seen them in real-world HTML markup

Only recently I read in a blog that these spaces should be used for fine-tuning spacing. I find it odd that different-width spaces have been encoded as characters, and even worse that people would solve design issues with help these pseudo characters ...

In future I will use REAL CAPS TEXT on the web.


John Hudson
31.Mar.2010 8.47pm
John Hudson's picture

Karsten: I find it odd that different-width spaces have been encoded as characters.


Thomas Phinney
31.Mar.2010 10.49pm
Thomas Phinney's picture

The logic for encoding them as characters is clear. Type designers have to then either assume that reasonable applications will support them (the Adobe position), or decide that a really sophisticated font should include glyphs for these characters, to enable their use in less savvy applications.

Personally, I have long been of the latter POV, but I don't think the people who want to omit them are crazy, either. So I didn't argue the point too strenuously when over-ruled on this question at Adobe.

Regards,

T


kentlew
1.Apr.2010 4.55am
kentlew's picture

> For many years I was use to a typesetting program (TeX) where the comp could specify any needed space on the fly. InDesign doesn't provide for this; I find I miss it.

Charles — I’m not sure I know what you mean when you say “on the fly” and “InDesign doesn’t provide for this.”

Looks like all of the spaces listed above for the u2000–200B block are here (except zero-width space):

 
You can customize the app to apply keyboard shortcuts to any of these.

And it looks like you can specify them in InDD-tagged text using the form <0x200#>

BTW, can anyone tell us what the difference is supposed to be between enquad/emquad and enspace/emspace? I haven’t been able to find an explanation yet.


kentlew
1.Apr.2010 5.08am
kentlew's picture

Also: I’m not necessarily arguing that fonts *shouldn’t* include these encoded glyphs.

In my first reply, I was trying to explain why most font makers have not generally done so. I don’t think it has been a matter of incompetence, insolence, or arrogance.


Don McCahill
1.Apr.2010 6.38am
Don McCahill's picture

> Charles — I’m not sure I know what you mean when you say “on the fly” and “InDesign doesn’t provide for this.”

TeX has/had the ability to define any size of space, so if you need a 3/5 em space, you can create one. Perhaps this is what Charles meant.


Mathieu Christe
1.Apr.2010 7.15am
Mathieu Christe's picture

I was a Quark XPress user and I miss the possibility to set a percentage of the em, available as a custom space. In French we place thin spaces (espaces fines) between some punctuation signs and words.
In InDesign, you can only use predefined spaces. Unfortunately with some fonts, you won't find the right space, it'll be either too much or not enough. Reason why I'd like to be able to set a value, which could be available as "Custom Space" in the "Insert White Space" menu.
Anyone knows why this option doesn't exist in InDesign, or shall I study the manual closely, if it is?


Theunis de Jong
1.Apr.2010 7.37am
Theunis de Jong's picture

Mathieu, you can change the horizontal scale of anything in ID -- either manually (it's in the Character panel) or with a character style. So 81.67% of an em space can be defined -- just make sure you only apply it to em spaces and not to your text.

(I admit, at that point it's not really "a predefined space" anymore, and if you export to an XML format the formatting will be lost.)


dezcom
1.Apr.2010 8.04am
dezcom's picture

If you think about metal type, incremental spaces were not part of the font. The type setter would add variation spaces as needed. I don't think the onus should be on the typeface designer to supply such things.


kentlew
1.Apr.2010 8.11am
kentlew's picture

@Don: TeX has/had the ability to define any size of space, so if you need a 3/5 em space, you can create one. Perhaps this is what Charles meant.

Thanks, Don. I’ll bet you’re right. That sounds useful, and exactly like the kind of thing Charles would love.

Of course, this is a completely separate issue from the presence of myriad encoded spaces within a font.


Richard Fink
1.Apr.2010 8.18am
Richard Fink's picture

Sii wrote:
>I've seen them in real-world HTML markup - we had bugs related to "square boxes"
>logged against various fonts.

Yeah, this is what prompted the question. "On the fly" seems to be an issue.
I'll be back with details...

Rich


John Hudson
1.Apr.2010 10.19am
John Hudson's picture

Kent: BTW, can anyone tell us what the difference is supposed to be between enquad/emquad and enspace/emspace? I haven’t been able to find an explanation yet.

I think the difference is that a font is allowed to ‘lie’ about one set, but not about the other. For example, in a very narrow compressed or very wide expanded font, the nominally en/em characters might actually be proportionally narrower or wider than actual width relative to body height.

I think the en/em quad characters are the ones that should be fixed relative to the body height, but am not 100% sure about that.


joeclark
1.Apr.2010 10.29am
joeclark's picture

Well, what can I say? I use them and have advocated for them.


k.l.
1.Apr.2010 10.38am
k.l.'s picture

[Going back to John's post:] Unicode is not very specific here ...

Problem is that encoding these spaces creates expectation that they should be present in fonts. (Complaint: Missing!) And type designers who add them likely interpret the use and thus width of these spaces differently, so that hair space might be visibly different in different fonts.* (Complaint: Not the width I expected!) They more "encouragement" for end users to modify fonts.**

Worse, they obscure the idea of what encoding characters means. The Unicode 5 book, p.205, suggests that
U+2009 THIN SPACE and U+200A HAIR SPACE are successively smaller-width spaces used for narrow word gaps and for justification of type

where, in my understanding, "narrow word gaps" refer to the text level while "justification of type" (things like adjusting uppercase spacing?) is not a matter of text encoding but of design. Inviting to produce ambiguous data: when is thin/hair space a real space, when does it serve as design hack?

* Unicode 5, p.205, says:
where they [u-2000..U+200A except sometimes U+2009] are used (for example, in typesetting mathematical formulae), their width is generally font-specific

** See initial post:
3) Is there a script for Fontlab or another tool that will add these automatically?


dezcom
1.Apr.2010 10.42am
dezcom's picture

Well said, Karsten!


John Hudson
1.Apr.2010 11.59am
John Hudson's picture

Karsten: Problem is that encoding these spaces creates expectation that they should be present in fonts.

I've never accepted the argument that just because something is in Unicode it should be in any font, let alone all fonts. Glyph sets are determined by font makers. Unless you are claiming support for a character set that includes characters that you don't in fact support, those characters can't be considered missing.

I do put these space characters into my fonts, but that's because I know they are useful for scholars dealing with manuscript transcription in which capturing different widths of spaces in plain text can be important, and my clients tend to request them.

FWIW, these are the space widths I use in fonts (most are obvious):

U+2000 |enquad| 1/2em
U+2001 |emquad| 1em
U+2002 |enspace| 1/2em
U+2003 |emspace| 1em
U+2004 |thirdemspace| 1/3em
U+2005 |quarteremspace| 1/4em
U+2006 |sixthemspace| 1/6em
U+2007 |figurespace| tabular numeral width
U+2008 |punctuationspace/ comma width
U+2009 |thinspace| 1/5em *or* 2/3wordspace (whichever is narrower)
U+200A |hairspace| 1/18em
U+202F |NBSPnarrow| 1/5em (or 1/3em for Mongolian fonts)
U+205F |mathspacemedium| 1/4em


kentlew
1.Apr.2010 12.59pm
kentlew's picture

FWIW, it looks like InDesign’s default values for some of those spaces which are subject to interpretation, when not encoded in the font, are as follows:

hair space = 0.042 em (don’t ask me why; that’s what I measured)
thin space = 0.125 em (1/8 em)
punctuation space = width of a period
figure space = width of zero (does not change with OT figure features, so unless figs are tabular by default or an encoded figurespace is included, this will not be a tabular space)


charles_e
1.Apr.2010 2.12pm
charles_e's picture

Kent, this is why I fill in those Unicode characters. The *figure space* gets the width of a tabular figure, the *punctuation space* the width of a tabular comma, which I sometimes make up & switch with the regular comma -- Minion needs one, for example. When I need one of these spaces, I enter the Unicode from the keyboard rather than counting on InDesign to figure it out.

Not that it matters, but I use a 155 unit space for a thin, and a 55 unit space for the hair space -- same as John with the hair, & real close with the thin.

There is some precedent for varying hair space values; what a comp setting metal actually used for a hair space was "whatever suited." The thin space is a different matter; in Linotype is was the spaceband, unexpanded (you could switch in different spacebands). For systems using the em, I'd imagine it varied as well.

BTW, not all fonts have the same width for lining tabular figures as for oldstyle tabular figures. Well, it's not ideal, but you can live with that. What you can't live with are those fonts where the setwidth for roman tabular figures is different than for italic tabular figures. Ah, font designers. Why end users have to modify fonts.


Nick Shinn
1.Apr.2010 9.52pm
Nick Shinn's picture

It's a good job we have you to set us right, Charles!

However, I should point out that some of your ideas about what is correct are matters of taste (for instance, your preference for the slash to extend to descender depth), and/or geared to your own field of work, whereas comps in other parts of the graphics industry might have different standards and expectations.

FWIW, I have included the extra space characters in my mega-fonts (and Goodchild Pro, which will see the light of day eventually), but otherwise don't consider them necessary.


terminaldesign
2.Apr.2010 4.00am
terminaldesign's picture

I'm disappointed not to see a unicode value for a copper and a brass. Certainly just as important as a thin and hair space when composing hand set foundry type.


agisaak
2.Apr.2010 4.45am
agisaak's picture

Well, copper = U2640. Brass would be a ligature of U2640 and possibly U2643. Or I suppose in a universe without bromine you could use a Br ligature.

These, of course, can be further ligated with any other unicode character if you need to specify the composition of your foundry type.

André


Mathieu Christe
2.Apr.2010 6.32am
Mathieu Christe's picture

@Theunis: Thank you for your answer but it doesn't appear to be the solution has you concluded.
I'm curious to hear from Thomas Phinney about this typographic setting “missing” from InDesign, thanks.


agisaak
2.Apr.2010 6.51am
agisaak's picture

It's present in InDesign CS3. I'd be surprised therefore if it's absent from CS4 or CS5.

In CS3 it's under type->insert white space.

André


sii
2.Apr.2010 7.48am
sii's picture

>my clients tend to request them.

For custom type, if you charge your clients by the glyph, recommending the inclusion of these would seem sensible. :-)


Mathieu Christe
2.Apr.2010 8.26am
Mathieu Christe's picture

@André, I know it's possible to insert a white space in InDesign (CS3, CX4).

What I'd like to have is a "Custom space", which for the width can be define in a percentage of the em in the Preferences. For more details about my question, please read my first post, thanks.


agisaak
2.Apr.2010 8.23am
agisaak's picture

Sorry -- I missed your earlier post. It's not clear, though, why what you are suggesting couldn't be accomplished with manual kerning rather than custom spaces.

André


Mathieu Christe
2.Apr.2010 8.34am
Mathieu Christe's picture

You search/replace, then you have control on the amount of space everywhere you've placed this "Custom space" by simply changing the perrcentage of the em space. Theunis de Jong suggested horizontally scaling a white space, which can be done with a style sheet and basically equals the Quark XPress function. This solution has limitations, see his post.


dezcom
2.Apr.2010 9.04am
dezcom's picture

But it doesn't have to be a apace from the same font. You can create a set of spaces that you can use for all.


Arno Enslin
2.Apr.2010 9.12am
Arno Enslin's picture

@ Richard

I just thought, that it would be handy to have an embedded font in the css stack, that contains only different spacing characters. Up till now I used the span-tag in cases, in which the spacing was very bad, but this soils the markup more than having a font just for such extra spaces.


Nick Shinn
2.Apr.2010 9.16am
Nick Shinn's picture

A space font.
Very conceptual Chris.
You shoulda published it yesterday!


eliason
2.Apr.2010 9.23am
eliason's picture

Shoulda? You didn't see his great online specimen?


Arno Enslin
2.Apr.2010 9.24am
Arno Enslin's picture

@ Nick

Oh. Was this already proposed? I would have been the second one, if I would not have wasted time with translating. And I swear, I did not read the thread thoroughly.


Arno Enslin
2.Apr.2010 9.54am
Arno Enslin's picture

But I have another idea:

I don’t know, if the problem is already solved in Firefox, but if you change the leading with the help of CSS with a relative value, it can happen, that one line is one pixel higher than the following one. I found this very bothering, because one pixel more or less is visible. So it would be possible to provide a font in the first place of the stack with a higher space for long lines for the case that Mozilla will not fix this bug (caused by too strictly following the specification). In the Internet Explorer the leading is even.


sii
2.Apr.2010 9.55am
sii's picture

>You shoulda published it yesterday!

too late...

http://www.p22.com/lanston/products/spacing_sorts.html

Am I really the only person who remembers this trivia? :-)


dezcom
2.Apr.2010 10.50am
dezcom's picture

Oh, god, I am so unworthy of you guys :-)

Isn't it still April 1st some where on the planet?


Nick Shinn
2.Apr.2010 11.01am
Nick Shinn's picture

I might have known Kegler would have already excogitated that idea!

Am I really the only person who remembers this trivia? :-)

Until you have won the TypeCon quiz, not by a long shot :-)
Right Kent?


Theunis de Jong
2.Apr.2010 12.43pm
Theunis de Jong's picture

.. [Em space with a horizontal scaling applied --] just make sure you only apply it to em spaces and not to your text.

I should've thought of it earlier -- since InDesign CS4 you can use a GREP style to apply the horizontal scale to em-spaces only. A GREP style only can apply character styles, which is sometimes annoying (just a little!), but in this case it's an advantage because you can change the scale in that style, and it'll be changed all over your document.

Sounds interesting? Create a new GREP style. In the Apply Style list, choose "New Character Style". Select this and name it "em width".
In the To Text box put "~m" (sans quotes, of course). Insert a number of ems into your document -- you don't have to apply the style manually --, then change the horizontal scale in the "em width" character style to 50% and 200% to see what happens.


sii
2.Apr.2010 1.26pm
sii's picture

> Until you have won the TypeCon quiz, not by a long shot :-)
> Right Kent?

I better start studying those Dwiggins books then :-)


dezcom
2.Apr.2010 1.32pm
dezcom's picture

Si, study alot about LA as well :-)


sii
2.Apr.2010 1.39pm
sii's picture

Got it, studying taco truck menus and Oscar ceremony typography - I should be good if Hrant and Mark Simonson don't team up.


dezcom
2.Apr.2010 2.50pm
dezcom's picture

Don't worry, Si, I hear Hrant is teaming up with John Downer ;-)


dezcom
2.Apr.2010 2.54pm
dezcom's picture

Just don't team up with me, Si. I have as much chance of winning the TypeCon Quiz as I do of winning the New York Marathon. There, instead of a stop-watch, you would need a perpetual calendar to see me cross the finish line.


Richard Fink
3.Apr.2010 7.22am
Richard Fink's picture

>Until you have won the TypeCon quiz

To cop William Buckley's famous line from 1965's New York Mayoralty campaign - if I were to win, the first thing I would do is demand a recount.

Spacing glyphs, spacing glyphs...

1) As a Beta tester, I reported a bug in IE8 on Windows XP (only XP) that caused a 1 pixel "jog" in line height when the author used one of the HTML character entities like &thinsp; or &emsp;
However, if the font contained the character corresponding to those entities, the bug went away. It was a problem related to whatever way IE8 was synthesizing the character - at least on XP.
But it was filed too late in the game and perhaps not deemed critical enough and IE8 shipped with it.
This was one clue that including spacing characters in the font was, perhaps, a good idea. After all, why rely on UA synthesis if you don't have to?

2) Joe Clark stopped by Readable Web to make a snide comment about my using HTML Character Entities for spacing.
Which read:
You mean you’re using “spacer entities” (fun neologism, BTW) just like spacer GIFs? Because they’re easier than CSS?
You’re so 2009 you’re 1997!

I replied with an apt example and, credit to Joe for re-thinking when re-thinking is due, he seems to have come around to the wisdom of using spacing characters in certain situations:
Talking With The Taxman About Thin Spaces
These entities are part of the specs - both HTML and Unicode - and they do effortlessly what, in some situations, could take many lines of fitful CSS and added HTML span elements. (And, without going into a lot of detail and explaining why it's important, I can tell you firsthand that if you want to get decent H&J text out of a browser, these glyphs are indispensable.)

Now, if the glyph is not in the font, there's a disconnect with the CSS spec. If you read the spec carefully, you see that the "proper" behavior for a browser - if it cannot find the corresponding glyph in any of the fonts in the font stack - is to display the rectangular "character not found" box. This is what Opera does. IE and some other browsers, more practically, will attempt to synthesize the space. But Opera's unsightly behavior is actually correct.

And, as you can see from Kent's analysis of InDesign's behavior, even a high-end app can be weird about the math, let alone a browser you get for free.

In line with Phinney: why not add certainty when it "costs" nothing?
Including these glyphs should be de rigeur.

Where they don't exist, I add them.

Rich


joeclark
3.Apr.2010 10.32am
joeclark's picture

I was always in favour of using space characters once they failed to produce ugly rectangles in standards-noncompliant browsers. (The spec is wrong, incidentally, and is being ignored for good reason.) There was no Damascene conversion.

Our dear friend Richard does still need to learn what an HTML entity is.


John Hudson
3.Apr.2010 9.17pm
John Hudson's picture

Rich: However, if the font contained the character corresponding to those entities, the bug went away. It was a problem related to whatever way IE8 was synthesizing the character - at least on XP.

My guess is that IE was using font swapping (if I recall correctly, a function of RichEdit) as do a lot of other MS apps. So instead of displaying a .notdef glyph for the unsupported character, a different font is used to display the character (typically an MS core font). The reason for the linegap jump is that the substituted font has larger vertical metrics than the other font.


kentlew
4.Apr.2010 11.51am
kentlew's picture

> And, as you can see from Kent's analysis of InDesign's behavior, even a high-end app can be weird about the math

With regard to the thin and hair spaces, at least, this isn’t really a fair accusation. There is no standard width for these. So, I’m not sure that you’re going to be a whole lot more satisfied having the type designer define these willy-nilly either. (We all know how capricious they can be ;-)

Unlike the objective, relative, nominal spaces (3-to-em, 4-to-em, et al.), there is no objective definition for a thin space. I believe the Unicode spec says “a fifth of an em (or sometimes a sixth)” — well, which is it? And some comps might say, Neither. (I happen to like 8-to-em thin spaces.) If the intention was to encode a 5-to-em space, then it should have been called as such.

Back in the day, there may have been a generally shared understanding within certain typesetting shops of what one meant by a thin space, but the truth of the matter is that this will have varied between shops and typesetters.

In fact, the term thin space was also used generically, as in “one of the thin spaces,” referring to several different spaces up to about a fifth of an em — spaces such as a copper or a brass (which James facetiously referred to above) or even a hair space.

And a hair space usually just meant “some small amount of space to make it look good.” Often a comp might just use a scrap of card stock or a piece or two of cigarette paper.

So, I wonder at the wisdom of encoding these subjective spaces. Might just as well encode a tad — “Hey, would you space that out a tad, please?” “I think that could use a tad less space.”

At least a copper and a brass had definite measurements. But these were absolute spaces, not relative. A copper referred to a half-point space, and a brass referred to a one-point space. (These were provided in the different metals to make them easily distinguishable at a glance.)

The reason James’s reference above is amusing is that you can’t realistically provide for these in a digital font. A “brass” in a 12-point font would have a value of 83 em units; but set in an 8-point font, it should be 125 em units; etc.


John Hudson
4.Apr.2010 2.33pm
John Hudson's picture

“Hey, would you space that out a tad, please?”

Colin Brignall's preferred unit of measurement when suggesting minute changes to designs was a gnat's bollock.


James Puckett
4.Apr.2010 3.38pm
James Puckett's picture

The reason James’s reference above is amusing is that you can’t realistically provide for these in a digital font.

Couldn’t we just use OpenType to sub them in appropriately sized coppers and brasses if software just supported that feature?


Richard Fink
6.Apr.2010 9.05am
Richard Fink's picture

@joeclark

I was wondering when you were going to catch up with me. ;)

@kent and all who are capricious:

Thanks for all the valuable info.
So, what's the answer? Yay or nay to including these spaces?

Rich


kentlew
6.Apr.2010 3.04pm
kentlew's picture

Oh, you and Joe have made compelling arguments for including them in any font destined for web use, certainly.

Beyond that, I don’t see the harm (or that much extra work) to including them, but I also wouldn’t be inclined to fault the designer who doesn’t. I guess it depend on the nature of the font.

It does seem to me that as type designers and font producers attempt to become more and more comprehensive, I would expect more future fonts to include them.

Will they become “standard”? — Time will tell.