I believe the culprit has to do with a discrepancy in one of the various ascender metrics in the font header, but someone with more tech savvy would have to identify the specifics for you. And if Linotype says there's nothing wrong internally, then perhaps its something else Indd-specific.

To avoid just this sort of thing, I am in the habit of defining my Basic Text Frame object style for book documents so that Text Frame Baseline Options > First Baseline is Fixed, with a value that is usually the same as my basic baseline measure or leading. That way, regardless of whether the first line in a frame is a heading or some other variation from text, the baseline will start in a consistent position and not vary depending upon the type size or ascender dimensions.

At this point in your project, I'm not sure if redefining the Basic Text Frame would reliably propagate in your document and fix your problem without introducing other anomalies. If you're working with a fixed Master text block that isn't overridden on pages, then you might be able to manage the issue globally from there. You may need to use a little trial-and-error to figure out what First Baseline setting will match your existing baseline alignment without needing to adjust the position of all your text frames.

Hope this makes sense and suggests some possible workarounds for you.

-- Kent.

Hmmm. Thanks, Kent. I'll give this a try.

—Michael

To avoid just this sort of thing, I am in the habit of defining my Basic Text Frame object style for book documents so that Text Frame Baseline Options > First Baseline is Fixed, with a value that is usually the same as my basic baseline measure or leading.

Us too -- except we use 7.5 points -- about the base to ascender measurement of most fonts at text size (9-10-11 point settings). If you think that's anal, I had to argue for it, as another comp felt that 7.45 points was more accurate . . .

Also, if you do this, then when you want to sink the first line, as with a subhead starting a page, it is relatively easy to do this, keep your nominal space below the subhead, thus getting the text back on the grid.

that kicks the first line down one line space, but everything aligns to the grid. What’s the problem here?

It could be the setting for the baseline grid start being too close to the top of the text area. A small adjustment there to allow the (presumably higher) ascenders of the italic to fit should do.

This applies whichever way you define the grid, as for exmple here:

So, moving the grid start to 20.2 mm should do the trick.

I don't have SabonNext to test (since that family is not licensed to Adobe), but I suspect Kent is right about the vertical metrics discrepancy between the upright font()s and their italic counterpart(s).

Michael, does this issue only happen in InDesign CS2, or do you see it in Quark XPress as well?

Good question. This does NOT happen in Quark XPress 7.2. The baseline is consistent whether the first line is roman or italic. HOWEVER, if I set a few characters in small caps, the baseline is thrown off. I checked to see what would happen with small caps in InDesign, and the type did drop down ever so slightly—but by a trace amount.

Sorry, I did not realise that you do not want to use the baseline grid. If you do not use the grid in any form, the ascender of the first line aligns to the top of the text area/text box by default. So the baseline will be in a different spot in different typesizes, or italic or small caps. It's nothing wrong with the typeface.

The jumping of one line down you described happens when baseline grid is in use and the space above the first baseline grid line is not large enough for the ascenders.

¶ -- I don't think it's necessarily the ascender itself. Different apps use different metrics from the font header info to determine where the "top" of the font is. It may or may not be the actual height of a typical ascender in the design of the typeface, depending upon the value(s) of the various font header fields.

Miguel, can you tell us which field InDesign uses to determine this?

Another workaround trick for Michael's problem might be to search-and-convert all Italic spaces to Roman spaces. For lines of Italic that occur as the first line in the text block, the Roman spaceband will force the Roman metrics and shift the line down to the equivalent alignment of others. It's not necessarily elegant, but it is a global fix. Presumably, the spaceband width is the same or very similar between Italic and Roman, and with justified setting any slight difference shouldn't matter much. (And hopefully there are no Italic kern pairs involving the space.)

This assumes, of course, that the Italic lines are riding high. If not, then this trick won't work, since that would mean the Italic ascender metric is the larger value.

Maybe I've missed something, or don't understand the question, but I didn't see where Michael didn't want to use a grid at all, he just didn't want to snap to it. In that case, What Kent & I mentioned should work. Here is the InDesign setting:

Using that, I can have a big stick-up letter on the first line (no, didn't take the time to kern it):

BTW, We are NOT snapping to the grid, but we do set the grid up to the nominal text leading. If there had been an extract with half a line above & below in the example, that space would be honored.

> Miguel, can you tell us which field InDesign uses to determine this?

I don't know exactly what InDesign does or uses. It's probably some elaborate algorithm filled with fallbacks that may have evolved over time. One thing I can say for sure is that in the font families we build we always try to set the TypoAscender, TypoDescender and TypoLineGap the same for the romans and italics.

This is all wildly helpful, and I'm learning a great deal. I'm presently leaning towards the technique Charles has described.

What I don't understand, though, is why italic and roman and small caps from the same family (or different characters therein) would have different body heights and thus open themselves to this problem.

Michael -- They shouldn't. But there may be errors or discrepancies in certain values that are part of the header. These are not necessarily derived from the font outlines directly. They are sometimes set manually and can therefore be subject to human error. They should be the same, as Miguel expressed, but sometimes they might not be. No real reason that I can think of.

Miguel -- I'll shoot off an e-mail to Eric. He should know which values are used.

I just realized that the thread is about a Type 1 (a.k.a. PostScript) version of SabonNext. Type 1 fonts do not have a OS/2 table, so I'm not sure where the equivalent values for TypoAscender/Descender/LineGap would be stored. Perhaps in the metrics file (.pfm)?

The 7.5 pt offset that Charles gives is completely reasonable for the work he does.

The reason I usually prefer the underlying baseline leading value is that a lot of my work has been multi-column or profusely illustrated, with multiple and variable text frames. By using the leading value I can easily achieve precision by simply snapping the head of a text frame to the baseline grid, knowing that the first line will then be aligned, regardless of the text matter -- caption, sidebar, pull quote, whatever -- or where on the page it occurs.

It's just a slight difference in working styles. But the concept is the same -- establish a controlled starting point, so that precision and consistency can be achieved easily and reliably.

-- K.

If a long text contains headings, the technique recommended above is not ideal, it leads to this look:

Sorry, there is no way to expain this in a short post. A better solution is to use the baseline grid and snap to it, build the snap definitions into the styles. However, that requires that the whole design is modular. If, say, your body copy is 10/12, your grid could be 6 pt (half-a-line). You could then design the lager headings roughly at 6 pt leading jumps, say 16/18, 22/24, 28/30, you get the drift. You would limit your paragraph spaces above and below to increments of 6 pt: 6, 12, 18, etc.

It is precisely to avoid the happening shown in the picture, that the default behaviour of InDesign text boxes is (roughly) to align ascender to the top edge of the text area. The headings (no matter how large) will not jump over the top of the text area, or even better over the top of the page :)

Also, controlling the behaviour of a 900-page book with the text box properties is very limiting, it is much better to use individual settings for individual styles (snap some, leave others floating, snap only first lines, etc.). Another advantage of this approach is that lines align across spreads or at the bottom of columns or pages as well (within the 1/2 line jumps, which are easily adjusted).

Hope this helps.

Jan,

It works fine, if you are doing a long book. For those pages you have a subhead beginning the page, you sink the the starting position. I'm home now & can't bring up a picture, but if anybody really wants to see it, I (or I suspect Kent), can show it

Of course, in any reasonable scholarly book, you'd never have any such honking big subheads, but you do have the situation I mentioned above, a subhead beginning a page, with +1/2 line specified to the text. Unless told otherwise, we'll sink such a subhead, so the text itself begins on line (that would be line 3) -- but no snapping!

To further flesh out what Kent was saying about the offset value: If you use the ascender height, then any images to be placed at the top of the page will snap to the frame & be in position. Exceptions are designers who want the images to top align with x-height of the first line. Then you can make a different decision, either use the x-height value so images can snap to the text frame, or mess with each image. But these days, most of the work we do specifies images to top align with the ascender position.

BTW, I use the same number, usually 7.5 points -- with table settings (ID2). We usually set the tables separately & put them in a library. We show them all in galley form at sample pages. Even when I'm designing a book, I set all the tables before finalizing the design. Using the 7.5 (or whatever) number, you do need extra spacing between the rows of course, but most of the body rows will use the same value, so you can highlight all of them & specify the extra space at one time. This small value also lets you get tighter table rules if you want them fairly tight. ID (at least CS2) won't take a negative value. Another plus is that when placed, the tables will snap into place on the text frame.

When you're doing a 600 page book with 100 images and 50 tables, little tricks like this help you stay somewhat sane. Of course, in such a book, you are not likely to have many subheads starting a page; I suppose if that were the norm, I might consider a different technique.

Charles, the example is made up on the spot and exaggerated for clarity. As long as Michael gets some useful advice for his problem out of this, I am happy. The debate about the font construction details and OS/2 tables is not going to help him much in his predicament. As for what InDesign uses by default for its text boxes, I still say it's ascender without writing to Linotype or Adobe:

Jan --

Notice it says "Ascent." This is not the same as the ascender and will give different results in different typefaces. Witness the following examples of 14 pt. Whitman, Plantin, and PMN Caecilia and notice the positions of the ascenders relative to the top of the text frame:

 
I have a meeting to attend this morning, so no time to respond in detail to the issue you raise about heads at the top of the page.

Nothing wrong with the different approaches. Each has its upsides and downsides. I have techniques for dealing with heads, similar to Charles's. It's all part of the planning and the specs.

Any working method is a host of techniques that all work in concert.

-- Kent.

Wow, it looks like you are right again, Kent. Off to some experimentation.

As to the host of techniques that all work in concert, how helpful is incomplete, expert level instruction to a person asking for help in one of these forums? Can we somehow give Michael some coherent advice to save his 900-page book?

I am still convinced that the snap to grid and lowering the grid start to accomodate the first line in italic or small caps is the best (global) way to do it. No need to change the 900 odd text boxes through object styles or manually and THEN dropping every awkward instance by hand.

how helpful is incomplete, expert level instruction to a person asking for help in one of these forums?

The same could be said for type design, esp. writing OpenType features. At some point, you have to learn the program, the tool. My grumble about using "snap to grid" is I feel I give up control, but I suppose all that means is the program may do something I don't expect. Depends both on what you are use to looking for that needs fixing, and how hard that fix is.

Anyway, if you want to sink something on a page set up as Kent & I described, activate the particular frame, hit Control+B, and enter the value in "Inset spacing"

how helpful is incomplete, expert level instruction to a person asking for help in one of these forums?

I would say there is an art to giving a person enough so that they can teach themselves through experimentation. Specific prescribed solutions are too often used and forgotten, IMO.

Jan -- I don't disagree with your point, which is why I usually use plenty of qualifiers in my advice and specifically said above, ". . . suggests some possible workarounds for you."

I would need more complete details about Michael's specific problems and how he has engineered his document to recommend specific fixes. I was merely pointing out an avenue that might prove worth exploring, and perhaps also making others in general aware of a technique that has certain merits and is worth considering in setting up future projects.

My technique for subheads is different than what Charles's describes above and I will try to illustrate it soon.

It is also not fool-proof.

-- Kent.

how helpful is incomplete, expert level instruction to a person asking for help in one of these forums?

So far, it's been pretty helpful. I've got two new approaches to use for a host of circumstances. I'll probably use the text frame options for the 900-page book, and I'll be using the snap-to-grid for a bookseller's catalogue I'll be starting in a few minutes. I'm glad to have two more tools for different problems.

Thanks!

Charles, upon reflection, your and Kent's approach is best on a professional level, precisely because it is open-ended: you can change any aspect of any style at will without suffering any untoward effects. Change point size and leading to change the extent of a book when a publisher keeps changing their mind, huh?

Jupiterboy, you are quite right. Encouraging people to learn is the best way. Balancing the detail with concrete advice is hard, experts tend to hold expert opinions and everyone needs to start somewhere.

Michael, I am glad that you found the stuff helpful. The booksellers catalogue is a perfect candidate for the grid use, especially if it has a lot of pics. I am such a fan of the baseline grid because my jobs were suited to it. Textbooks in two columns with tons of pics and diagrams? The last medical atlas I did was 900 pages with more than 2200 pictures and the spreads needed some sort of alignment everywhere. It just could not be done without the grid. And Charles, it was reasonably scholarly (sorry, could not resist ;-).

Jan -- Don't get me wrong (or Charles, I suspect): I am a big proponent of organizing using a baseline grid. I am just not generally in favor of relying on snap-to or align-to-grid commands, because I am distrustful of how space then gets handled for floating elements and other exceptions. Past experience is that lines will get pushed down or pulled up unexpectedly, and I'm too much of a control freak to risk that.

I certainly don't begrudge those who choose to work with snap-to. And I will say that the "align first line only" feature is new to me, since I developed my working methods many many years ago, before InDesign, and never noticed this feature before. And to be able to apply that within a paragraph style . . . I can see how that might be useful.

No longer resolving Michael's initial plea, but because I said I would come back and explain:

I did not have a suitable real-world project close to hand, so this somewhat quick-and-dirty example must suffice. This is not presented as a paradigm of excellent design specs, but only to demonstrate an "engineering" technique.

Here is an example of a heading with space above and below, both inline and occurring at the top of the column. When the head comes at the top, the decision here is to sink the head, in order to preserve the text alignment on the third baseline while preserving the amount of space after.

 
Here is the same screenshot with margins, baseline grid, and text frames visible.

 
The basal text here is 11/13 pt. The baseline grid, therefore is 13 pt. Text frames are defined (via Basic Text Frame object style) to have First Baseline fixed at 13 pts. The heading is 15/13 pts with 17 pts space above and 9 pts space below: 17 + 9 = 26 = 2 x 13, thus preserving the grid spacing.

However, here's the "trick": rather than specify the heading style with 17 pts before and 9 pts after, I specify the style with 13 pts before and 13 pts after, then baseline shift the text down 4 pts.

Why? Despite the seeming inelegance of this approach, what this allows is that when a head occurs at the top of the column, the baseline is perceived by the application to fall directly on the grid. The baseline shift achieves the necessary sinkage. That way, I don't have to manually override the text frame inset, as in Charles's approach.

The work I have done has usually been in a much greater state of editorial flux than I suspect Charles's manuscripts are. So, I developed a technique where I don't have to do manual fiddling for heads at the top of columns (or worse, undoing the manual work when the copy reflows due to editorial adjustments).

-- K.

I am distrustful of how space then gets handled for floating elements and other exceptions

Most apps start to round off at a few decimal points, which ultimately catches up to the point system and causes jumps. Maybe we will have CAD precision some day.

A second example, further illustrating a point I made earlier. At the risk of basically repeating myself. FWIW.

The majority of books that I have done (usually classified as trade illustrated reference) involve multiple planes of text, illustrations, photos, etc. Page layouts often vary spread by spread. So the basic text frame is not necessarily a relatively fixed entity always starting at the top and ending at the bottom of the live area. For that reason, I find it advantageous to work with the fixed baseline value equal to the baseline grid (leading) value.

In the following excerpt I have a two-column layout with a photo and caption at the head of the second column.

 
With margins, baseline grid, and text frames visible:

 
With the default text frame defined with First Baseline fixed at the full value of the baseline grid, it's a simple matter to adjust the second column to accommodate the photo & caption by pulling the top handle down to snap to the grid. An ad hoc text frame created to hold the caption text also snaps at the top to the baseline grid, and thus the caption starts neatly on the grid (although the caption leading is not the same as the text).

No big deal. Just nice and neat. But also flexible.

One would be correct in noting that this is not anything that couldn't also be achieved with judicious application of align-to-grid and align-first-line-only properties in paragraph styles rather than text frame properties. Different strokes for different folks, as we used to say.

Okay, enough pontificating from me.

The work I have done has usually been in a much greater state of editorial flux than I suspect Charles’s manuscripts are.

I imagine that is true, though not because the editors or authors are so careful. Almost all the books we set have an index, and that index is usually prepared from first proof. The publisher -- well, editors -- take pains to keep pages the same in revises, because significant changes can affect that index. And while alterations affecting an index isn't our specific problem (it is an editorial problem), viewed another way, the whole book is our concern, so we too take pains. If an alteration causes copy to change pages, we try to get back to the original pagination as soon as possible. You can make or loose lines fairly easily, etc.

We probably don't do as many two-column books as Kent, but we do enough to pay attention to issues affecting them. We probably get more of a mix than most people on Typophile, all the way from straight, simple text through illustrated books, to single or dual column column text with two footnote streams, one dual column, one single column.

Or worse; I have one with a pub date of July entitled Ballads of the Lords of New Spain, a transcription of a codex, much of the book Nahuatl on the verso, English on the recto; footnotes to the English but not the Nahuatl; and no getting ahead with either language. With a few more complications . . .

No technique is perfect for all kinds of work. In our shop, we also have multiple people working on most jobs, so we probably treasure a consistent approach more than most people.

But with all that said, it is enlightening to see other people's techniques, often there is be something we can use.

I really like the split of these two approaches to the same problem. I think that jobs that require lots of minute differences, such as different leadings (11/13 and 8/9 or 9/11), or paragraph spaces (of say 3 or 4 points) the first-line snap of the default text box is the way to go. Also for feathering spaces above/below heads to align at the bottom (for this I usually have to un-snap the whole page or parts of it).

Past experience is that lines will get pushed down or pulled up unexpectedly

It is easier to understand the grid operation in these simple terms: within the grid (ignoring the page margins or text box edges), the only jumps are down, no dimension or space is compressed or lost. The element that does not fit into the grid is pushed down onto the first grid line that can accomodate it. By moving the whole grid up and down on the page (as shown above in the Preferences) the first line fit can be easily and globally controlled (this is the equivalent of snapping the first baseline inside the frame which, b.t.w., bypasses the grid altogether). Finally, it's really advisable to set the grid at a half or a third of body text leading, not on a whole line— to obtain fine-enough control.

The following bit is really optional and only a suggestion for the brave: It is possible to use the grid as the main type control. The style definitions can be made truly minimalistic and simplistic: only minimum acceptable leading (say 10/11), only minimum acceptable paragraph spaces (say 3 mm above, 1 mm below for a heading). Then, by varying the grid the whole job can be changed from 10/11 to 10/12.5, 10/13, 10/13.8 to achieve a desired look or extent without touching any style definitions again. Assuming that other long-document controls are in place, such as properly defined ‘keeps’, a job can be re-flown repeatedly and easily (just do not tell the editors and publishers :)

Finally, adjustments to the layout are then best done (no doubt strangely to people with good manners) by using manual overrides, simple click on the up arrow will jump the space by the half or third line defined in the grid.

If a change is required, select all and click the ‘Clear overrides’ button, and assuming you have been a good person, the only overrides will be these ones, and the job is pristine again.

Venturing far afield from the original question, I'd note we make extensive use of paragraph styles. The reason is we consider the *file* to be the end product of composition, not a printed book. Paragraph styles can be used for XML tags, or at least a start (since the structure of InDesign coding is essentially flat, not a tree).

For example, text in a numbered chapter is styled "chapter", text in the introduction is styled "introduction", even though both are the same -- say 10.2/13.5. Moreover, both are based on "basic text", so if a change is needed, it is made only in "basic text" paragraph style.

By extension, extracts are "chapter.extract" and "introduction.extract". If spacing above & below is different, we use "chapter.extract(1,0)" "chapter.extract(0,1)", and "chapter.extract(1,1)", all based on "chapter.extract". You guessed it, stuff in parentheses is ignored for processing the text outside the typeset book.

We try to keep direct formatting to a minimum. That minimizes work needed later for a useful *file.* Where direct formatting won't affect the usefulness of the file (as in sinking a subhead), fine, we direct format.

At first, it is a little daunting to be confronted with 30+ paragraph styles to fill in, but really there are only a few basic styles the rest are based on. Like most things, you get use to it.

I'm not advocating any of this for composition, simply pointing out that using InDesign styles can be helpful with certain kinds of workflows, depending on what you view the end product to be.

Jan --

I do understand the principles underlying working with automatic align-to-grid.

My comment about "lines pushed or pulled" was hasty and imprecise. You're right: technically, they only really get pushed. When the spacing of a floating item does not end up preserving grid spacing, only designated space before is honored, and extra space gets added after, so that a following snapped element will get pushed down to the next alignment. (And this is exactly the kind of automatic space manipulation that I find annoying -- but, hey, the app is just doing its job.)

On some thread in the past, we had a long discussion about the pros & cons of relying on snap to grid. Perhaps you were even part of that conversation. I'm not interested in repeating the points I made there. As I said, I don't begrudge those who choose to work this way. I do recognize the potential power of doing so, and you've been an articulate advocate for the advantages of this approach.

For those who are interested: Here’s a link to the thread that Kent referred to.