How does Illustrator calculate text frame height

Adobe Illustrator obviously ignores any metrics values stored in the font to calculate the height of a text frame (point type). It rather uses the bounding box.

But that is not the full story. Illustrator seems to use a subset of glyphs for the bbox‽
There are glyphs that change the frame height.

What is going on under the hood of Illustrator?
How can I prepare my fonts that the frame always shows the same height?

«1

Comments

  • Nick Shinn
    Nick Shinn Posts: 2,207
    edited June 2015
    I use the top of Å as the vertical limit, and standardize throughout the family.
    With this method, it’s good to consider the boldest weight first.
  • attar
    attar Posts: 209
    Is it me or this triple integral does not look like it belongs to the font? (I don’t know if Illustrator does font fallback, I know InDesign doesn’t…)
  • Nick,
    what do you mean with “use as the vertical limit”? Do you limit your bounding box, thus your design, for every parenthesis, integral or even swash letter? Do you always increase the lighter Å to the bold height?

    Adrien,
    you’re right somehow. I changed the integrals due to a special customer request. But the shown example is made with a single font.

    Frode,
    with the Illustrator text tool you can just klick and type, whereby the frame is generated depending on the text.


  • PabloImpallari
    PabloImpallari Posts: 806
    edited June 2015
    Forget about the ascender/descender. That's for the type designers eyes only. Snake oil.
    Software care about the Bbox, as defined in your TypoAscender/Descender, WinAscent/Descent, hhea Ascender/Descender and LineGap values.

    In FontLab you can configure those values under: Font Info -> Metrics and Dimentions -> TrueType-Specific metrics. Sadly many people don't know or don't care about it, and just leave the automatically calculated values.

    In Glyphs app, you can configure it using custom parameters.
  • Paul van der Laan
    Paul van der Laan Posts: 242
    edited June 2015
    I agree Pablo that many software looks at the values in the OS/2 table for determining the vertical dimensions.

    The uncomfortable truth however is that there is lots of ambiguity about how to define the vertical dimensions in the OS/2 table, and also how certain software interprets these values again. See for instance this explanation at the Glyphs website that lists different strategies. And then I am not even talking about different strategies for webfonts such as these advised by the Google Font Directory.

    No snake oil here, but a muddy minefield instead. ;)
  • Pablo, Paul,
    these are the known (and confusing) values that Illustrator obviously ignores.
    Or am I wrong?
  • Have you checked whether Illustator might be using some of the OS/2 values? The only way to find out is by testing.
  • PabloImpallari
    PabloImpallari Posts: 806
    edited June 2015
    Paul, yes, agree. Exactly what you said: a muddy minefield.

    This is what I do:
    1) Make sure that the BBox is not greater than 125% of the UPM:
    For example, if the UPM is 1000 units, the sum of TypoAscender + TypoDescender should not exceed 1250.

    2) Unify values (To reduce ambiguity in the how the software handle those values):
    TypoAscender = WinAscent = hhea Ascender
    TypoDescender = WinDescent = hhea Descender
    LineGaps = 0 (both)

    Sample attached


    You can choose whatever values make sense for your font. Just make sure they are not bigger than 125% UPM, and keep them consistent in all the 3 places.
  • PabloImpallari
    PabloImpallari Posts: 806
    edited June 2015
    Another sample of custom parameters (in the Masters tab) for Glyphs app.
    It's from another font (Different values, but same strategy).

  • PabloImpallari
    PabloImpallari Posts: 806
    edited June 2015
    It's also a good practice to place guidelines for your TypoAscender and TypoDescender values when designing, and make sure that no glyphs exceed those values (otherwise they will be cropped).
  • attar
    attar Posts: 209
    edited June 2015
    Personally I just refer to the KLTF Font Metrics document: http://kltf.de/downloads/FontMetrics-kltf.pdf
    It presents a clear methodology and works well in end-user applications in my experience.
  • PabloImpallari
    PabloImpallari Posts: 806
    edited June 2015
    I think KLTF Font Metrics document was great in the old days when you only have to care about Win and Mac... but now a days you have a much bigger ecosystem of OS, browsers, phones, clocks, dog collars and whatever else comes next with the internet of things.... and you never know which metrics group each system is going to choose, it's simple impossible to know with so many of then... so, I think it's better to have all 3 groups using the same values.
  • Dave Crossland
    Dave Crossland Posts: 1,429
    I wonder what the other big web don't services recommend
  • Nick Shinn
    Nick Shinn Posts: 2,207
    Friedrich: I make the the top of the Ring.case glyph the most extreme BCP in each and every font in a typeface family, with the same value in each font. I make this the WinAscent and hhea.Ascender value.

    Similarly, I make the bottom of the Commaaccent as the WinDescent And hhea.Descender value.

    This ensures* consistency of the Bounding Box, irrespective of issues concerning TypoLineGap.

    I make the total of Typo values = 1000, with TypoLineGap then being the difference between 1000 and WinAscent+WinDescent. Giving TypoLineGap a value other than zero apparently causes some minor inconsistencies between certain browsers and devices, as Pablo notes.

    *Unless big swashes and flourishes are in the font.


  • Khaled Hosny
    Khaled Hosny Posts: 289
    so, I think it's better to have all 3 groups using the same values.

    Which works only for simple Latin fonts.

  • PabloImpallari
    PabloImpallari Posts: 806
    edited June 2015
    Which works only for simple Latin fonts.
    It also works for Devanagari, which is quite complex.
    I can't say about other scripts such as Arabic, etc... since I have no experience in those.
  • Friedrich Althausen
    edited June 2015
    I tried several combinations of these values and found out that Illustrator (CS3 on OSX 10.10) ignores them all, but rather does the following:

    ✒︎ The point where I clicked with the text tool becomes the baseline.
    ✒︎ From there Illustrator places the top of the text frame at around 83,5 % of the point size.
    That seems to be independent from any font values. Attention: when a higher glyph occurs while typing, Illustrator adjusts the text frame height (see screenshots in the initial post).
    ✒︎ The bottom of the text frame is calculated as the lowest glyph part in the font. That may correspond with the yMin value in the head table. But obviously Illustrator ignores that and measures by itself.

    Is there somebody who can confirm, complement or correct that?

  • When you click, and the cursor appears, what is the line spacing set to?
  • Standard is 120 %. I couldn’t find a way to influence it through any font metrics values.
  • Jan Schmoeger
    Jan Schmoeger Posts: 280
    edited June 2015
    In layout and illustration programs the slug was always set by the leading, whether baseline to baseline, or block. It is (and should be) controlled by the layout's designer/typographer, not by the type-designer, in my experience.
  • But it seems to be influenced by the app and font data, with now way to influence/know what it chooses.
  • It is (should be) completely transparent, it should snap to top/bottom/baseline. It accepts positive or negative leading. Its output is mainly print or online graphic. Why should a type designer worry about it?
  • You should worry if a client ask you why his text frames are all of different height. That might be important if you try to align them. So if it changes the bounding box because you typed a tall glyph, then you top align it with another text object, the baseline will shift.
  • Jan Schmoeger
    Jan Schmoeger Posts: 280
    edited June 2015
    Well, I must be old-fashioned, my preference would be snapping baselines, rather than top-aligning text boxes. But you are correct, if clients are unhappy, worry about it. PageMaker, Quark, InDesign, Freehand and Illustrator all behaved similarly, the only tool I recall using the built-in values, was MS Word (and that would clip your ascenders and descenders on screen).
  • Mark Simonson
    Mark Simonson Posts: 1,734
    edited June 2015
    There seems to be some confusion in this discussion. The OP was asking about point type. That is, text that you get when you click at a point with the text tool. The bounding box that he is talking about is not the same as a text box (or area type I think it's called), like you get when you drag out a box with the text tool.

    The box around the text that you get with point type is only there to allow you to scale, skew, or rotate the text. You can't use it to align to other objects. It only appears when you select the text with the selection tool. The only part of point type that can be used for alignment is the origin point, that is, the point where you originally clicked. It's at the left end, middle, or right end of the baseline of the first line of text, depending on whether the text is left, center, or right aligned. The size of the bounding box is unrelated to any metrics in the font. It only needs to be a convenient size to manipulate and large enough not to obscure the text. Things like baseline shift or larger characters will cause it to grow larger.

    When you create area type by dragging out a box with the text tool, the distance from the distance from the baseline to the top of the box is always equal to the ascender height of the font, or the tallest ascender if there are multiple fonts or type sizes on the line. This distance stays the same regardless of leading or baseline shift. A text box like this can only be aligned using the edges or corners of the box.
  • Thank you Mark!
    But in one point you are wrong: This point type box is not only for scale-skew-rotate, but also for alignment. Which may result in difficulties. (I tested CS3 and CS5, does CC behave different?)
    As you mentioned: when a higher glyphs comes up, the top border of the box shifts.
    Top align then results in useless mess.

    And that’s the reason why I was asking. My client has many point text boxes in many charts and wants to substitute old fonts with my new one. Some boxes are aligned at the top, some are at the bottom, some are not aligned.

    It seems to turn out that I have to limit the overall BBox, thus omit some tall glyphs …
  • Mark Simonson
    Mark Simonson Posts: 1,734
    That's very weird. Point type, in my experience, is always oriented to the baseline of the first line, regardless of the size of the glyphs. I've never seen it shift like that (oriented from the top of the tallest glyph), and I've been using Illustrator since version 1.0. Maybe you or they are doing something I never do.
  • Mark Simonson
    Mark Simonson Posts: 1,734
    Are you perhaps using the alignment palette?
  • Mark Simonson
    Mark Simonson Posts: 1,734
    edited June 2015
    Okay, so I think I see what's going on. You're trying to use the alignment buttons to align several instances of point type. When you do that, the align buttons do the alignment visually, instead of by the baseline. Not very useful, but I guess that is how it works for whatever reason. There doesn't appear to be any way to modify this behavior, either in the app itself or in the font.

    There is a way: If you want to use the alignment buttons with type, use area type instead. Alignment will be based on the text box you create. As long as all the instances of area type have the same type size and font, they will align perfectly, including along the baseline.

    Alternatively, if you want to keep using point type, use the direct selection tool to select the handle on the baseline of the text and align using smart guides. It's not as efficient, but it works.
  • Mark, thank you very much for your effort! You are right, they used the alignment palette.
    As I am the type designer and not the Illustrator user I come to the conclusion that I have to limit the bounding box for design. In short: I will offer a subset font with fewer glyphs.