According to the specification it sounds like it’s “a mixed set of lowercase and small capital forms”, in the sense of Filosofia. U.C. made to join the l.c., from both U.C and l.c. text.

“U.C. made to join the l.c., from both U.C and l.c. text.”
?

I’ll clarify what I meant, I take the specification to mean that the user should expect to be able to type in a case-insensitive manner and have everything remap to a single case...
sub [F f] by f.unic;
...where the .unic set of glyphs could be a mixed set of capital and lowercase drawings at the same height like Filosofia. Do you agree?

The feature is deliberately ambiguous in this regard, David. Emigre requested the feature because they wanted it for the OT version of Filosofia. I think it can be legitimately interpreted in different ways, including making giant lowercase letters to mix with uppercase letters or, as in Filosofia, making small uppercase letters to mix with lowercase. There is also no reason why the result couldn’t be something in between upper- and lowercase. The point of the feature is to remove the normal visual distinction of upper and lowercase and display text in a single case. I considered calling it the Uncial feature, but thought that made too strong a reference to particular historical styles.

“The feature is deliberately ambiguous in this regard, David.”
Thanks John. That was my first thought but I wanted to make sure. I’m going to put what I was calling “biforms” in there, actually “uppercase biforms”, and be glad I don’t have a second or third set, “lowercase biforms” or “Smallcap biforms” in this design. Otherwise...I don’t know what I’d do...Does anyone?

If you had multiple unicase implementations in the same font, you would need to decide on one of them to be the default associated with the unicase feature, and then use the stylistic set features to access the others as variants of the first. In a situation like that, you would probably want redundant glyphs and perform a complete substitution of the entire alphabet to .unic variants, rather than only subsituting specific letters that change form in this feature, since you wouldn’t want the stylistic set feature to be affecting random letters if applied to non-unicase text.

Yep! choices must be made. It seems OT is settled on a default state of case that is lower. Is that you understanding? So, is the “case” feature also ambiguous?

I think there probably is a presumption somewhere that lowercase text as the most frequent, is in some sense the default. But this presumption precedes OpenType. It is seen in all those old smallcap fonts with smallcap glyphs mapped to lowercase positions and not to uppercase positions. OpenType has actually corrected the presumption with regard to smallcaps, enabling them to be mapped to lowercase and to uppercase.

I don’t think the unicase feature contains such a presumption: the results of the feature should be the same regardless of what case of text it is applied to. The decision of whether the results of the unicase feature look more like lowercase, more like uppercase, or not predominantly like either, is an individual design decision.

The case feature on the other hand is not ambiguous at all, it is just poorly named. The description makes it clear that it presumes affected glyphs to be lowercase harmonising by default, and the feature substitutes uppercase harmonising forms and positioning.

John, I’m sure u can can imagine this is confused. Most designs lack Small caps, some lack lowercase, no faces in my experience, with Latin, lack UC, and many display faces only have that one case.... You’d think, just from lookin’ at the keyboard, not touching it, would give a clue, but I quess not ;) The font format, on the other paw, should be equally adept in any case. There outta be one feature (each) for lower case, upper case and small caps. (period)...

you are so right david
and such a system
with the lower case feature
would have the added benefit
of being useful for hardcore modernists

I’m not sure what your point is, David.

Nick seems to be wanting a glyph substitution feature to display all characters as e.g. lowercase, regardless of how they are encoded. In the first place, this is unnecessary as InDesign’s display-all-text-as-uppercase function demonstrates: this is something that can be done outside of font layout features using buffered character casing and referencing the cmap. In the second case, though, it is a really bad idea anyway, as the InDesign function also demonstrates. Like it or not, we have a bicameral alphabet in which case is semantically significant. If you display lowercase characters are uppercase glyphs or vice versa, you are just creating unnecessary text processing problems for yourself. I never use that InDesign function: if I want uppercase glyphs, I change the text case, which is just as easy to do and has the benefit of matching the text encoding to the text display. If you display lowercase characters as uppercase glyphs you have text strings in your document that look like all caps but which will not be found in a case sensitive search for all caps. In order to find them, you have to employ extra formatting sensitivity in your search, but then you miss actual all caps character sequences that do not share the same formatting as the fake all caps.

In “InDesign’s display-all-text-as-uppercase function”, “all text” means what? 26 characters + whatever gsubs happen, don’t it?

The point is not that “”the “change Case” sign”” only works on A-Z changing to and from a-z...the fact is that many fonts now aspire to, and some contain, a much broader crowd of case sensitive forms.

I like the bicameral alphabet very, very much. I agree completely that case is semantically significant, (else I’d not argue for an upper default in OT fonts ;) violet goes pale, you see).

Can I rest my...point?

I’m afraid I still don’t get what your point is :)

InDesign’s display-all-text-as-uppercase function employs character case mapping without changing the backing string. So it should work for any character with straight casing behaviour. I say straight casing, because Adobe have not implemented Unicode Special Casing support, in this function or in the actual case changing function, so there are some lowercase characters that slip through the net — as Nick found when working with polytonic Greek — or which case correctly only for certain languages.

I’m not sure what you mean by ’an upper default in OT fonts’. For the most part, there is no assumption of a default text state, and less of an assumption than there used to be in Type 1 smallcap and expert set fonts. I think the ’case’ function is unique in presuming that the default forms and positioning for e.g. hyphen height is going to be for use with lowercase or mixed case text. But this seems to me a very fair presumption about the nature of most text. The fact that there are some fonts that only contain uppercase forms doesn’t seem very relevant: these fonts would have appropriate forms and positioning for their design, and wouldn’t need the ’case’ feature at all. The majority of text is mixed case and within that the majority of consecutive character strings are lowercase. That is a reasonable basis for the default form and positioning for punctuation, symbols and, yes, numerals, in mixed case fonts being designed for use in such contexts.

:)”display-all-text-as-uppercase” in indesign, is really “display all alphabetics as uppercase alphabetics, (i.e. the same as “shift”). ” Display all text as uppercase”, I believe, is a different thing to users, and thus to type designers.

There are, 5 cases and a point to be made for a sixth to account for better composition with a particular foreign script (and esp). But the 5 cases we work with most of the time are upper, lower, small cap, infs. and sups. These are not ambiguously used, which is why they should not be ambiguously defined. It’s sometimes confusing, because people work in narrow design spaces and don’t think all the time about all the space.

Here is a picture: Garamond is the best of the bad examples. If you choose “lowercase” in InDesign only the “lowercase”, are , figs are still “too big” Can You See?. Next worst is Trajan, where the figures are not managed for the user as in Garamond, and “lowercase” it says, but small caps they are, SEEEE?. Is this a good way to teach users? Zapfino shows the true metalheadedness of the situation. As the cases diverge in whatever direction the designer chooses, ht. & wt. being the most effective wedges , the characters we usually think of as appropriate for both, (multicase in FB terms), are stressed, and the need for case specific characters increases.

Is the OT ideal that the user needs to manage all of the case outside of A-Z and a-z with other feature tags, or are we trying to hElP? er. no. I think the expectation of users after all this time, is that they will have more power to more easily compose superb typography in a WIDE RANGE OF STYLES, without having to face menus like these... But don’t worry, I’ll fix it.

Right.
“Small Caps” should be accurately termed “Caps with Small Caps” to differentiate it from “All Small Caps”.

