Regular vs Book

Hello folks — I have got a question in regards with type weight, in particular when making a Regular and a Book version. What would be the purpose of a Book version in your opinion? Does it do something point size wise that a Regular cannot? 


  • That has been discussed on other threads already.

    If you define it as a weight between light and regular the use follows common typographic rules regarding performance in print, on-screen or readability. If by “point size wise” you mean it could have a different stroke contrast, I would say it is quite unusual to apply that to one single font style only.

  • John HudsonJohn Hudson Posts: 2,863
    edited April 17
    I’m working on a new variable version of our Euphemia family, and since Ross’ original Regular is quite light, I have opted to call the OS/2 weight class 500 instance ‘Book’, since it is close to the weight I would probably choose for 10 or 11 point text.



  • edited April 17
    I see... that's a very helpful information John and Philip, thanks!
  • John SavardJohn Savard Posts: 1,073
    edited April 25
    Hermann Zapf wanted to call the typeface Aldus Palatino Book instead, so comparing Aldus to Palatino would be another example. And there's Bodoni and Bodoni Book.
    If a typeface is designed principally for use in books or other purposes with similar needs, obviously there's no need for a "Book" version of it. But if, instead, the basic idea of the typeface is suitable to both a display face and a text face, then one way to distinguish them would be to call the display face by the basic typeface name, and add "Book" to the text face. I think there are examples, although I can't recall one offhand, where it was done the other way around, by adding "Display" to the display face.
  • Craig EliasonCraig Eliason Posts: 1,366
    That comment arrives at the drawback of “book” as a label: it feels like an optical size but usually is a weight
  • Nick ShinnNick Shinn Posts: 2,098
    I recently read We Were Eight Years In Power by Ta-Nihisi Coates, published by Random House in 2017. The colophon identifies the typeface as Bembo, but it is good and solid, so appears to be Bembo Book, and is lovely to read, for my ancient eyes.

    I would say that the extra “grading” (and this is not just press gain) of Bembo Book when printed by offset lithography compensates for the missing “druk”, that occurred with the original Bembo in letterpress. And as John Hudson mentioned, the first digitization of Bembo was made from font artwork, not a printed image, so was a little on the thin side. 
  • John SavardJohn Savard Posts: 1,073
    That comment arrives at the drawback of “book” as a label: it feels like an optical size but usually is a weight

    Is that a drawback?
    Yes, the "Book" form of a typeface, compared to its regular form, has many of the same differences that you would find in a smaller optical size of the typeface.
    But by making it a weight instead, it becomes easier to specify.
    And, incidentally, it would not be impossible to have "Regular" and "Book" forms of a typeface that was also optically sized.
  • John ButlerJohn Butler Posts: 195
    edited April 27
    And as John Hudson mentioned, the first digitization of Bembo was made from font artwork, not a printed image, so was a little on the thin side.
    I agree, although the first digitization looks quite good at fourteen point.
  • I totally agree with @John Hudson's views. My feeling was that 'Book' felt a pinch heavy on the digital environment but ideal for printing body text. I wonder whether the potential customers are not confused or simple not well informed about these nuances when they see a type family they like including these two variants. I was...
  • Nick ShinnNick Shinn Posts: 2,098
    In the digital era, Fontlab, for one, contributed to the confusion, by assigning the numerical value of 400 to all three of Book, Regular and Normal weights, in its Font Info dialogue.
    Therefore, if a FL user wanted to include two of these weight names in a typeface, it was debatable which should officially be the heavier, and which the lighter, with the result that in practice, from different foundries, both resulted.
    Although Book does occur higher up the list, suggesting that it is the lighter:

  • John ButlerJohn Butler Posts: 195
    Another good example to compare is Gentium vs Gentium Book.
  • Thomas PhinneyThomas Phinney Posts: 2,632
    @Nick Shinn

    The OpenType spec itself indicates that Regular and Normal share the same weightclass, 400.

    It does the same thing with ExtraBold and UltraBold (both 800), and Black and Heavy (both 900).
  • Chris LozosChris Lozos Posts: 1,457
    It does the same thing with ExtraBold and UltraBold (both 800), and Black and Heavy (both 900).
    I sure wish it indicate order did so we can end this wishy-washy lack of ordinal listing.  Why not 850 and 950?

  • Mark SimonsonMark Simonson Posts: 1,629
    edited May 5
    Because some ancient version of Windows couldn't deal with weightclasses that weren't evenly divisible by 100.
  • John HudsonJohn Hudson Posts: 2,863
    The subset of valid usWeightClass values (1–1000) that are mapped to nominal weights could certainly be supplemented by additional named weights, but at this stage this would be likely to produce a lot of inconsistent and non-standard font name/weight mappings. About the only common one that seems fairly consistently implemented is 

    350 = Semi-light
  • John ButlerJohn Butler Posts: 195
    A counterexample to Gentium and Bembo is Veljóvic’s recent design Agmena, whose Book weights are lighter than its Regular weights. The plot thickens. And thins.
  • I realize we all avoid Eric Gill nowadays, but back when it came out, I really liked (and bought!) Gill Sans Book. It seemed a lot more useful at that time, given what had been available.

    And Nick alluded to “grading”... I think I was initially cool on the “grades” concept that David Berlow has been advocating in recent years, but these days I love it. I think I could do a lot with a good grade axis in any variable font, in much the same way people are thinking about book weights here.
  • Dave CrosslandDave Crossland Posts: 1,347
    Why were you less keen back then? What experience changed your position? (I've obviously always been a true believer 😄)
  • No reason I could explain very well for being less keen. I suppose at the time I saw grades as too specialized for everyday users, when I was (professionally) more vested in simple solutions for average designers.

    I think grades fit very well into the variables ecosystem, and as a designer I see grades as a powerful, problem-solving tool. Subtle, usually, but that’s what good typography is all about. For anyone who is going to go out of their way to even consider a book weight over a “regular” weight, it seems like grades are a good idea.
  • Dave CrosslandDave Crossland Posts: 1,347
    Ah yes, got it :)

    I have been promoting the value proposition of variable fonts as in 3 parts: to compress, to express, and to finesse. The important thing about finessing typography with variations is that it can largely be automated, such that complex and subtle things like grade are actually and in fact simple solutions for average designers -- at the application level, where the automation is coded.
  • John HudsonJohn Hudson Posts: 2,863
    edited June 3
    finessing typography with variations is that it can largely be automated

    That’s been a conceptually attractive aspect of variable fonts since their beginning, but I wonder if anyone can point me to practical applications of automated finessing of typography with variations?

    I was thinking a couple of days ago about alternatives to David Berlow’s parametric variatons model: mostly in the context of wondering if one might achieve 80% of the flexibility with 20% of the effort and unusable design space (not specifically those percentages, but you get the idea). And an attendant thought was that automated finessing of typography seems a natural fit for AI, and that even non-parametric variable fonts probably have sweetspots for best-fit for a given purpose that someone trying to apply manual variations might miss in an even moderately large and complex design space of two or more optical instances.

  • Dave CrosslandDave Crossland Posts: 1,347
    CSS font-optical-sizing
  • John HudsonJohn Hudson Posts: 2,863
    edited June 4
    Optical design size selection is pretty basic: is it all we have to show for typographic automation in seven years of OT variable fonts? It doesn’t seem much of an achievement to finally being able to automate something on these exciting new computational machines that a) was an inherent aspect of typogaphy for  500+ years and b) doesn’t depend on variable technology.
  • Thomas PhinneyThomas Phinney Posts: 2,632
    Although it doesn’t DEPEND on variable technology...
    1) the data sizes for a good set of optically sized non-variable fonts are ginormous compared to their variable counterparts
    2) we originally mostly lost optical sizing in the move to phototype, so we have been without for 50 years and more than one generation of tech
    3) even if the optically-sized fonts are available manually, average users with access to them are more likely to mis-use them than use them correctly. We once had an internal contest at Adobe, and this particular aspect of the results was rather horrifying. 🤢
  • John HudsonJohn Hudson Posts: 2,863
    All valid points, Thomas. My point was that automation of optical size selection—which, it should also be noted, is something that a lot of software is managing to get wrong—is restoring typographic functionality, not extending it. It isn’t a lot to show for the potential of variable fonts, and I for one am concerned about people—including me—developing parametric models for manipulating variable fonts independent of models to perform that manipulation in software. It would be easy to come up with something that doesn’t actually work, or that obliges software to handle such manipulation in some particular way that precludes other options.
  • Dave CrosslandDave Crossland Posts: 1,347
    edited June 7
    Separation of concerns is common, though, and I work in a font team, not a typography team. 

    This is all I'm aware of that's been written into public standards or otherwise publicly documented beyond a demo. For demos, is full of 'em, and @Lasse Fister presented more extensive demos with me and David Berlow at an atypi a couple years ago.

    One of the issues we ran into is the problem of obtaining accurate size information within CSS....

    ...which led lasse to pronounce even this single Finesse example to be, in fact, "broken."

    Each of the 5 axes registered in the MS OT spec is also "broken" and unfit for proper Finesse automation in my humble opinion, but that ship has long sailed. Oh well 🤣
Sign In or Register to comment.