Hi Carol,

With a quick look at your attachments, I'll make a stab at trying to answer some of your questions:

1. In the Poststring of your hlt_hd tag the <mc;x43=%blines;xs(44,%lnwidth);xs(44;%lnwidth+3q)> is effectively setting temp register 44 to %lnwidth+3q if the header is multiple lines (i.e. when temp register 43 is not equal to %blines) giving a 3q of spacing before the "text" begins, but if the header is only one line temp register 44 is only set to %lnwidth and so the "text" begins right at the end of the header (i.e. there's no added 3q as with the multi-line header).

2. This ones the most difficult. My guess is that the "runin" tests (the first <mc>) in the hlt12p0 and hlt20p0 macros are not accounting for enough space for the fist word of the "text" to fit after a one-line header (or even a multi-line header where the last line is near as long as the column).

I don't think composition will force a first word (of a line) that does not fit within the remaining measure to the next line. Why? Imagine the scenario where an indent was set such that the next (or first) word does not fit; if composition did not force the word to set (albeit with a justification error) then you could end up with a runaway situation where composition would keep generating blank lines "forever".

One approach would be to change the "runin" tests to allow for more than just 2p (as in hlt12p0) and 1p (as in hlt20p0) of space, but to make those tests allow for a space large enough for the longest expected first word of "text".

Other customers might have some suggestions for a different approach as to how to handle the "transition" from a header to the following "text" that is able to better deal with this scenario.

3. Yes, you have different point sizes and extra lead and ascender/descender values in the hlt_hd and hltp0 tags which makes it difficult to line up the baselines. The <lp;-10.5q> macro at the beginning of the 12runin and 20runin macros has to negate the last header line's descender + extra lead and the first "text" line's ascender lead. If we assume that the header line's descender is 3q, then I think that would add up to 3q + 1q + 7q = 11q - not the 10.5q value currently being used.

However, that may still not "exactly" line up the baselines because the header line's descender may not be an exact 3q. In the hlt_hd tag the Descender Lead is set to "normal" which means that it is calculated as a percentage of the Height (which is 10q). I think the percentage (of the ascender) comes from the FV spec. I've seen typical percentage values for ascender as 67%, which would mean a descender percentage of 33%, and if so that would mean the descender would be 3.3q and not 3q. Line Status with your cursor inside a header line will give you the DscLd value.

You don't have the same "calculation" problem with a "text" line's ascender value because the hltp0 tag specifies a fixed Ascender Lead value of 7q (versus "normal").

4. I see that the Justify Line(s) value for the hltp0 tag is set to "l" (left justify), but all the hlt12p0/12cancel/12runin/hlt20p0/20cancel/20runin macros all do a <tq;rr> which overrides the tag's Justify Line(s) value for "text" line to makes it ragged right.