Floating diacritics

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!

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.
  • 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.
  • With combining accents, …

    image
  • Paul van der Laan
    Paul van der Laan Posts: 242
    edited November 2013
    Overlapping components are allowed in TrueType – making it possible to have certain glyphs with ogoneks and cedillas only made of components.
  • 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.).
  • Rainer you should write a combining accents tutorial!
  • Paul van der Laan
    Paul van der Laan Posts: 242
    edited November 2013
    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. ;)
  • 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?
  • John Hudson
    John Hudson Posts: 3,190
    edited November 2013
    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/
  • John Hudson
    John Hudson Posts: 3,190
    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.
  • 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?
  • John Hudson
    John Hudson Posts: 3,190
    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 work
  • 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.
  • 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.
  • John Hudson
    John Hudson Posts: 3,190
    Ooh, I like the Elfdalian y̨: that could be made a very elegant form. Thanks, Denis.
  • Duh.
  • Doh! I meant ‘there are’.
  • "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.
  • Thanks for the info, Denis!
  • 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....
  • 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/