“Strikethrough” — now isn’t that useful!?

Don’t complain you lucky ones ... In the German version it was just “Kapitälchen” for both “Small Caps” and “All Small Caps”.

I also realize I did not answer “I’m not sure what you mean by ‘an upper default in OT fonts’”. John, really it’s in a good Document, in a good environment, OT font or not, that the default case composition is set to “mixed U&l.c.”, and so, the empty blinking cursor is thinkin’ uppercase because that first letter composed should be Uppercase. It is not until another character is input that you know for sure it should be uppercase, but, as I hope is a point of no contention, it’ll most likely remain uppercase regardless of what is typed next, or for the rest of the document.

This “Uppercase Default” is true from the beginning of composition (pre-type), and remains true even in digital squirt gun fights like these, I did not make it up, readers did, and All’s I’m saying, is writers. By now. should have the tools to make this easy at even the zer0th common denominator level we strive so mightily to serve, (and I don’t mean in the deadhead way some have mangled to work it out, where e.g. E.g. Happens because En(2)rage e.g. doesn’t have an abreviational period and a solid set of tables on its head to play with. :) )

To do it right, I think we need a well organized and unambiguous series of case features, applications based on how people read and write, (not based on old fonts), and some other important parts too few to mention, as opposed to splitting up the user’s perception of case into an idiot’s paradise of menus. This is not to say, once again, the FB Inc. is not “doing things right, even if we have to copy other people’s mistakes”, because we’re well practiced in this area of the type business, but we are taking precautions in case an intelligent forward-looking composition system can be made to work, and in the mean time we’re using those precautions to make the “right” tables now. :)

Okay, now I understand what you’re getting at. Thanks for the examples.

On one hand, everything you’ve described could be handled at the UI level, largely independent of the font level implementation. This is why, for instance, Microsoft’s XAML typographic features are not identical to the OpenType Layout features that they trigger, and a single UI feature might implement a collection of OTL features. [Which is not to say that I think the XAML feature structure is the best thing going, only that it is an example of the distinction between UI experience and underlying architecture.] Similarly, there is no reason why the ’convert to lowercase’ function in an application couldn’t apply the ’onum’ OTL feature at the same time as converting character case.

Of what you are typographically identifying as ’case’ — upper, lower, small cap, inferiors and superiors — two are considered case for alphabetic characters from a text encoding perspective, and two different ones are considered case for numeric characters from a text encoding perspective. And that isn’t going to change any time soon, if ever. So the question is what kind of architecture and what kind of UI should exist to handle a combination of character level processing and glyph level processing in such a way that the user only has to think about what he sees on the page/screen, not how it got there.

Regarding architecture, the question is how, for example, to have oldstyle numerals, which are glyph variants, identified with lowercase text, which is a character class, and how to enable this in a design-specific — i.e. font-specific — way. And, at the same time, how not to lose the significant processing speed advantage of character level actions available for alphabetic case mapping. In other words, one wants to be able to say, within a font, ’The following glyphs are associated with lowercase text’ without needing to rely on such a statement for glyphs that are already associated with lowercase text by virtue of their character mapping to lowercase character codes. Well, one way to do that is to create new font layout features or tables, in which such statements are made. But another way to do it is so take existing layout features, such as ’onum’, and to say that this feature should be applied as part of text transformation functions triggered by the application UI.

David Berlow wrote:
This “Uppercase Default” is true from the beginning of composition (pre-type) [...]

I wonder if this is still the problem except for a few relicts — default numerals, currency & mathematical symbols which are still “uppercase”.

John Hudson wrote:
In other words, one wants to be able to say, within a font, ‘The following glyphs are associated with lowercase text’ without needing to rely on such a statement for glyphs [...] one way to do that is to create new font layout features or tables, in which such statements are made. But another way to do it is so take existing layout features, such as ‘onum’, and to say that this feature should be applied as part of text transformation functions triggered by the application UI.

Maybe it’s rather a matter of conceiving things. Just consider oldstyle numerals as lowercase, and lining numerals as uppercase. And make oldstyle numerals default in your fonts. This would make numeral-related UC-to-LC text transformation obsolete.

It is banal: “Normal” text is made up of lowercase, with some uppercase here and there. “Normal” typing (no ’shift’ &c) gets you lowercase. Uppercase ask for ’shift’ or the ’All Caps’ option (’case’ which includes switching to lining numerals), and thus can be regarded as “exceptions” already. All caps, small caps, italics — there’s not much difference from a typographic point of view, they are to make text stand out from “default” lowercase setting. And if someone wants lining numerals in lowercase context too, this again has to be an active decision. Moreover, those who really want lining numerals everywhere could make it the default on application or OS level with future software.

But then, one could just turn the last suggestion around: It should be possible to set *any* numeral style, say ’onum’, as default or preferred on application or OS level. That way it turns out irrelevant which numeral style is set as default in fonts.

The real problem is that a normal keyboard doesn’t apply ’shift’ the same way to numerals as it does to letters.

Tthere’s some confusion of form with function.

While it’s OK to make a set of figures to go with lower case alphabetic characters, that doesn’t mean they have to be oldstyle. For instance, I could make “Scotch” lining figures (three-quarter cap height) to go with lower case (and upper and lower case) settings — but make a full-cap height set of lining figures to go with an all-cap setting.

However, while it may make more logical sense to have the OT figures categorized according to the case they’re intended to support, users are used to the conventions of oldstyle and lining.

The real problem is that a normal keyboard doesn’t apply ‘shift’ the same way to numerals as it does to letters.

That is just a symptom of the underlying issue that I described: the alphabetic case distinction is a character-level distinction, while numeric ’case’ distinction — because usually thought of as a style distinction — is a glyph level distinction. A keyboard is primarily a character input tool.

John Hudson wrote:
That is just a symptom of the underlying issue that I described:

Now I understand your earlier text better by reading your comment on my one ...

I just wonder if some of these things, say, automatic selection of the contextually appropriate numeral style on application level, are possible. If I have lowercase text, then for emphasis some uppercase words, followed punctuation marks, then figures, and again lowercase. Would a application be able to “decide” whether to put oldstyle (lowercase context) or lining (uppercase context) figures? And respect different typographic conventions, even ideosyncraties ...
But then, maybe it would help a bit if applications’ ’All Caps’ were used instead of ’Caps Lock’. Or if ’Caps Lock’ would evoke applications’ ’All Caps’. Then, automatism could be omitted.

Maybe one has to apply a more radical view: uppercase-lowercase as a glyph-level distinction (like smallcaps-lowercase) which accidentally/historically was regarded as a character-level distinction. ’Shift’+[any lowercase character]* then does nothing but apply ’All Caps’ to a single lowercase character. And special unicode values for uppercase are a necessary evil, legacy, one has to live with. (Typographic point of view.)

* I am writing on a Mac: ’Caps Lock’ applied to numerals does *not* evoke punctuation marks. Which is a little step toward a change of the paradigm.

Nick Shinn wrote:
While it’s OK to make a set of figures to go with lower case alphabetic characters, that doesn’t mean they have to be oldstyle.

Of course. When applying this broader view (numerals for lowercase & uppercase context), a distinction of oldstyle & lining numerals is too narrow, too design centric — as opposed to function centric. (Which becomes obvious when adding small caps figures ...)

> users are used to the conventions of oldstyle and lining.

