Typing conditional text

[Combs, Richard]

Chris Despopoulos wrote:
 
> If you apply bold to a char range that includes the last char in a
pgf,
> then Maker will assume the whole pgf should be bolded.  Using the
Default
> Font setting in the fmt catalog won't change it back to its default
> properties.  I've found that you should always have a space between
the
> last formatted char and the pgf marker, and give it Default
Formatting.

When char formatting (either ad hoc or a char tag) abuts up against the
pilcrow (end-of-pgf symbol), it creates a pgf format override -- in the
status bar, you'll see an asterisk by the pgf tag name. Applying the
Default Paragraph Font char setting won't fix this because it's a pgf
property you need to change, not a char property. 

Reapplying the pgf tag removes the override, but as Chris noted, you
really need a space or something between the end of the char format and
the pilcrow to prevent these pgf overrides. 

> Likewise, if cond text is not for the complete paragraph, it's
possible for
> there to be similar problems at the end-of-pgf, but those problems
really
> only surface at the FDK level -- users should not see those problems.

I haven't seen any end-of-pgf issues with conditional text -- but with
rare exceptions, I conditionalize only complete pgfs. 
> 
> I haven't verified this problem in Maker 9, but I would be surprised
to see
> it fixed there.  I also didn't realize cond text had different
behavior
> between Maker 7 and Maker 8.  I hope to noodle around with that to see
what
> it means for the FDK.  But for users, I strongly suggest you have a
space
> between the last char and the pgf marker whenever you intend to apply
> formatting to the last char.

The same issue exists (and I've posted about this several times)
regarding text insets. FM treats a text inset like a single object (char
or marker) sitting at the cursor position at which it was imported (you
can confirm this by putting the cursor somewhere above the text inset
and then pressing right arrow repeatedly until, with a single key-press,
the cursor moves past the text inset). 

If the cursor is in an empty pgf when you import the text inset, then it
sits adjacent to the pilcrow. This causes a problem almost certainly
related to the char formatting bug: the pgf that contains the text inset
takes on the pgf format of the first pgf in the text inset. That's not a
big deal if they're both Body pgfs, but if the text inset begins with a
Head1, you've suddenly got all this white space. 

Once again, the solution is to have a space or something between the
text inset and the pilcrow. I use a non-breaking space so that the
symbol is visible. 

I never have the char formatting problem because of a habit I developed
when I taught myself to type. I always press the spacebar at the end of
a sentence, even if it's the last sentence in the pgf. I think that with
rare exceptions (file names, code), a period should always be followed
by a space.

I seem to be in a distinct minority in this regard, but to me it makes
eminent sense. It avoids the pgf override problem mentioned above, and
it means I can merge any two pgfs without sentences crashing into each
other. 

Richard


Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
303-223-5111
------
rgcombs AT gmailDOTcom
303-777-0436
------