Re: Typing conditional text
This looks like part of a bigger problem with character ranges. It's understandable that you would get this behavior where arrowing from one direction makes the transition point show one property, and from the other direction the transition point shows another. The fact that the Enter key (new pgf) is inconsistent between versions of Maker highlights problems with pgfs at the end of a char range. 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. 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. For FDK developers, this is compounded by inconsistent results when you use the End-Of-Pgf token for text loc offsets. Sometimes it works, sometimes it acts like some location within the pgf, and sometimes it acts like infinity (sort of). So it's tricky to find these last characters and fix them. 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. cud [SNIP...] Lynne Price Says... By the way, I found a surprise in the 7.x behavior also. Suppose you have unconditional text followed by conditional text in one paragraph. If you click in the unconditional portion and then press the right arrow until the insertion point is between the unconditional and conditional material and then type a character, the character will not be conditional. However, if you click in the conditional portion and then press the left arrow until the insertion point is between the two portions and then type a character, the character will be conditional. The same is true for font properties. As you type new characters, FrameMaker applies the properties of the adjacent characters. If those properties are different to the left and right of where you are typing, FrameMaker remembers how the insertion point was set. If you move the insertion point with the arrow keys, FrameMaker changes the properties assigned to new content when you cross a border between text ranges with different properties but does not change them when you simply reach the border. [SNIP...] ___ 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.
RE: Typing conditional text
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.
Typing conditional text
This looks like part of a bigger problem with character ranges. It's understandable that you would get this behavior where arrowing from one direction makes the transition point show one property, and from the other direction the transition point shows another. The fact that the Enter key (new pgf) is inconsistent between versions of Maker highlights problems with pgfs at the end of a char range. 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. 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. For FDK developers, this is compounded by inconsistent results when you use the End-Of-Pgf token for text loc offsets. Sometimes it works, sometimes it acts like some location within the pgf, and sometimes it acts like infinity (sort of). So it's tricky to find these last characters and fix them. 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. cud [SNIP...] Lynne Price Says... By the way, I found a surprise in the 7.x behavior also. Suppose you have unconditional text followed by conditional text in one paragraph. If you click in the unconditional portion and then press the right arrow until the insertion point is between the unconditional and conditional material and then type a character, the character will not be conditional. However, if you click in the conditional portion and then press the left arrow until the insertion point is between the two portions and then type a character, the character will be conditional. The same is true for font properties. As you type new characters, FrameMaker applies the properties of the adjacent characters. If those properties are different to the left and right of where you are typing, FrameMaker remembers how the insertion point was set. If you move the insertion point with the arrow keys, FrameMaker changes the properties assigned to new content when you cross a border between text ranges with different properties but does not change them when you simply reach the border. [SNIP...]
Typing conditional text
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 --
Re: Typing conditional text
At 02:30 PM 6/25/2009, Fred Ridder wrote: Am I correct that FrameMaker's behavior when you type an Enter in conditionalized text changed before version 8.0? The behavior I'm seeing in FM8.0 seems flat-out wrong to me, and is driving me crazy. Fred, You are correct and I agree that the behavior introduced in 8.0 is counterintuitive. 7.0, 7.1, and 7.2 all behave the same way, as do 8.0 and 9.0. What seems to happen is that in 7.x, when you create a new paragraph by pressing Enter, the end-of-paragraph itself takes on any condition tags applied to the object (character, variable, table anchor, etc.) immediately preceding the insertion point. In 8.0 and 9.0, the new end-of-paragraph is never conditional. It does not matter whether the insertion point is at the end of the paragraph when you press Enter. By the way, I found a surprise in the 7.x behavior also. Suppose you have unconditional text followed by conditional text in one paragraph. If you click in the unconditional portion and then press the right arrow until the insertion point is between the unconditional and conditional material and then type a character, the character will not be conditional. However, if you click in the conditional portion and then press the left arrow until the insertion point is between the two portions and then type a character, the character will be conditional. The same is true for font properties. As you type new characters, FrameMaker applies the properties of the adjacent characters. If those properties are different to the left and right of where you are typing, FrameMaker remembers how the insertion point was set. If you move the insertion point with the arrow keys, FrameMaker changes the properties assigned to new content when you cross a border between text ranges with different properties but does not change them when you simply reach the border. The subtle detail that surprised me in 7.x is that when I pressed Enter with the insertion point on the border between conditional and unconditional text ranges, the new end-of-paragraph was always conditional, even if I set the insertion point such that if I'd typed new characters instead of pressing Enter, the new characters would have been unconditional. --Lynne Lynne A. Price Text Structure Consulting, Inc. Specializing in structured FrameMaker consulting, application development, and training lpr...@txstruct.comhttp://www.txstruct.com voice/fax: (510) 583-1505 cell phone: (510) 421-2284 ___ 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.
Typing conditional text
At 02:30 PM 6/25/2009, Fred Ridder wrote: >Am I correct that FrameMaker's behavior when you type an Enter in >conditionalized text changed before version 8.0? The behavior I'm seeing >in FM8.0 seems flat-out wrong to me, and is driving me crazy. Fred, You are correct and I agree that the behavior introduced in 8.0 is counterintuitive. 7.0, 7.1, and 7.2 all behave the same way, as do 8.0 and 9.0. What seems to happen is that in 7.x, when you create a new paragraph by pressing Enter, the end-of-paragraph itself takes on any condition tags applied to the object (character, variable, table anchor, etc.) immediately preceding the insertion point. In 8.0 and 9.0, the new end-of-paragraph is never conditional. It does not matter whether the insertion point is at the end of the paragraph when you press Enter. By the way, I found a surprise in the 7.x behavior also. Suppose you have unconditional text followed by conditional text in one paragraph. If you click in the unconditional portion and then press the right arrow until the insertion point is between the unconditional and conditional material and then type a character, the character will not be conditional. However, if you click in the conditional portion and then press the left arrow until the insertion point is between the two portions and then type a character, the character will be conditional. The same is true for font properties. As you type new characters, FrameMaker applies the properties of the adjacent characters. If those properties are different to the left and right of where you are typing, FrameMaker remembers how the insertion point was set. If you move the insertion point with the arrow keys, FrameMaker changes the properties assigned to new content when you cross a border between text ranges with different properties but does not change them when you simply reach the border. The subtle detail that surprised me in 7.x is that when I pressed Enter with the insertion point on the border between conditional and unconditional text ranges, the new end-of-paragraph was always conditional, even if I set the insertion point such that if I'd typed new characters instead of pressing Enter, the new characters would have been unconditional. --Lynne Lynne A. Price Text Structure Consulting, Inc. Specializing in structured FrameMaker consulting, application development, and training lprice at txstruct.comhttp://www.txstruct.com voice/fax: (510) 583-1505 cell phone: (510) 421-2284
Typing conditional text
FrameMaker 8.0p277, Windows XP SP3. Am I correct that FrameMaker's behavior when you type an Enter in conditionalized text changed before version 8.0? The behavior I'm seeing in FM8.0 seems flat-out wrong to me, and is driving me crazy. I older versions of FrameMaker (at least through 7.0, which is the other version I have on my system), if you type Enter with the insertion point at the very end of a paragraph that is conditionalized, you get a conditionalized pilcrow in the existing paragraph and the new paragraph is unconditional. This was a little annoying if you wanted the next paragraph to also be conditional, but there was an easy workaround, which was to always keep a space between the insertion point and the end of the paragraph. That way, the new paragraph would be non-empty, and FrameMaker would apply the condition to it. Perfectly logical, and everything just worked. But in FrameMaker 8.0, if you type Enter in a paragraph that is entirely conditionalized, the *new* pilcrow (the one that is inserted at the end of the conditional paragraph you've been typing is always *unconditional* and the *following* pilcrow is always *conditional*. This is just plain wrong, because the unconditional pilcrow on the otherwise conditional paragraph will always produce an extra line space when you hide the condition. And if the following paragraph is actually non-conditional, having a conditional pilcrow at its end will make it collapse into the paragraph that follows it when the condition is hidden. I find myself having to spend a lot of time manually conditionalize and unconditionalizing pilcrows throughout the documents I work on. And it's only made worse by the fact that the developers who write the initial drafts of the docs and apply the conditions usually don't even see the pilcrows because the won't follow my advice to always work with View Text Symbols turned on. Am I the only person who has noticed this? I wasted about a half hour trying to find anything about this misbehavior in the Adobe Knowledgebase. Does anyone have a workaround? Does FrameMaker 9 behave the same way (not that I'd be able to recommend having to spend money to upgrade the dozen or so developers to the new version...)? Fred Ridder ___ 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.
Typing conditional text
FrameMaker 8.0p277, Windows XP SP3. Am I correct that FrameMaker's behavior when you type an Enter in conditionalized text changed before version 8.0? The behavior I'm seeing in FM8.0 seems flat-out wrong to me, and is driving me crazy. I older versions of FrameMaker (at least through 7.0, which is the other version I have on my system), if you type Enter with the insertion point at the very end of a paragraph that is conditionalized, you get a conditionalized pilcrow in the existing paragraph and the new paragraph is unconditional. This was a little annoying if you wanted the next paragraph to also be conditional, but there was an easy workaround, which was to always keep a space between the insertion point and the end of the paragraph. That way, the new paragraph would be non-empty, and FrameMaker would apply the condition to it. Perfectly logical, and everything just worked. But in FrameMaker 8.0, if you type Enter in a paragraph that is entirely conditionalized, the *new* pilcrow (the one that is inserted at the end of the conditional paragraph you've been typing is always *unconditional* and the *following* pilcrow is always *conditional*. This is just plain wrong, because the unconditional pilcrow on the otherwise conditional paragraph will always produce an extra line space when you hide the condition. And if the following paragraph is actually non-conditional, having a conditional pilcrow at its end will make it collapse into the paragraph that follows it when the condition is hidden. I find myself having to spend a lot of time manually conditionalize and unconditionalizing pilcrows throughout the documents I work on. And it's only made worse by the fact that the developers who write the initial drafts of the docs and apply the conditions usually don't even see the pilcrows because the won't follow my advice to always work with View Text Symbols turned on. Am I the only person who has noticed this? I wasted about a half hour trying to find anything about this misbehavior in the Adobe Knowledgebase. Does anyone have a workaround? Does FrameMaker 9 behave the same way (not that I'd be able to recommend having to spend money to upgrade the dozen or so developers to the new version...)? Fred Ridder