I think this is true only of a small minority of users.

hhp

I think Nick’s point is that if users are aware of a distinction in numeral style at all, then they are aware of it in terms of the convention of oldstyle and lining. The idea of ’lowercase and uppercase numerals’ is so rare as not to be a convention at all.

“Of what you are typographically identifying as ‘case’ — upper, lower, small cap, inferiors and superiors — two are considered case for alphabetic characters from a text encoding perspective, and two different ones are considered case for numeric characters from a text encoding perspective.”

:) which, I guess in the Hudsonian universe leaves small caps as “not a case”, which in turn begs the question of why you’d call lowercase characters drawn to Small Cap height, as Unicase...

now for a name for l.c. drawn to the ht. of the caps, I have “fornicase”. Sound okay?

In typography there are four formal categoric systems.
The first is abstract, and the other three are geometric, i.e. they concern the graphic qualities of shape, size, and position.

1. Character Form. This creates the category of character.

2. Variant Character Forms. This creates categories of majuscule/minuscule, and roman/italic. However, some characters (eg “ess”: S,s,S,s) do not have variant forms, while others do (eg “ay”: A,a,a).

(Note that Unicode recognizes both majuscule, which it terms “capital” and minuscule, which it terms “small”, but not italic variants. That’s somewhat illogical.)

3. Relative Size. This creates categories of Big (upper case) Medium (lower case, small caps), and Small (inferiors, superiors, numerators, denominators, ordinals)

4. Relative y-axis Position. This creates categories of Baseline, Superior, and Inferior.

In practice, there are conventional groupings of character parameters from different categories, which exclude many combinations. So on the basic keyboard you get a default roman set of some Medium characters (eg s) with some variant Medium characters (eg a), and some Big characters (eg S) with some variant Big characters (eg A).

In theory, Unicase is not a question of Relative Size (3), because size is “case”, and unicase means that there is one “common” case, and therefore no distinction based on size. So unicase is a question of what default set is chosen from the Variant Character Forms (2).

David: I guess in the Hudsonian universe leaves small caps as “not a case”

Smallcaps have (variable) significance in the display of text, but does this make them a case in the same sense that majuscules and miniscules are separate cases? I don’t think so, because there are no spelling rules regarding them, no rules at all in fact, other than (variable) typographical style rules, about how and where they should be used. The Latin script is an evolved bicameral alphabet, and that is the basis for its encoding. We augment this bicameral alphabet with additional categories of letterforms for both aesthetic and functional purposes, but these categories do not constitute cases in the same way that uppercase and lowercase do. If you write a German noun with an initial lowercase letter, you have spelled it incorrectly. There is no parallel, orthographically required use of smallcaps, or italics, or sans serif. Any of these categories of letterform might be used in a articulatory way, to make clearer the meaning of a text, but they are not cases in the orthographic sense. We might decide to refer to them as cases, but they are ’typographic cases’, not orthographic cases.

Nick: (Note that Unicode recognizes both majuscule, which it terms “capital” and minuscule, which it terms “small”, but not italic variants. That’s somewhat illogical.)

No it isn’t. If it looks illogical in terms of your categorisation, then that should alert you that there is something wrong with your categorisation. Orthographically there is no distinction between this and this; ergo, there is no encoding distinction.

I’m with John on this one.
Smallcaps, italics, etc. are not cases.
And they certainly don’t “deserve” encodings!

hhp

Orthographically there is no distinction between this and this; ergo, there is no encoding distinction.

I think I’ve disproved your statement, by copying and pasting the text!

But seriously, orthographic logic is not the same as typographic logic, which is why we are having this discussion.

> orthographic logic is not the same as typographic logic

Certainly.
But the latter, unlike the former, is not “codified”, it’s not standardized (for example people disagree about how best to use italics) and there’s no way to encode anything that mushy. So you could say that logic and formalism are as different as typography and orthography!

hhp

But seriously, orthographic logic is not the same as typographic logic, which is why we are having this discussion.

Right, but digital typography sits on top of a framework of digital text processing. Unlike bits of lead, digital characters have semantic properties. Text processing and display is multilevel processing: there are the individual encoded characters with their standard properties (e.g. directionality, case folding, canonical composition/decomposition); there are strings of these characters with string level properties (e.g. bidirectional layout); at this level we’re still dealing with what is defined as ’plain text’; then there is the first level of display, the direct mapping of characters to default glyphs; then we have what Unicode calls ’higher level protocols’ that look after basic rendering requirements beyond straight character-to-glyph mapping (e.g. language shaping for complex scripts, a mix of font and shaping engine responsibilities depending on the technology employed); and finally one gets to the relatively thin layer of typographic refinement that sits on top of the rest of the structure. So however one determines things should be considered in typographic logic, practically one has to consider how these are to be implemented on top of a text processing architecture that begins with a structural model of how individual scripts work at the plain text level.

I think I’ve disproved your statement, by copying and pasting the text!

Actually, you’ve proved my statement: plain text copying and pasting removed the typographic distinction between roman and italic but, of course, retained the case distinctions between capitals and lowercase letters.

...you’ve proved my statement...

Actually, copying and pasting removed the semantic significance which you had encoded by italicization, proving that in some instances italics can have orthographic value.

***

the relatively thin layer of typographic refinement that sits on top of the rest of the structure.

Admittedly, this way of arranging things works far better than what we had before, when it was the other way up. However, I think writing/typography is more fundamental than a veneer.

Cased unicase!?
The issue of unicase highlights the problem the orthographic system has with casing. Casing is convention, enshrined as standard, but from a typographic perspective it’s inconsistent to define upper and lower case as separate characters. The German noun convention, the proper name convention, the first letter of the sentence convention, these are all examples of Titlecase, and departing from the convention is not mis-spelling, but mis-casing. Of course, such casing should be kept in the basic document (ie orthographic), but it begs the question of whether Case is a quality of text or layout. Unicode says that case is a text thing; typographically, it’s not.

Keyboards recognize that A and a are not different characters, by only having one set of keys, modified by the shift key. And all but the most basic of word processors recognize the inadequacy of having the same “letter” as different characters for upper and lower case, by making the connection between 41 and 61. A and a, etc.

According to the 4-level typographic system I outlined above, these could be coded
1111: 1 (first character) 1 (majuscule) 1 (big size) 1 (baseline), and
1221: 1 (first character) 2 (minuscule) 2 (medium size) 1 (baseline).

In practice, we already have the .unic OpenType feature, which, as has been observed, is non size-specific. A .forc feature is unlikely.

Actually, copying and pasting removed the semantic significance which you had encoded by italicization, proving that in some instances italics can have orthographic value.

No, that is not orthographic. The semantic significance of italics is what I call articulatory. Orthographic implies something on the level of spelling. My point was that there is no difference, orthographically and hence in terms of text encoding, between roman and italic setting of the same word. The spelling is the same, the character string is the same, and so far as plain text operations are concerned they are identical. If Typophile enabled rich text copy/paste, then the italic styling would have been preserved when you copied and pasted my text. But italic styling is mark-up above the text encoding level.

Keyboards recognize that A and a are not different characters, by only having one set of keys, modified by the shift key.

A shift key isn’t modifying the input from a key, it is accessing a totally different input. In a bicameral alphabet, the shift key typically switches between cases, with the upper and lowercase characters associated with the same key in different shift states. But as soon as you start keyboarding non-bicameral scripts you learn to think of the shift key in a completely different way. On my Hebrew keyboard, for instance, the shift state of a key accesses characters that have no notional relationship to the characters accessed by the non-shift state. This keyboard contains four states, with up to four characters associated with a single key, none of them notionally related to one another.

And all but the most basic of word processors recognize the inadequacy of having the same “letter” as different characters for upper and lower case, by making the connection between 41 and 61. A and a, etc.

Inadequacy? It is hardly inadequate if the particular text processing function you are trying to perform relies on case matching. By treating upper and lowercase letters as separate characters, but defining their relationship as a property of the characters, you get the best of both worlds, and you get it in a way that is very quick and easy to process and which corresponds to conventional use of the script as a bicameral writing system. If casing were handled as a higher level protocol like, e.g. italics styling, there would effectively be no such thing as plain text processing for the Latin script. Almost every text processing operation would have to be handled as rich text, because almost every operation is applied to bicameral text: that has been the normal way to write the script for many centuries, and almost all text one encounters includes both upper and lowercase letters. Far from being inadequate, encoding upper and lowercase letters as separate characters is highly sensible.

Unicase does not ’highlight the problem the orthographic system has with casing’. Unicase presents anomalistic problems in text encoding and display. It is precisely because they are anomalies that they are problematic and are not obviously addressed by casing technologies designed to handle normal text.

Anomalies are sometimes important, but they shouldn’t be taken as benchmarks of encoding technologies, precisely because they are anomalies, they’re not normal. I’m very aware of the importance of textual anomalies because I work with scholars who are studying and transcribing pre-standard texts, documenting textual ambiguities, recording scribal errors. At the Unicode conference next month, I’ll be discussing the problems of addressing textual anomalies in the context of encoding standards designed around normal — i.e. standardised, majority convention — language processing. Even addressing the textual anomalies of a single well-documented text, the Leningrad Codex of the Hebrew Bible, has taken almost three years to pass through the international standards process. Yesterday, I received a copy of Emmanual Tov’s Scribal practices and approaches reflected in the texts found in the Judean desert, which contains tables of symbols found in the Dead Sea Scroll fragments, most of which are not encoded in Unicode yet. The very identity of some of these symbols is unknown or ambiguous, so how does one encode them. Similar complex situations pertain to other ancient texts. The encoding of Vedic marks for Sanskrit has been stalled for several years now because the same visual mark may be used to signify different characters in different texts, or the same character may be signified by a different marks in different texts, and no one has yet been able to thoroughly document the usage in a way that would enable to useful encoding. Early Arabic texts, including the earliest Qur’an fragments, are written in an archigraphemic script without the dots of later Arabic that distinguish different letters. To encode these texts using standard Arabic characters is to make assumptions about the identity of the letters that are not explicit in the texts themselves. So, yes, anomalies are sometimes important and we need to be able to handle them within a text encoding and display architecture that is designed around presumptions of normal text, but the importance of anomalies is primarily found in textual analysis operations — e.g. comparison of multiple texts in an electronic corpus —, not to things like cased unicase display typography.

The semantic significance of italics is what I call articulatory.

And so is Titlecase. Your argument that titlecase is like spelling is a justification for assigning casing to plain text. But common sense says that there are some 26 letters in the alphabet, and words are spelled the same way whether in upper, lower, or mixed case.

...as soon as you start keyboarding non-bicameral scripts you learn to think of the shift key in a completely different way.

Well of course! Bicameral means that the same character has two components, not that two (or more) separate characters have been arbitrarily associated.

Almost every text processing operation would have to be handled as rich text,

Now that sounds like progress!
Assigning casing to plain text is a bit of a cheat, to facilitate basic encoding.

the importance of anomalies is primarily found in textual analysis operations ... not to things like cased unicase display typography.

Eunoia is perfectly logical, and only an anomaly in terms of standard practice. (Which may explain why only a handful of people have licensed the font!) I don’t really consider it display typography — it’s more of a theoretical experiment.

> Eunoia is perfectly logical

Just like Van Gogh’s ear.

hhp

If unicase and small caps are accepted practices, and people understand the logic behind them, then a “cased unicase” font is equally logical — and Eunoia Unicase adheres strictly to both the unicase and the small cap conventions; there is nothing mutually exclusive that screws up the combination. The fact that the term sounds contradictory is the fault of the terms, not the typographic logic.

> If unicase and small caps are accepted practices,
> and people understand the logic behind them

But they’re not, and they don’t. Not even plain old
italics enjoys that. Unicase in particular is looked
upon by many people (including readers) as a bad joke.

And again: even if they are, their usage is still
not codified (or probably even codifiable) so no
encoding is possible.

hhp

There is a unicase OpenType feature tag.
All that’s lacking is for it to be supported by a layout application.

Your argument that titlecase is like spelling is a justification for assigning casing to plain text. But common sense says that there are some 26 letters in the alphabet, and words are spelled the same way whether in upper, lower, or mixed case.

My specific example was German nouns, in which capitalisation is not optional and an initial lowercase letter constitutes something like a spelling error. The fact is that uppercase letters have grammatical function in a way that italic styling, the presence or absence of ligatures, the use of smallcaps, etc. do not. We expect a grammar checker to pick up on whether the first letter of the first word of a new sentence is a capital, but we don’t expect it to pick up on whether that word is set in italics. This is the common sense way in which we use our bicameral alphabet.

Bicameral means that the same character has two components, not that two (or more) separate characters have been arbitrarily associated.

It’s begging the question to describe them as ’the same character’. They are the same letter, but that is not the whole basis on which a decision is made regarding how they should be encoded. We must consider how they are used, what kind of functions we expect to be able to perform with encoded text, how best to facilitate those functions. Describing something as a ’cheat’ because it ’facilitates basic encoding’ seems to me perverse when the goal is basic encoding. It’s like saying that kicking the ball in the direction of the goal is cheating at soccer.

Describing something as a ‘cheat’ because it ‘facilitates basic encoding’ seems to me perverse when the goal is basic encoding.

The problem is that Titlecase, while it is basic to encoding, and arguably to grammar, is a layout feature. Unicode gets around this by pretending that majuscule and minuscule versions of the same letter are different characters, making basic encoding possible without resorting to the higher level of layout features. Sure, it may get the ball in the goal, but so can handball, and that’s a foul.

In terms of grammar, Titlecase is a form of Inflection. Whereas most inflection signifies a grammatical feature by altering the spelling of a word, Titlecase does so by capitalizing the initial letter.

The result of the “cheating”, which applies case selectively only to letters, and through “characterization”, as David Berlow has so astutely pointed out, is that the typographic casing of non A-Z characters is left up in the air: “Is the OT ideal that the user needs to manage all of the case outside of A-Z and a-z with other feature tags? ...an idiot’s paradise of menus”.

As Karsten has noted, ideally the shift key should activate the Case feature. The way it is now, letters keyed as all-caps by using the shift key (or shift-lock), will not automatically display the appropriate “case” of accompanying glyphs, such as figures and punctuation — unless the “all caps” button is pushed for text which is already in all caps; from the user’s perspective, that’s absurd.

