Floating diacritics
Max Phillips
Posts: 474
I draw all my ogoneks as integral parts of the base glyph. So can I omit floating ogoneks from the glyph complement, or are there apps out there that need them?
And while I've got the mic: why do some fonts have what seem like duplicate floating accents, like acute and acutecomb?
Thanks!
And while I've got the mic: why do some fonts have what seem like duplicate floating accents, like acute and acutecomb?
Thanks!
0
Comments
-
And while I've got the mic: why do some fonts have what seem like duplicate floating accents, like acute and acutecomb?
The acute is spacing and the acute comb is none spacing. The latter is used for the mark feature.0 -
I can't speak specifically for Polish but base accents are dead key glyphs used when someone has to type the accent and then the base glyph (pressing Option-i then u briefly shows the glyph ˆ and then changes to the glyph û). -comb accents are combining accents, which are repositioned dynamically not substituted by precomposed glyphs.0
-
With combining accents, …
0 -
Overlapping components are allowed in TrueType – making it possible to have certain glyphs with ogoneks and cedillas only made of components.0
-
There are reasons not to do overlapping components which hold true for both outline formats, notably glyphs misbehaving when effects are applied to them (outline, shadow, etc.).0
-
Rainer you should write a combining accents tutorial!1
-
There are reasons not to do overlapping components which hold true for both outline formats, notably glyphs misbehaving when effects are applied to them (outline, shadow, etc.).
I have no problem to discourage the use of outline and shadow effects.2 -
Thanks for the clarifications, everyone.
But just so I understand: can I omit the floating ogonek, even though Truetype knows how to make use of one?
And Jackson: what's a dead key glyph?0 -
what's a dead key glyph?
A deadkey is a keyboard input mechanism, by which a sequence of two or more keystrokes input a single character. I presume Jackson meant that the spacing accent signs are glyphs to represent characters in deadkey input sequences. That's certainly one of the ways these characters have been used, but basically they're legacy compatibility encodings (which is why no new spacing accent marks are encoded beyond the basic set covered in pre-Unicode 8-bit sets).
It is useful to realise that in a Unicode+OpenType text environment, the relationship of keystrokes to characters to glyphs is
[n] -> |n| -> /n/1 -
Max, combining ogonek is one of a handful of marks that don't fit comfortably in a positional class with others, because of the various ways in which it may combine with a base glyph. In general, I don't prioritise positioning for such marks, as their use on bases not handled with precomposed encodings seems rare. I've only once been paid to provide GPOS for all marks on all bases. That said, if you did want to provide some positioning data for the combining ogonek, I think you would be safe in assuming that the mark only applies to vowels.0
-
But just so I understand: can I omit the floating ogonek, eve
If you have to make it anyway, and if it's remotely possible that any user anywhere might want to stick it up the C's undershoot some other way, name their magazine with a funny letter, bump something realistic into an underlying ascender or some such thing, what exactly would be lost, beside some tiny bit of space... by Including it?0 -
what exactly would be lost, beside some tiny bit of space
Time, which you will never regain? Of course, you could just slap the combining ogonek in the below marks central class, and let it inherit that anchor positioning. But if you were to try to provide optimal positioning for the ogonek on all bases, it can be a lot of extra work1 -
If you have to make it anyway […] what exactly would be lost, beside some tiny bit of space... by Including it?
Well, that's the thing: I don't have to make it anyway. I draw all my ogoneks as part of the base glyph. And if I have to make one and position it, it'll probably come out half-assed unless I spend a bunch of time on it, and I'd rather not do something half-assed. And I've got a sort of aesthetic objection to cluttering up a font with a lot of vermiform appendixes. And as John says, life is brief.
Thanks for all the info, John and others.
1 -
JH:
That said, if you did want to provide some positioning data for the combining ogonek, I think you would be safe in assuming that the mark only applies to vowels.
The combining ogonek can be spotted with y, as a vowel in Elfdalian, but also with m, t and some additional letters æ, ø, ɔ in older scholarly stuff. I assume their are more cases.
Of course you probably don’t want to support those cases with most common fonts.1 -
Ooh, I like the Elfdalian y̨: that could be made a very elegant form. Thanks, Denis.0
-
Duh.0
-
Doh! I meant ‘there are’.0
-
"Doh! I meant ‘there are’."
Exactly. So why anyone would suggest deleting the floating diacritics, is right next to why anyone would think we are here to save time for anyone other than the user. As precious as our time is, it's nothing compared to the time we save them.1 -
Thanks for the info, Denis!0
-
It's an age-old problem. Is it better to have the support even if it is imperfect? Or to only do things "right" and well?
Given that most apps and OSes will do fallback fonts if the font does not support the character, I submit that for your users on those apps, you are not even possibly doing them a favor by deliberately omitting combining diacritics, because fallback is going to be much worse than a badly-positioned or badly-joined diacritic.
If a significant portion of your users needing such characters are on apps that just shoot notdefs in such cases (e.g. Adobe creative apps), then it's a different calculus. Would you rather your users get somewhat inferior results with your typeface, or be forced to use a different typeface altogether (or do some difficult workaround)?
You can probably tell from my wording that I am in favor of more functionality when possible, these days. However, it is unfortunate that my current tool of choice (FontLab Studio) does not yet have the relevant mark attachment features, which would make me more inclined to do this. If only I could turn anchors into mark attachment points for arbitrary marks....0 -
However, it is unfortunate that my current tool of choice (FontLab Studio) does not yet have the relevant mark attachment features, which would make me more inclined to do this.
Well, my tool of choice happens to do exactly this. Or, you could write a Python script for the job.Rainer you should write a combining accents tutorial!
Actually, I did! It has been a while, and I could update the text a little, but here it is:
http://www.glyphsapp.com/tutorials/mark-to-base-positioning/
http://www.glyphsapp.com/tutorials/mark-to-mark-positioning/2
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 799 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports