Easily using small caps

I recently purchased a font that includes many additional typographical goodies such as text figures and small caps. I would like to to know if there is an easy method to convert selected text to small caps (i.e. highlight some arbitrary text and select a menu item that converts the selected text to small caps). There is a menu item (Format > Font > Capitalization > Small Caps) that I am aware of, but to the best of my knowledge, this is a faux small caps, which simply takes the capital romans and algorithmically shrinks them down.

I'm looking for a solution that converts the selected text to the actual small caps glyphs included in the OpenType font that I purchased.

Bonus points if anyone knows of a method of selecting numbers and converting them to the text figure glyphs.

Thanks in advanced.

MacBook Pro, Mac OS X (10.5.4)

Posted on Jul 27, 2008 10:00 PM

Reply
45 replies

Jul 30, 2008 12:43 AM in response to KOENIG Yvan

And, the fact that Word allow users to calculate all the "faux" is certainly not a reason to do the same.


Matthew Carter told the Monotype conference in Cambridge in 1992 that a decade earlier there had been 120,000 sites world wide where type could be set.

If memory serves, Linotype had sold 150,000 composition casters between 1887 and 1960. Monotype would have sold significantly less. Thus the estimate for systems in use is propably right.

Bitstream, co-founded by Matthew Carter and Michael Parker both of Linotype, had based its burgeoning business on bitmap fonts for the Hewlett-Packard LaserJet introduced in 1984.

When Microsoft implemented TrueType for Windows 3.1 in 1992, the figure shot up by about forty to fifty million beyond the figures for Adobe PostScript and HP Printer Control Language. John Warnock told the Seybold Conference on Computer Publishing in September 1989 that Adobe and Linotype had sold 20 million licences to Type 1 products.

In all, then, Matthew Carter estimated that in 1992 type could be set at possibly 120 million sites world wide. This is an incredible increase, making the SFNT architecture as important and as successful as the HTML architecture for the rise of the information society we have today. But in the process the nature of type and the value of type has been lost sight of.

hh

Jul 30, 2008 12:50 AM in response to Henrik Holmegaard

As of Copland, the premise has been that each SFNT Spline Font file defines its own rendering, giving the type maker the freedom to do as much or as little as she thinks fit.


This takes an additional technical item of information to follow: WorldScript did not allow appearance data to be independent of content data. A glyph was drawn by direction depiction onto a character.

hh

Jul 30, 2008 3:28 AM in response to Henrik Holmegaard

"As I say, Word on Windows is fine for almost everything in Unicode, and Pages on Mac OS X is fine for all of it. It is resolved now in that sense."


I don't know where that comes from, but Pages is currently unable (because of text engine bugs and lack of AAT fonts) to do various RTL and Asian scripts correctly which are not a problem with MS Word for Windows.

Jul 30, 2008 3:54 AM in response to Tom Gewecke

Tom Gewecke wrote:
... Pages is currently unable (because of text engine bugs and lack of AAT fonts) to do various RTL and Asian scripts correctly which are not a problem with MS Word for Windows.


Not to mention optical and metrics kerning and tracking, properly working leading, minimum, desired and maximum word spacing, letter spacing, glyph scaling, auto leading, flush space, skew type, vertical and horizontal glyph scaling and so on. Most of us do not need those things, but if one wants to get things 100% right in all imaginable circumstances, one needs not only that, but much more - as far as I understand.

http://www.adobepress.com/articles/article.asp?p=1084741&seqNum=2

Jul 30, 2008 5:19 AM in response to SermoDaturCunctis

Not to mention optical and metrics kerning and tracking, properly working leading, minimum, desired and maximum word spacing, letter spacing, glyph scaling, auto leading, flush space, skew type, vertical and horizontal glyph scaling and so on.


For the record, metrics represents the intentions of the type maker. What Adobe calls 'optical' is to do with an algorithm purchased from URW for kerning on the fly when the kerning in the font is catastrophic. You don't want to use 'optical' in the first place.

TrueType 2 knocks the socks of this from the start. In the full monty, you can do contextual state-based kerning and intelligent tracking that changes with the size of the type and much more that I can't recall - some copied into OpenType and some not.

Skewing, vertical scaling, and horisontal scaling are artifacts created algorithmically. You could skew in PageMaker 1 and QuarkXPress 1 as long as you were skewing spline type, skewing bitmap type was not on the menu.

The point is that you don't want to have artifacts created algorithmically, you want to have smart typographic shaping to get rid of Adobe 'Expert' fonts (and Linotype's bizarre broken TrueType 1 editions of ligatures in Zapfino, Poetica and more). And you want smart typographic scaling to get rid of dozens and dozens of Adobe 'Pro' fonts that belong in a single font file. You also want to be able to implement custom composition features and implement the custom multilingual interface for those features without having to ask out of three two Anglo-American software publishers plus ISO if you can pleeeease have the ability to support non-English composition requirements.

Best,

hh

Jul 30, 2008 5:28 AM in response to Tom Gewecke