So the Unicode system is not perfect. But funnily enough, I don’t think that’s necessarily bad for good typography. Perfection is hard to come by. OpenType is a powerful tool, and if some expertise is required from typographers to realize all its benefits, then it becomes a focus of interest. If typographers have to think about which figures go with which case, and make a decision, that’s good for typography, rather than just having the standard kick in automatically. Nonetheless, there’s a lot of room for improvement in the OT menus.

> Unicode gets around this by pretending majuscule and minuscule
> versions of the same letter are different characters

Pretending? That’s exactly what they are: two different characters representing the same letter, each one used depending on certain grammatical rules. The fact that non-alphabetic characters don’t have other-case counterparts is just a complexity we have to live it; it doesn’t make Unicode’s handling of UC/lc incorrect. And typographic distinctions are completely moot to this point; because they are not formal, codified rules - they’re more like personal preferences.

Think for example of so-called “upright italics”, which aren’t
really italics at all (because they’re functionally not) but too
many type people claim they are.

> the typographic casing of non A-Z characters is left up in the air

That’s a different problem. As is the observation that
there’s room for improvement (although there always is,
even in something like the basic alphabetic structures).

My own main point (a minor one, I admit, in this broad thread) is that you cannot -and should not- encode things like smallcaps and italics the way you encode formal grammatical distinctions, at least not at such a base level as Unicode. Also, unicase is not a formal grammatical distinction (thank god).

> the Unicode system is not perfect

True.
Verily, only Eunoia’s unicase logic is so.

hhp

two different characters representing the same letter, each one used depending on certain grammatical rules.

That’s self-fulfilling. Just because grammar determines their usage doesn’t make them different characters.This is apparent with those characters which have an identical form in both cases, CcOoSsUuVvWwXxZz in Latin. That’s the fundamental way casing works, it’s the same character in two different sizes. The complexity we have to live with is that in many instances the character has a different form as well as size.
As I said, Titlecase is a grammatical indicator that works by changing case (a typographic quality), not by changing character, i.e. spelling (a linguistic quality).

The fact that non-alphabetic characters don’t have other-case counterparts is just a complexity we have to live it; it doesn’t make Unicode’s handling of UC/lc incorrect.

The correct casing of characters, both alphabetic and non-alphabetic, is an important part of typography. Beyond typography-lite, Unicode’s handling of case poses difficulties; it’s incorrect because it’s simplistic. Rather like what happened with faux-italic, -small caps, and -bold.

Unicode would accomodate expert typography better if it encoded casing for all characters — not just those which are grammatically meaningful. That would be something like feature tags for the five cases: Caps, Lower case, Small caps, Superior, and Inferior.

The idea that “oh that’s just fancy typography, the icing on the cake, so it doesn’t matter” is at the root of the way Unicode handles case.

> it’s the same character in two different sizes

No, I don’t think size is it at all. The essential useful difference
between UC and lc is that they’re used grammatically differently.
The size, forms, etc. are all on a different level of usefulness. Maybe
a more useful level to an art director, but clearly not to most people.

Also, by seeing uppercase letters that are structurally different than their lowercase counterparts as somehow flawed, you’re making the same mistake as Thompson: vying for destructive simplification.

> The correct casing of characters, both alphabetic and
> non-alphabetic, is an important part of typography.

Not really. It’s more of an important part of orthography, and [the casing aspect of] typography just follows that. I’m getting the feeling that perhaps you’d like people to see unicase as a typographic scheme as valid as traditional mixed-case, and you realize that can only happen by simply ignoring [that aspect of] grammar, so you’re advocating classing typographic refinement above basic encoding? If so, I’m sure that won’t work.

> Unicode would accomodate expert typography
> better if it encoded casing for all characters

No, it would become a mess. Repeat: those are not properly encodable.
The decisions made would be “incorrect” to various segments of users.
Like try to define what an “italic” is, and you won’t hear the end of
it from me. :-)

What you’re talking about isn’t useless, quite the contrary; but that’s not the point of unicode, and it shouldn’t be. Furthermore: what unicode tries to do is in fact more important, simply because it’s more fundamental; billions of people have trouble typing their scripts into computers - they’re quite far from worrying about smallcaps and such - not that the most technologically advanced cultures really worry about smallcaps either anyway... :-/

Seeing this distinction is critcally important - it has nothing to do with “fancy” or dumb - but with the useful layers of how humans process textual information.

hhp

by seeing uppercase letters that are structurally different than their lowercase counterparts as somehow flawed

I didn’t say that, I don’t see that. The minimum requirement for upper vs. lower casing to be grammatically significant is size. The fact that there are many characters where the glyph shapes are different for the different cases is therefore grammatically redundant. Which isn’t to say it’s a flaw, it’s a complexity (to use your term), and probably serves some other purpose.

I’m getting the feeling that perhaps you’d like people to see unicase as a typographic scheme as valid as traditional mixed-case,

Hrant, it’s 2006. Go change some diapers. Stop projecting your feelings onto me and address what I say. Note that in my last post I mentioned five typographic cases, and unicase wasn’t one of them.

Repeat: those [expert typographic cases] are not properly encodable. The decisions made would be “incorrect” to various segments of users.

Standards are negotiated. OpenType feature tags are agreed-upon encodings. Typographers need sophisticated layout applications to work efficiently — at the moment their menus are all over the place — and it would be a lot easier for application developers to do their part if the five kinds of casing were encoded. The premise of Unicode is to encode only that which is grammatically significant.

simply because it’s more fundamental;

Not so. Coded text can’t exist without typography.

There’s no reason to blow off typography as the icing on the cake. The system should work for everbody — art directors using small caps are no less important than ancient linguists studying dead languages.

Small caps are an integral part of the world system — Microsoft’s commitment in the ClearType fonts will see to that: small caps for Latin, Greek and Cyrillic; Regular, Bold, and Italic!

(Nick, I hope you weren’t counting
on soiled diapers to save your ideas
from being trounced. :-)

> The minimum requirement for upper vs. lower
> casing to be grammatically significant is size.

If that were true (beyond the banal absolutist/formalist
sphere) guess what wouldn’t work in practice: smallcaps! :-)

> grammatically redundant

It’s ironic that you suddenly seem to be missing
what makes it not redundant in the end: typography!

> Stop projecting your feelings onto me

Feelings? “I’m getting no reading, captain.”
What I’m doing is trying to figure out where somebody is going based
partly on where he’s coming from. In my book that’s a smart thing.

And nevermind that I used “perhaps”, and a question mark.
After all, it’s much harder to feel/act offended while noting tentativeness.

> The premise of Unicode is to encode only
> that which is grammatically significant.

I would friggin hope so, is my whole point.

> Coded text can’t exist without typography.

Sure. But it CAN exist without smallcaps, italics, etc.
What it can’t exist without (without changing the language)
is alphabetic casing. Why is this distinction so hard to accept?

> There’s no reason to blow off typography as the icing on the cake.

I agree - and I never do that. But seeing the difference
between orthography and typography, and accepting that the
former can’t simply be ignored, is still crucial.

> The system should work for everbody — art directors using small
> caps are no less important than ancient linguists studying dead
> languages.

1) No system can do that. Fortunately.
2) Some occupations are still more important to the world at large than others. Your example of those who study dead languages is a convenient extreme.

> Small caps are an integral part of the world system

Not even close.
Not even italics is.

hhp

The premise of Unicode is to encode only that which is grammatically significant.

I don’t think it is a premise, per se, but it is often the way it works out for a particular script. Unicode is guided by a number of conflicting principles, and in given situations one or more of these principles will trump others. For example, the principle of one-to-one compatibility with pre-existing standards has always trumped the character/glyph distinction principle. But Unicode precedes from a notion of ’plain text’, which is defined as ’Computer-encoded text that consists only of a sequence of code points from a given standard, with no other formatting or structural information. Plain text interchange is commonly used between computer systems that do not share higher-level protocols.’ Unicode encodes as characters that which is necessary to encode plain text, and one way of looking at this is to determine what is an acceptable loss of information when richly formatted text is interchanged as plain text between systems that do not share higher-level protocols. So the question is, is it acceptable to lose the distinction between upper and lowercase letters in Latin plain text? I would say no.

Positing a ’grammatical’ premise for Unicode is innacurate. Indeed, a criticism of the Unicode encoding of some scripts is that it does not correspond to how users think of their script in grammatical terms, or may reflect only one of a number of competing grammatological analyses of the writing system. The Tamil script is an interesting and controversial example. The Unicode encoding is based on the ISCII encoding (an example of the pre-existing standard principle), which treats Tamil in a way directly analogous to the North Indian Brahmic model. Some Tamils complain bitterly about this, pointing to the existence of a very ancient Tamil grammar that explicitly describes the structure of the script in ways that do not neatly correspond to the Unicode/ISCII encoding. This debate takes place against a political and cultural struggle. But the question that needs to be asked is whether an encoding needs to correspond to a grammatological analysis of a writing system? Isn’t it enough that the encoding works and, indeed, shouldn’t the practical considerations of computer text processing be the guiding principle of a computer text encoding standard? So the UTC and WG2 committees look at writing systems and made decisions about how to apportion handling between plain text operations and higher level protocols.

The idea that “oh that’s just fancy typography, the icing on the cake, so it doesn’t matter” is at the root of the way Unicode handles case.

I disagree. I don’t know anyone at Unicode who dismisses typographic display in this way: they just insist that it sits above the plain text level at which they encode characters. And they’re right. It is not their job to enable rich typography at the text encoding level. It is the job of systems and applications to enable rich typography at the higher level. As discussed much earlier in this thread, and as alluded to in your recent mention of menus being ’all over the place’, the problems you are describing are essentially user-interface issues. Sure, you can say that it would be easier for applications to solve these user interface issues if all five of the typographic cases you identify were encoded at the character level, but what other text processing functions would become more complicated if one did this? One shouldn’t build a text encoding standard around user-interface ease of design. That’s putting the cart well before the horse.

In any case, this is a very moot point, because there is no way that Unicode’s handling of casing for the Latin script is going to change. This is the architecture we have to work with, and the level at which we should be addressing it is in UI design and UI function interaction with font layout features.

The system should work for everbody — art directors using small caps are no less important than ancient linguists studying dead languages.

Trust me, the system currently works a heck of a lot better for art directors using smallcaps than for scholars studying ancient texts. Again, what we’re talking about for the former is essentially a user interface issue: how to present typographic controls in ways that make intuitive sense to a typographer. Further, the needs of the art director are typically quite simple: he needs an individual piece of text to look a particular way, often without needing to worry about the underlying text encoding at all because the result is to be output in a static medium.

seeing the difference between orthography and typography

That would be nice, but they overlap.
Unicode ignores the overlap by encoding capitals as separate characters, not by case.
So higher level protocols are left to hack the connections between A and a, etc., in order to perform functions like “all caps”.
“All caps” is rich-text typography, but it’s as basic to the standard WP software, MS Word, as holding down the shift key on a typewriter — not exactly art-director stuff.

I don’t know anyone at Unicode who dismisses typographic display in this way: they just insist that it sits above the plain text level at which they encode characters.

Sorry for the colourful figure of speech, but I suspect that the subtleties of expert typography may be perceived as a bit precious, hence the reluctance to incorporate a display function like casing.

Yes, this is all very moot.

> higher level protocols are left to hack the connections between A and a

Yes, but certainly not “hack”.
In fact the main benefit of unicode is greatly reducing hacks.

> the subtleties of expert typography may be perceived as a bit precious

Which, of course, they are.
We’re simply not very useful.

hhp

Hey, Unicode is awesome.
Complex typography is, er, complex — as always.
But in general, it’s all good.

All’s I know, is that I have over 100 styles either in flight, on the flight deck or ready to move into the elevator, that have been ordered by customers. What customers want in these styles are a, e, m, n, and u, and sometimes t and r, drawn to the size of the H, accented to the t, and kerned to all high heaven. (No one, has ever asked for e the size of small cap E, or H the size of x...ever, but maybe it’s because my customers are...justifiably valued). I’ve done some tests though, drawing and sending various forms, and what they are looking for is a special case to use for headlines, not l.c. or small caps, ever. You are the boss:
a. go to the end of the line and start registering ucbf, uppercase biforms.
use something else in the meantime (?), and then wait for updates to
ID that may or may not ever hardwire ucbf to show users “uppercase
biforms”, scramble and explain until complete, or denied.
b. send clients feature named something generic, like special style feature #1556, explain endlessly, because changing would be messy.
c. appropriate the “Unicase” feature to a useful task. Non-ambiguously state to customers and other vendors that neither you nor your users will see anything but lowercase forms drawn to the size of the H when this feature is selected.

But the general feeling is, if this was implemented better in one of several ways it’s be a lot less stupid a set of choices. If e.g. Features had tags and menu names, and apps just passed ’em through, and the market made the features market, not some clumsy bucket line, absolutely everyone would be happier.

If e.g. Features had tags and menu names, and apps just passed ‘em through, and the market made the features market, not some clumsy bucket line, absolutely everyone would be happier.

Except the application designers, who can’t resist adding faux features, which is probably why they are reluctant to just let the fonts be, and let users only get what’s in the font.

That might have been a good idea for PC Word users when fonts only had 250 characters, and there were hardly any digital fonts with expert sets, but the situation is different now.

Would there be an outcry from InDesign users if the next version didn’t enable them to create, for instance, superior figures for fonts that don’t have ’em? They wouldn’t even notice, with AdobeSans/AdobeSerif substitution.

Quark 7 still has a faux menu, and buries its OT menu. Aaaagh!

> They wouldn’t even notice, with AdobeSans/AdobeSerif substitution.

A very good point - and one that applies to every area,
including smallcaps, maybe even so-called “true” italics.

hhp

Right. If you’re not bothered using a font with special features, and are happy with faux features, you’re unlikely to be concerned whether your faux superior figure is from Times or AdobeSerif.

Paradoxically, you may be upset to get a true italic when you’re expecting a sloped roman!

NB. The AdobeSans and AdobeSerif MM fonts I’m referencing are OS 9, stored in the Acrobat Reader 5 folder, and only have a basic character set — no small caps.

> If you’re not bothered using a font with special
> features, and are happy with faux features

The thing is, and my point is, most people don’t even get that far! :-/
They don’t even realize there’s anything to be bothered/happy about.

> you may be upset to get a true italic when you’re expecting a sloped roman!

I actually know of one such case, and at the foundry level: when Joe Treacy subbed in a “true” italic for his Arrow family apparently his customers almost rioted. So now it has both.

hhp

David,

c. appropriate the “Unicase” feature to a useful task. Non-ambiguously state to customers and other vendors that neither you nor your users will see anything but lowercase forms drawn to the size of the H when this feature is selected.

