My text face wish list
Comments
-
As someone who hates fiddling about in typing and typesetting to get upright (and properly spaced) parentheses and other delimiters in italic text, I greatly prefer when fonts do not slant these characters. I don’t think they should be slanted; I don’t think they look good slanted. Thankfully, most of my professional publishing clients agree. One requested stylistic set alternate slanted forms, which I was happy to provide, because at least that way if users want different styles of typography I am able to support them with appropriate kerning within the font.1
-
I tend to agree with Nick Shinn about that this is more a typography’s convention issue rather than a font issue. If one typesetter prefers upright + = ( ] etcª in Italics – he is to typeset it this way manually (or via search/replace) – or to burden the font maker with extra work and complexity. On the other hand, to someony else these uprights may easily look wrong amongst Italics. To be on the safe side I prefer everything logically slanted, because this is ‘standard’ which I would not want to fail to deliver. Upright glyphs in Italics is ‘Extras’.d) or f] – will always look horrible, kerned or not.4
-
I like the way upright parentheses and other delimiters look with italic text, too, but it does seem the convention to slant them has existed for a long time.
Looking at the 1941 ATF catalog, most typefaces did not seem to include any delimiters; you had to use generic ones. Some that did have them (e.g., Garamond and Bodoni Book) only offered roman ones, while others (e.g., Caslon 540) offered (upright) parentheses and brackets in roman, and slanted parentheses in italic.
Looking at a Linotype catalog from 1958, parentheses and brackets were standard characters in all fonts. With serif faces, the parentheses were always slanted in the italic, but the brackets were, except for a few exceptions, upright in both roman and italic. On the other hand, both parentheses and brackets were slanted in sans serif italics.
Looking at a VGC catalog from 1984 (film fonts for display), parentheses were always slanted in italic faces. No fonts included brackets.
Judging from these examples, it appears that parentheses were slanted if they were offered at all with italic fonts, but brackets were upright with most serif faces, at least with machine set metal type. As with today, the compositor had the option to use upright parentheses or brackets in italic text.4 -
Mark Simonson said:Judging from these examples, it appears that parentheses were slanted if they were offered at all with italic fonts, but brackets were upright with most serif faces, at least with machine set metal type. As with today, the compositor had the option to use upright parentheses or brackets in italic text.3
-
I am constantly returning to this great thread (thanks much to @Joshua Langman for starting it!).I am in the process of finalizing a revival family (I hope to launch my typefaces/typography label page sooner than later) and I was wondering, in the end, which would be the most appropriate codepoints to associate to the Angle Brackets.Joshua initially implied that they would have been Unicode “mathematical angle brackets”, but since not all of their uses would be mathematical (and since I have drawn mathematical operators monoline in this particular instance), I was still undecided between 276C-276D, 2329-232A or the aforementioned 27E8-27E9.Being the latter in the range "Miscellaneous Mathematical Symbols", I would be more inclined to use 2329-232A (which are in "Miscellaneous Technical") and maybe have them as duplicates in 276C-276D (which fall in the "Dingbats" range and are often used as punctuation in Japanese).Which are your thoughts on the choice?0
-
Any thoughts about the Unicode values one would chiefly expect for these "Angle brackets", if they are meant for regular typesetting?0
-
Brill use U+27E8 and U+27E9 for the angle brackets.
Dingbat codepoints are best avoided, since they may be emojified in some environments, i.e swapped out for the default emoji font on a system.
U+2329 and U+232A are deprecated. They have canonically equivalent CJK codepoints with specific spacing expectations, so unless one is spacing them accordingly it is best to avoid including these in fonts.3 -
John Hudson said:U+2329 and U+232A are deprecated. They have canonically equivalent CJK codepoints with specific spacing expectations, so unless one is spacing them accordingly it is best to avoid including these in fonts.I am sorry, but I was, at least initially, unable to parse that last paragraph in a way that made sense.If one is designing a font that is not for use in typesetting a language with a script of the CJK family, it would seem to me that the other codepoints, whatever they were, that were canonically equivalent to U+2329 and U+232A, except for having the additional specific spacing expectations for CJK texts, would be the ones to be avoided.Not U+2329 and U+232A themselves, which don't have those spacing expectations.However, upon reflection, I think your meaning is as follows:
- U+2329 and U+232A are not to be used because the UNICODE Consortium has officially deprecated them, informing font designers that they are not to be used.
- This is because these codepoints are specifically defined as corresponding to the same characters, used only in CJK texts, as two other codepoints - except that they're also defined as not having the right spacing for the appropriate use of those characters in CJK texts.
- As for the visually similar characters that may be desired in Latin alphabet texts, appropriate codepoints already do exist for them (whether they're the U+27E8 and U+27E9 that Brill used, or other well-known codepoints among the mathematical symbols).
However, I came up with that only because I'm familiar with Unicode and have seen discussions around such topics here several times. A more naïve reader would be likely to remain as confused as I was initially.
0 -
Canonical equivalence means that text processing may normalise text in a way that actually changes the character codepoints to equivalents, which means that U+2329 and U+232A may be converted to U+3008 and U+3009, respectively, or vice versa.
The Unicode Standard code chart indicates the expected CJK full-width spacing of these characters:
And the deprecation is explicit:
U+27E8 and U+27E9 are the only angle bracket codepoints that correspond to typical proportion and spacing of parenthetical delimiters. Yes, they are classified by Unicode as ‘mathematical’, but math also uses regular ( ) [ ] { }, alongside more specifically math delimiters. The angle brackets exist somewhere between the two: they are not as common as ( ) etc. but they are not limited to mathematics. Brill use them in a lot of linguistics publications, as I recall.3 -
John Hudson said:
U+27E8 and U+27E9 are the only angle bracket codepoints that correspond to typical proportion and spacing of parenthetical delimiters. Yes, they are classified by Unicode as ‘mathematical’, but math also uses regular ( ) [ ] { }, alongside more specifically math delimiters. The angle brackets exist somewhere between the two: they are not as common as ( ) etc. but they are not limited to mathematics. Brill use them in a lot of linguistics publications, as I recall.
"Enclosing punctuation" (as I call it) used in the right way has the benefit, that Unicode properties 'open punctuation' or 'closing punctuation' are defined and they work also in BIDI.
Angle brackets can be used everywhere, if ( ) [ ] { } are not enough. Some language dictionaries use them for "coming from language", e.g. <engl.>.2 -
Andreas Stötzner said:I tend to agree with Nick Shinn about that this is more a typography’s convention issue rather than a font issue. If one typesetter prefers upright + = ( ] etcª in Italics – he is to typeset it this way manually (or via search/replace) – or to burden the font maker with extra work and complexity. On the other hand, to someony else these uprights may easily look wrong amongst Italics. To be on the safe side I prefer everything logically slanted, because this is ‘standard’ which I would not want to fail to deliver. Upright glyphs in Italics is ‘Extras’.d) or f] – will always look horrible, kerned or not.
If the whole portion of text (the context around it) is Italic, then ()[]{} etc. should also be Italic. And vice versa.
E.g. mathematical formulas are upright by definition, thus all punctuation and operators are upright. But the variables, sets and single letter functions are Italic. E.g.
f(x) = a + 2x
But within a quote
Galileo wrote " ... f(x) = a + 2x ..." it depends on a styleguide, but all Italic is considered a good choice.
Good typesetting programs insert extra thin spaces to avoid horrible spacing.0 -
John Hudson said:Brill use U+27E8 and U+27E9 for the angle brackets.
Dingbat codepoints are best avoided, since they may be emojified in some environments, i.e swapped out for the default emoji font on a system.
U+2329 and U+232A are deprecated. They have canonically equivalent CJK codepoints with specific spacing expectations, so unless one is spacing them accordingly it is best to avoid including these in fonts.
John, technically speaking, to add also the Unicode value for U+276C and U+276D would be incorrect? I used double codepoints 276C, 2329 and 276D, 232A but now that you tell me that the Japanese punctuation ones might cause substitutions (and are generally expected to be spaced as that punctuation) I was going to remove them and I was wondering if I could add 276C and 276D instead (they are classified as "bracket ornaments" and are in the Dingbats range, but I guessed it could not hurt and would make them more accessible.0 -
Helmut Wollmersdorfer said:Andreas Stötzner said:I tend to agree with Nick Shinn about that this is more a typography’s convention issue rather than a font issue. If one typesetter prefers upright + = ( ] etcª in Italics – he is to typeset it this way manually (or via search/replace) – or to burden the font maker with extra work and complexity. On the other hand, to someony else these uprights may easily look wrong amongst Italics. To be on the safe side I prefer everything logically slanted, because this is ‘standard’ which I would not want to fail to deliver. Upright glyphs in Italics is ‘Extras’.d) or f] – will always look horrible, kerned or not.2
-
I don’t think there’s any harm in double mapping your angle brackets to the Dingbat codepoints, but avoid naming them in any way that could be parsed back to those codepoints.3
-
I was reminded of this thread this morning when I noticed that the parentheses in Garamond Premier Pro are monoline, while those in the earlier Adobe Garamond are modulated.
1 -
John Butler said:I was reminded of this thread this morning when I noticed that the parentheses in Garamond Premier Pro are monoline, while those in the earlier Adobe Garamond are modulated.2
Categories
- All Categories
- 40 Introductions
- 3.7K Typeface Design
- 793 Font Technology
- 1K Technique and Theory
- 609 Type Business
- 443 Type Design Critiques
- 536 Type Design Software
- 30 Punchcutting
- 135 Lettering and Calligraphy
- 82 Technique and Theory
- 53 Lettering Critiques
- 478 Typography
- 300 History of Typography
- 113 Education
- 65 Resources
- 494 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 161 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports