Case sensitive forms

I can't seem to find this in the FontLab manual, but I want to add dashes for capitals so now I'm wondering how to go about adding this case feature.

Also, which glyphs in your experience require special case forms (excluding diacritics)?
«1

Comments

  • Nick ShinnNick Shinn Posts: 2,129
    Usually, all the brackets, lining figures, questiondown and exclamdown, and guillemets.
    And the dashes, despite the fact that I think they look strange raised.

    But I don’t bother with an alternate bullet.

    If a typeface has “three-quarter” height lining figures, I make alternate sets of lining figures (proportional and tab) at cap height, also weighted and proportioned for all-cap settings.

    Occasionally, an italic font will need a different exclam for all caps.
  • Martin SilvertantMartin Silvertant Posts: 166
    edited November 2014
    Thanks for the information. Is there a particular reason why you don't bother with an alternate bullet?

    As for the dashes, I read you think it doesn't look right in between serif T-T. Is that why you don't think it looks right or generally speaking as well? Because I often think the dashes are positioned too low when text is set in all-caps.

    So how do I implement this case feature? If it's in the FontLab manual a reference to the page would suffice.
  • Mark SimonsonMark Simonson Posts: 1,651
    edited November 2014
    A simple way to do it is as a substitution. Create alternate glyphs designed to look good in all caps settings using copies of the default glyphs, and then do something like this:

    feature case {
    sub hyphen by hyphen.case;
    ...etc.

    It's also possible to do it by modifying the positions of the glyphs rather than doing substitutions, but I've never tried it.
  • Using positing does not work. If you move the glyph up a bit the underline (in a link) will move up, too. I don't know if this would be a bug in the rendering engine.
  • Ray LarabieRay Larabie Posts: 1,376
    These days, what apps properly support vertical positioning? For example, if I wanted to raise a hyphen: pos hyphen <0 80 0 0>;

    It works in the FontLab preview window but what about elsewhere?
  • Kent LewKent Lew Posts: 905
    These days, what apps properly support vertical positioning? For example, if I wanted to raise a hyphen: pos hyphen <0 80 0 0>;
    We’ve experienced some anomalous behavior before when trying to use GPOS for {case} punct. As I recall there was an issue with soft hyphens getting “pinked out” or .notdef’ed in InDesign. It may have had to do with double-encoding (or not double-encoding, or some such) or with some other aspect that might have been ultimately fixable; but we quickly abandoned the approach rather than trying to resolve all issues.

    It’s also possible that the underlying issue may have resolved itself in later versions of the app — this was back circa CS4, if I recall correctly. I haven’t bothered to experiment more recently.

    Furthermore, using vertical positioning for {case} makes any additional kerning adjustment more difficult, in case that matters for the design (for example, dashes & guillemets with A). You could probably include additional contextual horizontal adjustment in the {case} feature while you’re at it, but you would need to calculate it as additive to any base kerning, and the whole process would obviously be cumbersome to manage.

  • I usually include the following glyphs in the case feature:
    hyphen, en dash, em dash, exclamdown, questiondown, the four quillemets, parenthesis, brackets, braces, period centered and, of course, the bullet.
    In a related theme, the same applies for Tabular Figures.
    Many people only include the tabular figures (0 to 9), and forget to add tabular version of the related glyphs (punctuation, math symbols, monetary symbols, etc.)
  • Nick ShinnNick Shinn Posts: 2,129
    In Fontlab, make two classes, one for “before” i.e. the default characters, and another for the replacements, e.g. hyphen. case

    Then, in the feature panel, you just need one entry for case:

    sub @case_default by @case_alts ;

    You can name these classes anything you like.
  • Nice. Thanks.

    Making an alternate for @ also seems like a good idea.
  • Nick ShinnNick Shinn Posts: 2,129
    But when would anyone ever set an email address in all caps?
  • On a business card for a law firm.
  • Or when the address is part of an all-caps headline.
  • Martin SilvertantMartin Silvertant Posts: 166
    edited December 2014
    Even if its use is obscure, I would like to include it.
    Then, in the feature panel, you just need one entry for case:

    sub @case_default by @case_alts ;
    How do I do this? Right now I have the following:
    feature case {
    sub @case_default by @case_alts;
    } case;

    I also created two classes, but the feature doesn't appear in the OT preview panel. In which of the features should I put the substitution?
  • Chris LozosChris Lozos Posts: 1,458
    Martin, Here is one of mine:
    feature case { # Case-Sensitive Forms
    # Latin
    sub @case1 by @case2;
    sub @case3 by @case2;
    sub @num by @capNUM;
    sub @onum by @capNUM;
    } case;
  • Chris LozosChris Lozos Posts: 1,458
    I keep them separate so I can plug and play with different fonts as needed.
  • What about math symbols? I've seen 'plus', and 'asciitilde' used in dictionaries aligned with x-height (maybe because of oldstyle figures), but they're typically aligned with cap height in most fonts.
  • How come the case feature doesn't appear in the OT preview panel though? A soon as I add this case feature I can't generate a font anymore, either. When I click on "compile" it goes straight to the case feature, which makes me suspect I'm doing something wrong there.
  • Chris LozosChris Lozos Posts: 1,458
    edited December 2014
    check your syntax? did you leave out a semicolon? mistype something? Have different number of items in the classes in question? Perhaps you should contact whoever supports the software you are using?
  • The case feature is triggers by the 'TT' button in the toolbar.
  • Ray LarabieRay Larabie Posts: 1,376
    "You could probably include additional contextual horizontal adjustment in the {case} feature while you’re at it, but you would need to calculate it as additive to any base kerning, and the whole process would obviously be cumbersome to manage."

    True. Plus you'd need to calculate horizontal adjustments for italics.
  • I don't know what I did wrong before but the case feature is working now.

    When I preview the case feature in the OT panel, obviously only the glyphs I put in the classes are changing but the lowercase letters are not changing to uppercase. Is this correct? As I understand it the lc>UC feature is handled by the program while the case feature includes the case punctuation.
    I keep them separate so I can plug and play with different fonts as needed.
    So do you use this only during the design process?
  • Chris LozosChris Lozos Posts: 1,458
    Martin, what I mean is, every typeface that I design does not have the exact same OT features. Some don't have math operators in each case so I make a separate substitution to make it simpler.
  • Is this correct?
    Yes.

    (Some friendly advice, for what it's worth: People here are happy to help, especially when it comes to things beyond the basics, but, if you are serious about making fonts, you will get farther faster by taking advantage of the copious online documentation about OpenType and fonts in general. Maybe you have been, but, for instance, if you had looked at Adobe's documentation about OT feature tags (http://partners.adobe.com/public/developer/opentype/index_tag3.html) you would know the answer to the case feature question. Just saying.)
  • Martin SilvertantMartin Silvertant Posts: 166
    edited December 2014
    Maybe you have been, but, for instance, if you had looked at Adobe's documentation about OT feature tags (http://partners.adobe.com/public/developer/opentype/index_tag3.html) you would know the answer to the case feature question. Just saying.)
    I saw the list, but I didn't know how to implement the feature. You helped me, but then Nick told me a better way to implement it. I copied Nick's feature but I made a typo somewhere so the feature didn't work, which confused me further. I understand there are lists of the features, but I find explanations of implementations to be lacking. I often get the feeling a certain amount of insight is required to make sense of this kind of information and I have a lot yet to learn about the technical side of making fonts. I learned most about OT features, classes, kerning etc. in the last year. I feel I learned a lot in a short time, but never had official training so I lack some insight here and there and am therefor quicker to ask my questions online.

    Also, by asking these questions here, I usually get a lot of extra information. Honestly I think I'm learning more by asking you guys. For example, I don't even know where I would have found how the case feature actually functions. Adobe gives some information, but the answer to my last question wasn't there.

    I would also never have learned what Chris Lozos mentioned. It helps tremendously to get some insight into how you guys work. It's also a matter of confidence. The longer I work alone or even completely offline, the more I start to wonder what I'm doing is correct. There are no type designers around me and no one who can help me at the art academy, so I'm posting my questions here.
  • Sorry about my attitude there. On reflection, my answer was a bit harsh.

    Don't know if you know about it yet, but here is a really good site for learning about feature coding:

    http://opentypecookbook.com
  • Chris LozosChris Lozos Posts: 1,458
    That is pretty cool, Mark! I didn't know about that site before, thanks!
  • Martin SilvertantMartin Silvertant Posts: 166
    edited December 2014
    Sorry about my attitude there. On reflection, my answer was a bit harsh.
    I get it though, but I have my reasons to ask these questions here. That is not to say I don't do my own research, but I find with the technical stuff you often really have to know what you're looking for specifically.
    There are no type designers around me
    Slight correction: Jasper de Waard lives near me but we haven't met.
    Don't know if you know about it yet, but here is a really good site for learning about feature coding:
    Very nice source of information.

    I suppose this is getting off-topic, but creating a new thread for this doesn't seem entirely justified. I read you can specify features according to language and they use Dutch as an example:
    script latn;
    language NLD;
    sub IJ by IJ.dutch;

    I understand this is just an example, but it made me wonder if features are specified in relation to Dutch at all. I usually add a contextual alternate for I_J where the tail of /J is shortened but sometimes I also add a proper digraph for the Dutch language, but I've never restricted this feature to only Dutch. Does anyone know if this is recommended? What about Afrikaans?

    Also, if I were to add a feature to substitute (C) with ©, which symbol do I use to make sure the parentheses are part of what should be substituted?
Sign In or Register to comment.