I don’t think this is appropriating the Unicase feature at all: this is a perfectly valid use of the Unicase feature, as I stated at the beginning of this thread. It just so happens that the Unicase implementation illustrated in the feature tag description uses an Emigre typeface that matches uppercase forms to the lowercase x-height. But there’s no reason at all not to do it the other way around. Go for it. If you want to make it a house style rule for Font Bureau that the Unicase feature will always imply this kind of implementation in your fonts, that’s your prerogative.

There is also the option to ignore OpenType features and have a separate common case font.
Some of the advantages:
* With InDesign, the font menu is easier to get at than the OpenType menu.
* A straightforward size relationship of “capitals” and “small” (cased unicase) — having the two sizes is rather like optical scaling.

> like optical scaling

?

hhp

...Cased Unicase is like Caps with Small Caps, in that the two cases have identically shaped glyphs. So the larger size is lighter, more of a display treatment, while the smaller size has stronger features, more of a small text quality.

You were saying... hack? :-)

hhp

Caps with small caps is not a hack for optical scaling, as it is a genre of type which historically occurred before single-master (ie non-optically scaled) fonts.

“identical form in both cases, CcOoSsUuVvWwXxZz in Latin”

not u.

> Caps with small caps is not a hack for optical scaling ...

Now my question mark kicks in again.
It’s not a hack for what you seem to mean, but it very much is a hack when one uses any half-decent definition of “optical scaling” (a term you might consider appending to your New Year’s resolution :-).

> identical form in both cases, CcOoSsUuVvWwXxZz in Latin

“Identical form” is way too strong. The most that can be said is
that they share a structure... but then you have to graple with the
paradox that typographic (unlike for example chirographic) forms
don’t actually have structure (at least not the way we tend to see it).
It’s an illusion.

hhp

not u

Sure it’s the same, because the right side vertical stroke is redundant, a grace note.
Futura, for instance.
Linguistically redundant, but typographically helpful nonetheless.

“Identical form” is way too strong.

Right. I’m referring to the underlying skeletal form.

it very much is a hack when one uses any half-decent definition of “optical scaling”

That’s like saying a gramophone is a hack of a CD player.

> the right side vertical stroke is redundant

That of course makes no sense, not least because it leads
straight to formal hell. Pray tell: how does one determine
what’s redundant; what parts of what letters are redundant,
exactly; is the left stem of the “R” redundant - why [not]?

Nick, trust me, this direction leads to the greatest quagmire
in type design. Not somewhere an art director can be happy.

> I’m referring to the underlying skeletal form.

Except there isn’t one. And if there is, you’re conveniently
ignoring parts of it (like in the U/u) at whim anyway, so...

> That’s like saying a gramophone is a hack of a CD player.

?
Just add it to your Resolution and everything will be fine.

hhp

formal hell

Trust me, it’s the same character if the spelling’s the same.
The Casing/Bicameral system works (ie delivers orthographic significance) if readers can recognize two separate classes of glyphs underlying the setting/writing. Size is the main indicator. What the actual glyphs are shaped like doesn’t matter (they can even be the same shape), as long as the letters are recognizable, and categorizable by the principle of case. In this example, upper case is minuscule, and lower case is majuscule.

More from previously:
> I’m referring to the underlying skeletal form.

The more one thinks there are skeletons under there,
the more one stays distant from true text face design.

The good way to think about typographic glyphs (the kind that designers never make by hand but users always read by eye) is in terms of notan, in terms of borders, not in terms of thicknesses being built up from skeletons.

> it’s the same character if the spelling’s the same.

But the spelling isn’t the same. Your spelling there is Incorrect,
something that’s possible to state in orthography but not typography.
The best evidence would come if you asked people -especially those
who don’t know [of] me*- what that says. They might say... dunno...
“horizontal rant”?** But if you spelled it correcly they’re quite
likely to know it’s a proper name.

* Of which there still are a few I hope. ;-)

** And everybody knows that my rants are always vertical.

Also: Even if most people can read something spelled incorrectly
the way it was “supposed” to be spelled, that doesn’t say anything
at all about orthography.

> Size is the main indicator.

That’s crucially different than what you said before.

> What the actual glyphs are shaped like doesn’t matter

Maybe to some art directors.
To most other people they sure do matter.

—

But anyway you’re digressing - maybe because you don’t want to admit
that your stance on the U/u is wrong. Come on, it’s not that hard.

Anyway.
What I was getting at above is that you can’t make blanket statements about which parts of which characters (again, not the same as letters!) are “redundant” - certainly not without thinking quite deeply about it. Is the top-left “cornerness” of the UC “F” not “redundant”? If you make it round, it starts getting close to the lc form, so becoming part of your “UC/lc identical form” invention. And have you seen the lc “g” in the credits for Spongebob Squarepants? Is it really lc? In fact almost all the letters that are not in your List can be drawn quite easily in a way that they can be either UC or lc, so invalidating your U/u distinction. Futura has a lc “u” without a full right stem? Who cares. That says nothing about anything useful, like what the conventions are.

And when it comes to the U/u, instead of claiming the untenable “the lc form doesn’t require a full right stem to be conventional”* you should instead simply point out that some entirely conventional fonts (like Perpetua) have an UC “U” with a full right stem. This converse is parallel to the truism that You Can’t Prove Something Doesn’t Exist.

* You might say that’s not what you stated. But it’s the only sensical thing that can come out of your line of thought, if you really think it through. Conventionality is really the key concept here - simply because if you loosen things up virtually anything is legible!

The fact is glyphs never fall neatly into any box, including UC/lc.
Your categorization holds about as much water as a lc “n”. Without a full left stem.

hhp

you don’t want to admit that your stance on the U/u is wrong.

Instead of seizing on any little thing you think you can “score points” on, try to look at the big picture and understand my full argument.

Characters don’t change from Upper to Lower Case.
They may or may not look the same.
A is the same character as a, despite Unicode’s expedient definition.
Casing is necessary to support the orthographically/grammatically meaningful “Titlecase”, but it’s immaterial whether the glyph shapes are very dissimilar (A and a), debatably dissimilar (U and u), or the same (S and s, etc.). As you put it:

The fact is glyphs never fall neatly into any box, including UC/lc.

> try to look at the big picture

I always do, but since I know we disagree on it,
and since I harbor no hope of changing your mind,
the only thing left to discuss is the details, in the
hopes of helping third parties. And because talking
helps me think. And it’s fun.

> Characters don’t change from Upper to Lower Case.

Incorrect.

> A is the same character as a

No, it’s only the same letter.

> The fact is glyphs never fall neatly into any box, including UC/lc.

Glyphs, not letters.
And the point there was to explain how your stance on the U/u is wrong.

Your line of thought is only relevant in the context of convention.
In the context of convention, the lc “u” has a full right stem.

hhp

Hrant, your nit-picking over U/u is avoiding dealing with the crux of my theory:

1. Titlecase is the only grammatically significant use of casing.

2. In terms of grammar, Titlecase is a form of Inflection. Whereas most inflection signifies a grammatical feature by altering the spelling of a word, Titlecase does so by upper-casing the initial character, and lower-casing the rest.

3. This grammatical signification does not happen at the level of character, but at the level of display (ie typography), primarily through size contrast.

