Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Best Of

  • Re: ‘Grand Cru Classés’ sprouting from Antwerp soil

    Wednesday 23 November Inside/Outside, the Expert class Type design / Expert class Book design 2016 exhibition, will open at Kades-Kaden in Antwerp!

  • Type Software Survey

    We’re working on a State of the Union for Type Design Software.

    If you design type, please fill out this form:
    It shouldn’t take more than four minutes and your individual answers will be kept confidential. Thanks so much in advance!
  • Re: Multiple contextual alternates in sequence, based on proximity?

    Regarding floating lookup blocks: Generally, lookups [groups of rules] are compiled in the same order as the feature blocks in which they are declared. And typically, this is how you want it (and why you pay attention to the order of your feature blocks).

    However, sometimes there are multiple feature interactions where, when two features are activated at the same time, you want some rules in a downstream feature to take precedence over rules in the upstream feature — but not *all* rules (otherwise, you’d just reorder the features, right?).

    If you declare a lookup block on its own, outside of a feature block, it gets compiled in the order in which it actually appears, regardless of the order of the feature block(s) that it gets registered to. (Last I checked, this is an advanced subtlety that Tal doesn’t explain in his excellent OpenType Cookbook primer.)

    Here are some hastily composed, abstract examples.

    In the following example, you have two features with two sets of substitutions, both for x and y.
    feature ss01 {
    sub x by x.001;
    sub y by y.001;
    } ss01;

    feature ss02 {
    sub x by x.002;
    sub y by y.002;
    } ss02;
    Pretty standard. If both Stylistic Set 1 and 2 are active at the same time, then the .001 alternates will be rendered.

    But suppose that, when both Sets are active, you would want the y.002 to be displayed but the x.001 to still take precedence? The solution is to declare the y.002 substitution as a lookup outside a feature block and before the ss01 feature.
    lookup y2 {
    sub y by y.002;
    } y2;

    feature ss01 {
    sub x by x.001;
    sub y by y.001;
    } ss01;

    feature ss02 {
    sub x by x.002;
    lookup y2;
    } ss02;
    In this case, the y.002 substitution is still deployed by the ss02 feature, but the lookup itself is compiled ahead of the ss01 feature lookups. So, when both features are active simultaneously, the y.002 substitution is found first and gets implemented, despite the ordering of the features (which still determines how x gets handled).

    This advanced technique is usually only necessary when dealing with complex multi-feature and cross-feature interactions.

    I’m not sure this will be necessary in your case, since it seems like you’re talking about everything happening within just a single liga (or calt) feature.
  • Digital Times (New) Roman

    (I'm sure there is something about this in the Typophile archives… but of course we have no access to that anymore. Long post warning, probably suited better to a blog.)

    What's going on with all the Times (New) Roman's? I found today there's a 'Times New Roman PS' which according to Google Translated German Wikipedia:
    Times New Roman is Microsoft's name for the Trueype version of Times New Roman PS, a narrower version of monotypes classic type. The PS version was introduced at the request of Microsoft Monotype in order with the dimensions of the Times Roman (one of the PostScript coincide -Kernschriften Linotype). She has finer capitals that were originally designed for printing German texts (because here, in contrast to the English seem very much more capital letters).
    I dug around a bit more and found Times (New) Roman and its part in the Development of Scalable Font Technology by Charles Bigelow, 1994:

    The outcome of all of the legal maneuverings is that Linotype and its licensees like Adobe and Apple continue to use the name "Times Roman", while Monotype and its licensees like Microsoft use the name "Times New Roman".

    During the decades of transatlantic "sharing" of the Times designs, and the transfer of the faces from metal to photo to digital, various differences developed between the versions marketed by Linotype and Monotype. Especially these became evident when Adobe released the PostScript version, for various reasons having to do with how Adobe produced the original PostScript implementations of Times. The width metrics were different, as well as various proportions and details.In the late 1980's, Monotype redrew its Times New Roman to make it fit exactly the proportions and metrics of the Adobe-Linotype version of Times Roman. Monotype claimed that its new version was better than the Adobe-Linotype version, because of smoother curves, better detailing, and generally greater sensitivity to the original designs done for The Times and Monotype by Victor Lardent, who worked under the direction of Stanley Morison. During the same period, Adobe upgraded its version of Times, using digital masters from Linotype, which of course claimed that it had a superior version, so there was a kind of competition to see who had the most refined, sensitive, original, genuine, bona-fide, artistically and typographically correct version. Many, perhaps most, users didn't notice and didn't care about these subtle distinctions, many of which were invisible at 10 pt at 300 dpi (which is an em of 42 pixels, a stem of three pixels, a serif of 1 pixel, and so on).When Microsoft produced its version of Times New Roman, licensed from Monotype, in TrueType format, and when Apple produced its version of Times Roman, licensed from Linotype, in TrueType format, the subtle competition took on a new aspect, because both Microsoft and Apple expended a great deal of time and effort to make the TrueType versions as good as, or better than, the PostScript version. During the same period, Adobe released ATM along with upgraded versions of its core set of fonts, for improved rasterization on screen. Also, firms like Imagen, now part of QMS, and Sun developed rival font scaling technologies, and labored to make sure that their renderings of Times, licensed from Linotype in both cases, were equal to those of their competitors. Hence, the perceived quality of the Times design became a litmus for the quality of several font formats. Never before, and probably never again, would the precise placement of pixels in the serifs or 's' curves etc. of Times Roman occupy the attention of so many engineers and computer scientists. It was perhaps the supreme era of the Digital Fontologist.As for the actual visual differences in the designs, well, like any good academic author, I leave the detection and analysis of those "as an exercise for the reader".
    Something from the English Wikipedia page for Times New Roman:
    Linotype licensed its version to Xerox and IBM, then Adobe and Apple, guaranteeing its importance in digital printing by making it one of the core fonts of the PostScript page description language. Microsoft's version of Times New Roman is licensed from Monotype, hence the original name. For compatibility, Monotype had to subtly redraw their design to match the widths from the Adobe/Linotype version. It has the lighter capitals that were originally developed for printing German (where all nouns begin with a capital letter). Versions of Times New Roman from Monotype exist which vary from the Linotype metrics (i.e. not the same as the version for Microsoft). In addition, the original digitisation of Times New Roman omits automatic ligature insertion, which the version of Times installed with OS X has. (This results in unsightly character collisions with the system version of Times New Roman whenever the characters 'fi' are needed.)
    Apple: Times Roman, Linotype
    Microsoft: Times New Roman, Monotype
    Later Monotype redrew its Times New Roman to fit proportions & metrics of Adobe-Linotype's Times Roman. Then Adobe upgraded it's version of Linotype Times.

    A couple questions though
    1. Are any of these original Linotype Times Roman and Monotype Times New Roman from pre-late-1980's around?
    2. a. What is 'Times New Roman Pro PS' I understand from the above German Wikipedia page for Times that it could be the late-1980's redraw of Monotype Times New Roman to match the Adobe-Linotype Times Roman's metrics, and I'm guessing PS refers to PostScript; but the drawings and spacing are slightly different.
      b. and what is 'Times New Roman Pro'—it's metrics are different, i.e. wider, even wider /a — perhaps a TNR that is closer to the original metal version?

    3. What specifically is meant by "for various reasons having to do with how Adobe produced the original PostScript implementations of Times. The width metrics were different, as well as various proportions and details."?
  • Font-specific emoji

    Is this a thing? *when* will this become a thing? Who doesn't want a Garamond :taco: or a Gotham :heart eyes:? I feel like this would've made a great Typophile battle, back in the day.
  • Grocer's ₹

    Since the Indian rupee symbol was introduced 5 years ago, has a casual style of writing it developed? After the euro symbol was introduced, it didn't take long for grocers to write it like a C with a single stroke. Has anyone seen handwritten rupee symbols in the wild? Are people drawing two separate strokes, including the top stroke without lifting the pen, not bothering with the top stroke at all, or something else?
  • Cyrillic italics vs. obliques

    When designing Cyrillic, some of the italics can take vastly different forms.

    But in some Cyrillic designs, the italics are oblique and the letterforms don't change. I'm trying to figure out the borderline where these traditional forms would be inappropriate.

    If I were doing an old timey Cheltenham sort of design, I'd go with the alternate (traditional) italic Cyrillic forms.
    If I were designing a square, high-tech spaceship font, I'd likely go with oblique forms.

    But I'm not sure where the borderline is. When I look at Paratype's italics, News Gothic has oblique forms while Humanist 521 and Journal Sans have traditional forms.

    It seems like the borderline has to do with "how italic" the a-z is.

    An oversimplification:

    1: Just slanted
    2: A bit more italic: the f has a descender and the a in monocular
    3: Somewhat italic: curls have sprouted
    10: Full blown Caslon

    Bell Gothic has a italic that would be somewhere between 2 and 3 yet it has the traditional Cyrillic italic forms.

    And Futura has oblique forms.

    Is it a case of "how humanist" the design is?

  • Re: Naming font styles in various languages

  • Re: Font editor of choice??

    Göran, I've been evaluating Glyphs 2.0 lately (and the beta some before that), and I'm very pleasantly surprised. I said three years ago that I was going to try both RoboFont and Glyphs, but I was so taken with RoboFont that I never got around to giving Glyphs a serious try. Now I have, and, although I'm not going to abandon RoboFont and my other UFO-based tools (they can do a lot of useful and amazing things), I will probably switch to Glyphs as my main production tool.

    The built-in TTF hinting was one of the things that got my attention because, until now, none of the TTF hinting workflows that I've seen was very practical to me, mainly because the TTF hinting was towards the end of the production process and necessitated forking my font data into separate OTF and TTF production files at some point. I really hate having multiple sets of source files. Glyphs lets you do the TTF hinting very early in the design on the interpolation masters and before removing overlaps! This is huge, because it means means the hinting becomes part of the design process, and the burden of manual hinting (when it is necessary) becomes much more manageable. (It's very much in line with what Petr van Blokland spoke about three years ago at Robothon.)

    So far, I am pleased with the hinting results I'm getting on Windows. Testing does require moving the TTFs to a Windows machine (VMWare in my case), but it only takes a few seconds to see a preview for each new itteration.

    Aside from that, Glyphs 2.0 has other advantages that are making me take it seriously:
    • Speed
    • Much smaller, fewer, and more manageable data files which means it will be practical to use it with things like Dropbox. (Example: 24 font family: 6 interpolation master UFOs + 24 instance UFO files totaling 160MB vs 1 Glyphs file totaling 2.5MB, plus each UFO is actually a folder containing hundreds or thousands of .glif files)
    • More focussed and integrated UI
    • A much simpler workflow than anything else I've used, which lets me focus on design
    • Although it's not as seamlessly integrated as it is with RoboFont, I can still do my kerning in MetricsMachine
    It does have it's quirks and annoyances, but I'm very impressed.