I don't know where that comes from


John Jenkins who maintains the TrueType Specification, see the link supplied with the citation.

Please, include me out in the pros and cons of the present implementation for Arabic and Indic, but include me in for the forty or so writing systems in ISO-IEC 8859-1:1987. The present implementation does not meet enduser expectations even for English, let alone something as exotic and foreign as Danish, Icelandic, Faeroese, Norwegian, Swedish, German ...

hh

Jul 30, 2008 5:51 AM in response to Henrik Holmegaard

I don't know where that comes from


John Jenkins who maintains the TrueType Specification, see the link supplied with the citation.


Thanks. I see now, Jenkins was refuting an argument someone else was making that publishing software does not yet support complex rendering, rather than saying Pages could do more scripts than Word for Windows (which it can't).

Jul 30, 2008 6:24 AM in response to Henrik Holmegaard

The present implementation does not meet enduser expectations even for English, let alone something as exotic and foreign as Danish, Icelandic, Faeroese, Norwegian, Swedish, German ...


I know you feel strongly about that, but search as I may, I haven't found support for this assertion other than your own postings, and I suspect that your personal concept of "enduser expectations" in this area is not shared very widely. But more information regarding others who support your views on the topic is always welcome..

Jul 30, 2008 11:12 AM in response to Henrik Holmegaard

The point is that you don't want to have artifacts created algorithmically, you want to have smart typographic shaping to get rid of Adobe 'Expert' fonts (and Linotype's bizarre broken TrueType 1 editions of ligatures in Zapfino, Poetica and more). And you want smart typographic scaling to get rid of dozens and dozens of Adobe 'Pro' fonts that belong in a single font file. You also want to be able to implement custom composition features and implement the custom multilingual interface for those features without having to ask out of three two Anglo-American software publishers plus ISO if you can pleeeease have the ability to support non-English composition requirements.


In my experience I haven't found any significant interest in or support for your personal point of view on these issues from Mac users, regardless of the country or language in which they work, so (unless that changes) I suspect that, for better or for worse, the chance of things evolving in the directions you suggest is small.

Jul 30, 2008 11:34 AM in response to Henrik Holmegaard

Henrik Holmegaard wrote:
The point is that you don't want to have artifacts created algorithmically, you want to have smart typographic shaping to get rid of Adobe 'Expert' fonts (and Linotype's bizarre broken TrueType 1 editions of ligatures in Zapfino, Poetica and more).


Above all, what I do not want is to have to worry about those things, unless I am doing some serious and/or artistic printing.

When I write a shopping list, I want the words "sugar free" in italics. That's all I want. I do not want to take the time to search my font list for fonts that have italic or oblique typefaces. Neither am I prepared to wait with my shopping until all font designers in the world have properly created italic or oblique typefaces for all their fonts. When I write a shopping list, I do not even want to worry about what a typeface is.

When I write book reviews, I leave the choice of font up to the editors of the magazine that publishes them. I do not want to worry about it. Neither do they want me to worry about it, because they want a font that fits the layout of the magazine. It's their choice - not mine.

For business presentations and commercial material or printed poetry, typography is important, and I take it very seriously, but for 90% of my writing I ain't bovvered.

Jul 30, 2008 12:03 PM in response to SermoDaturCunctis

Hello Magnus

As I already wrote, the only logic explanation of Apple's choice is:
"now we take care of intellectual property regarding fonts.
If a font designer included italics in the font you may use italic
If he included bold you may use bold.
If he didn't, you can't use these styles with these fonts."

It's simple, it's neat.
If a font doesn't match our requirements, we disable it with FontBook or any similar tool as long as it is a font which is not required by the operating system.
For those which are required by the system but don't fit our needs, we don't add them to the list of Favourites fonts available in the Font dialog.

With this protocol we are able to work without worrying.

If we are not satisfied by this way of life, we may search a program which is not so fair with the font designers. I don't know how Word behaves in the late version.

My concern in this thread is not to discuss if Apple is right in its choice. You know my point of view for months.
My only concern here is that Apple stopped in the middle of the road and offers an incoherent system (en français j'aurais écrit qu'Apple a le cul entre deux chaises).
We are not allowed to calculate bold, italic (and of course boldItalic) but we are allowed to calculate some other styles: subscript, superscript and small caps.

Yvan KOENIG (from FRANCE mercredi 30 juillet 2008 21:03:31)

Jul 30, 2008 1:05 PM in response to SermoDaturCunctis

but for 90% of my writing I ain't bovvered


Jottings off the cuff - in between other writing :

If you do not want to chaotify your coded text to get your composed type correct, then you have to separate processing of character content data from glyph appearance data. The UTC and SC2/WG2 cannot encode glyph appearance data as character content data.

Either you should use a smart font in simple mode with the default shapings of the CMAP Character Map. In this case you get your default cursive lower case letter a for LATIN SMALL LETTER A, and you forget about whether you want this or that swash for setting the sonnets of Michelangelo.