4. While there are conventional groupings of majuscule, minuscule, and unicule glyphs into case pairings (primarily Upper & Lower, and Caps with Small Caps), there is no direct correlation between case and “-cule”.

5. Unicase is a misnomer, as is common-case. This is demonstrated by the feasability of “Cased Unicase”, and the fact that “Unicase” can be either upper-case or lower-case size. Perhaps “multicule” would be more accurate.

6. For basic typography, the present system of “characterizing” the difference betweeen upper and lower case has expediency, but it creates problems further along, e.g. in assigning the appropriate figures for a particular case.

Avoiding it? The parts I thought were worth addressing,
I already have. But every new post of yours seems to
contain a new objectionable offshoot. Or three. :-)

The real avoidance Nick is you not admitting you’re wrong about
including the U/u in that list. Nitpicking? On the contrary, that
fault has opened up a line of discussion much more interesting to
me than the original topic or the direction you want to take.

hhp

The way the casing is handled in Futura, Bauhaus, Perpetua, Giovanni, etc. indicates that it’s acceptable to handle the U/u character as a “unicule” — i.e. the same structure in both upper and lower case.
As you say, it’s possible to design upper and lower with more commonality than is usual, and I’ve done that in Morphica.
Like I said, as long as the reader can discern from the text what design system the typeface uses to differentiate upper and lower case, and as long as the glyphs are identifiable as characters, anything goes.

> it’s acceptable to handle the U/u character as a “unicule”

But the point is that if/when that’s acceptable, then a bunch of other letters (maybe even all of them) can be “unicule” just fine too. So your list is either pointless because raw legibility is very lenient, or it should not have the U/u because it codifies convention. Why is this so hard to understand/admit?

> as long as the reader can discern from the text what design system
> the typeface uses to differentiate upper and lower case, and as long
> as the glyphs are identifiable as characters, anything goes.

In display design. Text faces are a whole other ballgame.
And as long as you think Eunoia-Text merits its suffix you
won’t be in that game.

hhp

Text faces are a whole other ballgame.

For you, more of a hobby horse.
How’s the Baskerville coming?

There’s the panic alarm going off in Shinnistan again...

Nick, you really think that admitting a mistake (it’s not even a major
one really) looks worse than acting like you don’t make any? Oh well.

hhp

The reason I included U/u in my list of “unicles” is because of faces like Cocon, Futura, Giovanni, Perpetua, etc., etc., etc. The practice of using the same form of U/u for upper and lower case is widespread — and done with both versions, with or without the right-side stroke extension. The casing of U/u is not like other bi-form characters such as N/n, where the typical lower case form may also be used in upper case, because there is a fundamental shape difference between N and n, and its majuscule form is not used in lower case. Simply put, the u’s stroke extension is not significant in distinguishing majuscule from minuscule, and as such is redundant to the basic letter form.

“Simply put, the u’s stroke extension is not significant in distinguishing majuscule from minuscule, and as such is redundant to the basic letter form.”

Oiy. Thou fiddleth around parts of characters while OT burns?

> the u’s stroke extension is not significant
> in distinguishing majuscule from minuscule

You’ve got to be kidding. It’s their main difference! And sometimes it can matter: picture “US” set in smallcaps in a sentence (in a font with the -traditional- x-height height smallcaps).

And that’s just the biggest thing wrong in your new post - I won’t get into the fundamental difference between “widespread” and “conventional” for one thing...

hhp

Thou fiddleth

I ain’t no emperor.
I do have the time to engage in banter on Typophile. But I wasn’t aware that there was a role for independent foundries in developing OpenType, which is the preserve of MS and Adobe — or layout interfaces, which is the preserve of MS, Adobe and Quark — or Unicode, which is the preserve of scholars and programmers, not typographers and type designers like me who are at a far remove from the business establishment.

I have the impression that if the concerns of Font Bureau are a cry in the wilderness, I’m just a whisperer, not a fiddler.

It’s their main difference!

Exactly. But it is so slight and variable (in all three widespread conventions, i.e. both cases with extra stroke, both cases without extra stroke, and stroke only on lower case), that it does not create clearly defined, oppositional majuscule and minuscule forms. Compare the blatant contrast between majuscule/minuscule forms here, and see why I group U/u with the unicules:

Even if the U/u contrast is exaggerated, as in Scala Sans, it’s very slight, less apparent than the alternate W/w forms, in fact.

“Engage in banter”? A likely story...

> it does not create clearly defined,
> oppositional majuscule and minuscule forms.

Type design is all about subtlety (not least because perception, and certainly reading, is all about subtlety). When we worry about the smallest details that might affect the reader, you can’t say that a full stem is irrelevant with a straight face. Not to mention that certainly the K/k, probably the Y/y, and possibly the P/p, are different to about the same degree; it’s increasingly clear that the line you’re drawing makes no sense (but that’s what happens when you’re more interested in winning an argument than seriously discussing type with a desire to grow, an ability to correct yourself).

hhp

Hrant, I may be intransigent, but I would rather banter than trade personal insults.
Could you please remove the “psychological insight” from your last post?

But of course it’s entirely OK for you to call
me a “clueless idiot”, mister “don’t ask Gerry
about Greek type”. You see, Nick, the only way
for people not to be able to hold stupid things you
say against you is if you formally retract them.
Be grateful you are being given the chance.
Otherwise, when you complain, you come off
as an unfair whiner.

Not that I will ever substitute cocktail-party civility for candor.

hhp

unfair
When you say that I am not a text type designer (which you frequently insinuate into threads) it is candour. When I say you are a clueless idiot (which I did once, upon provocation by your “candour”) it is stupid.

Even when I use your own benchmarks of what constitutes a personal attack and what doesn’t, you try to weasel out of it... Guess who else isn’t a “real” text face designer: me! But I think I’m at least heading in the right direction, while you have yet to do that. Only a despot would hold that up as an unacceptable personal attack. Having an ego is one thing (I would know), demanding adulation is another. And how did Gerry “provoke” you? By calling your Greek something like “in the vein of misguided Greek designs of the 70s”. Keep your ear on, Van Shinn.

BTW, if you think you were wrong to call me a “clueless idiot”,
there’s always the unthinkable recourse... Not that I care, since
it would basically be for your own benefit.

hhp

And how did Gerry “provoke” you? By calling your Greek type something like “in the vein of the misguided Greek designs of the 70s”.

Worse, he compared it with Times Greek, the ultimate diss :-)
But I must protest that my “Don’t ask Gerry about Greek” comment was made later, and not in anger, but jest — a type designer who, from his techno/grunge oeuvre, didn’t strike me as the calligraphic kind, wanted some pointers on Greek type design; it was in this context that I repeated Mr Leonidas’ advice to me to get liquored and start writing with a soft pencil.

Only a despot would hold that up as an unacceptable personal attack.

That wasn’t the consensus at Typophile last year, when OldNick, I believe, explained the principle of the ad hominem argument. It was generally agreed that the ad hominem argument should be avoided. You dissented. So I don’t know why I’m arguing this again. Have the last word, if you wish.

“I have the impression that if the concerns of Font Bureau are a cry in the wilderness,”

Maybe so, but the wilderness is closin’ in. Last week, the China.gov started the process of limiting the names of babies to glyphs in the first 15,000 of the std.. No more Chinese equivalents of DeShondra, Giselbert or Christian.