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 ------ _______________________________________________ You are currently subscribed to Framers as arch...@mail-archive.com. Send list messages to fram...@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.