Or you should use a smart font in smart mode and in this case you will discover that you can match the appearance of Early Modern German in glyph space and preserve your plain text plain in citations, and you can switch to Modern German and input your comment.

I went over the Unicode debates starting in 1991 and the TrueType debates starting in 1992. Nobody intended that you should have to bother with font fiddling the way you had to bother with font fiddling in Adobe applications - and still have to bother with font fiddling in buried menus.

Note that we essentially belong in the world of fraktur that knows only two letter cases and only one letter style. There is no small upper case, and there is no cursive. There is also no ligation as ligation is not set between syllables and compounds in German.

Svenska Akademien that awards the Nobel Prize for Literature began as an effort by Carl Linnæus, Lars Salvius and others to try to introduce spelling and setting more in agreement with the academies of England and France, and less with German printers in Sweden.

A century later Oxford University Press and Cambridge University Press essentially saw to it that the number of alphabet styles in manual composition was carried forward into mechanised composition, because they are useful in increasing the legibility of line layout.

If you do not separate processing of character content data from processing of glyph appearance data, then you cannot match the appearance of Harts Rules for Compositors and Readers at the University Press Oxford, the Oxford English Dictionary ...

German was different and German is still different. There are people, even people one would want to think of as intelligent, who post that they intend to insert control characters for ligation (ZERO WIDTH JOINER and ZERO WIDTH NON-JOINER) as well as insert combining diacritics.

As per ISO-IEC 10646:2003, if the above control characters for ligation are inserted, they affect searching and sorting. If the audience does not insert these control characters in the search string, the search is unsuccesful. Same with matching appearance in character space by combining diacritics - the plain text is not preserved as plain.

Nobody is saying that if you want to write a shopping list, you should use Linotype Zapfino. Everybody is saying that if you want to write a book with accepted Anglo-American academic typography, then you should use Apple Hoefler, Linotype Palatino, or Adobe Minion Pro (less the PUA that Adobe and Lino do not declare in their products).

And it's the same if you want to write a dictionary of Kiswahili with accepted Anglo-American academic typography as well as etymon in Farsi, Urdu, and Arabic. I could say the same of writing a dictionary of Portuguese or Spanish except that I wonder whether Arabic etymon are acceptable. I simply don't know.

hh

Jul 30, 2008 1:16 PM in response to KOENIG Yvan

Salut Yvan,

KOENIG Yvan wrote:

As I already wrote, the only logic explanation of Apple's choice is:
"now we take care of intellectual property regarding fonts.
If a font designer included italics in the font you may use italic
If he included bold you may use bold.
If he didn't, you can't use these styles with these fonts."


Yes, I know that's your opinion. However, as you well know, I am not convinced by it, and I still think Apple had other reasons for their choice. It would be interesting to find some official Apple document about their reasoning.

If a font doesn't match our requirements, we disable it with FontBook or any similar tool as long as it is a font which is not required by the operating system.


It is quick to do (search Font Book for "italic" and "oblique" and make a collection of the two result lists). However, what I find less than perfect, is that the user has to go through this exercise. Apple could have done it for us.

If we are not satisfied by this way of life, we may search a program which is not so fair with the font designers. I don't know how Word behaves in the late version.


Word 2008 also has faux italics and bold. Just like about any other word processor in the world, except the ones based on the default version of Mac OS X cocoa text engine. And yet, as we discussed in the past, even Apple's own development tools have faux style examples, like SyntheticBoldDemo. With that example, you can even determine the degree of how bold you want your text. It is all part of Apple's recommended techniques in their own development tools.

In addition their text engine has attributes to create faux bold and faux italics if needed (kATSUQDBoldfaceTag and kATSUQDItalicTag), and there is even an attribute kATSUFontMatrixTag to distort fonts like this:

User uploaded file

My only concern here is that Apple stopped in the middle of the road and offers an incoherent system (en français j'aurais écrit qu'Apple a le cul entre deux chaises).
We are not allowed to calculate bold, italic (and of course boldItalic) but we are allowed to calculate some other styles: subscript, superscript and small caps.


That is indeed very peculiar. Let's hope they find la bonne chaise!

Jul 30, 2008 5:18 PM in response to SermoDaturCunctis

It would be interesting to find some official Apple document about their reasoning.


The principle of parsimony (Ockham's Razor) suggests the simple answer that matching appearance in a page description model (e.g. PDF) and a page markup model (e.g. HTML) is simplest if the features in the fonts themselves are used rather than faux features.

Presently, simple shaping and smart shaping is supported in page descriptions but page markups only support simple shapings. For instance, solving the problem of Arabic and Indic is not possible without solving the problem of supporting smart shaping in page markups.

Håkon Wium Lie of the Opera browser people in Oslo has been pushing part of this problem. Mac OS X Server 10.5 has features that suggest some of the same. ATypI 2008 in St Petersburg is to debate smart shaping for page markups.

hh

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Easily using small caps

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.