Apparently, Scrivener is masking the text area when it creates the PDF. The top of the "f" extends outside the character bounding box (many do) and consequently gets cut off by the mask when it's at the edge of the text area.

I can't think of a workaround (other than using a different font). I would say this may a problem with Scrivener and you should contact the developer. It's also possible that it's something inherent in the PDF writer in OS X. If it does the same thing in either Text Edit or Pages, that might be the case.

Ok, thanks for your help. Much appreciated.

FWIW, I recently opened this font in FontLab to see if I could learn something about its OT features, and noticed that most of the characters do not conform to PostScript specifications; i.e., they lack nodes at many of the extrema...

FWIW, I recently opened this font in FontLab to see if I could learn something about its OT features, and noticed that most of the characters do not conform to PostScript specifications; i.e., they lack nodes at many of the extrema...

This is not true as far as I know. Can you cite specific glyphs? Which font did you look at?

This is not true as far as I know. Can you cite specific glyphs? Which font did you look at?

Try A B C E and F to start with...

Everything looks fine to me, e.g.

Keep in mind that in a design like this, there will always be outlines that do not adapt well to picture-perfect PostScript construction, but I would not say Garamond Premier Pro fits the description that "most" glyphs lack nodes at extrema.

The two FontAudit arrows on the right-hand side of the image indicate incorrect (not "unnecessary," as FontLab describes them) extrema. The handles are simply not orthagonal. The image below shows the original on the left, and a properly-constructed extremum on the right; there is absolutely no perceptible difference between the two.

Extrema points are needed to properly interact with hinting. Unless there are hints aligned with the points which you indicate (which I doubt), there isn't a problem with this. FontAudit indicates potential problems. Not everything which it flags actually requires correction.

André

Old Nick, as I remember, the Adobe paper on PS fonts specifically says that in cases like those you highlight, in tight curves in terminals, you don't have to have nodes at extrema. Presumably this is not a problem for hinting. This example of the terminals, then, is following the rules.

Perhaps because I have spent the better part of the last three months updating my entire product line, I have become a little obsessive-compulsive about extrema. Nonetheless, I find it odd that, if you can achieve precisely the same results by following the conventions strictly, one would choose not to.

My experience is that they are not precisely the same, and that you can see 'lumps' at large sizes in this kind of situation, if you use only nodes at extrema. And, as I said, it's following a myth, not the "conventions", if by that you mean the guidelines that Adobe issued.

I find it odd that, if you can achieve precisely the same results by following the conventions strictly, one would choose not to.

It's not odd when you consider the extent of work required to address it, and the resulting benefit.

As someone who participated in the production work on Garamond Premier, I can tell you that it was a massive undertaking -- a large glyph complement in eight separate multiple master fonts. It is easy to ask that outlines simply be designed "right" in the first place, to avoid time-consuming outline futzing later, but it's simply not compelling when the resulting problems are negligible (or non-existent). Believe me, various people in the Type group here have probably been conscious of it since Day 1 of PostScript. Over the years, we have come to realize that it's just not a significant problem and "choose our battles" accordingly.

When a designer (Robert Slimbach, in this case) is confronting such a massive undertaking, one finds that it's better to simply allow the outlines to be produced in whatever way comes naturally to the designer, rather than fixate on details that are of little consequence. Of course, Robert understands as well as anyone the importance of points at extrema where it will have an impact on rasterization, and is, IMO, very good at putting points in the right places. If I was receiving outlines that were truly horrible, of course it would be worthwhile to offer the designer some guidance.

I don't mean to sound pompous about it... just conveying a bit of font realpolitik from my perspective.

Most of what is being talked about is the curve positioning at cups of serifs or other tight turns. These kinds of things don't impact hinting and make the curve easier to draw with fewer points. You can extend the handle as a smooth point out from that curve section and still have enough tension to smooth that curve without having to add another point in such close proximity. Smooth Points in close proximity have limits on handle placement within the UPM grid thereby kinking the curve to force the handle to end at a UPM raster intersection.

Believe me, it is the best way out of a sticky wicket. Slimbach has his sh*t together when it comes to this.

ChrisL

My experience is that they are not precisely the same, and that you can see 'lumps' at large sizes in this kind of situation, if you use only nodes at extrema.

Perhaps; it's my experience that curves are immensely easier to edit with proper extrema. And, again FWIW, here's the sum total of the difference (using Photoshop's Difference blending) between the two versions I showed earlier at approximately 1200 points. I only tried to match the upper part of the curve; I am reasonably confident that I could have matched the lower part, had I addressed it.