RE: Maddening problem with frame below
Bummer. So much for that idea. I guess I'll just keep running Paragraph Tools as part of the conversion process. We're moving toward automating the PDF creation process from our FM files, though, and I don't know if we'll be able to get it fully automated if we're having to run a plugin between importing from the settings file to switch conditions and variable definitions, and then generating the PDF. So, it would be better if we could just get the paragraph formats behaving properly despite changing conditions along the way for the various flavors of output. Right now it takes 8-12 hours for a team of 4 to generate our 7 documents, and this Frame Above / Frame Below problem with the paragraph formats is one of the main hindrances to automation. Rene Steve Rickaby [EMAIL PROTECTED] wrote: At 12:16 -0700 11/4/07, Rene Stephenson wrote: I can't trigger it without changing the show/hide conditions. I wonder if it could be something triggered by show/hide conditions causing the para formats to reapply the ref pages or something... Just did a show/hide switch a few times with one of my problem docs, but the problem didn't trigger. -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Maddening problem with frame below
At 05:37 -0700 12/4/07, Rene Stephenson wrote: We're moving toward automating the PDF creation process from our FM files, though, and I don't know if we'll be able to get it fully automated if we're having to run a plugin between importing from the settings file to switch conditions and variable definitions, and then generating the PDF. So, it would be better if we could just get the paragraph formats behaving properly despite changing conditions along the way for the various flavors of output. Right now it takes 8-12 hours for a team of 4 to generate our 7 documents, and this Frame Above / Frame Below problem with the paragraph formats is one of the main hindrances to automation. If I get of whiff of what might trigger it, I'll be sure to post it here. Tell you something that might be vaguely relevant. In another book and template entirely, I've made extensive use of the method of negative vertical spacing to 'slide' graphics behind paras, mainly because of the limitations of the 'frame below' option - mainly, that 'below' means 'below'. I think the original idea came from Hedley Finger, for which, thanks. It might be a solution to your problem, although it carries other issues, such as triggering the screen redraw bug big-time. I have a demo file I can send you offline if you're interested. -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Maddening problem with frame below
At 13:43 +0100 12/4/07, Steve Rickaby wrote: I think the original idea came from Hedley Finger, for which, thanks. Grovel: it was Hayden Jones. Thanks anyway: Hedley's a hero too ;-) -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Maddening problem with frame below
At 12:16 -0700 11/4/07, Rene Stephenson wrote: >I just did a test and found it happening when condition-tagged text is not >adjacent to the BlockLine para tag, too. But, I can't trigger it without >changing the show/hide conditions. I wonder if it could be something triggered >by show/hide conditions causing the para formats to reapply the ref pages or >something... Just did a show/hide switch a few times with one of my problem docs, but the problem didn't trigger. -- Steve
Maddening problem with frame below
Bummer. So much for that idea. I guess I'll just keep running Paragraph Tools as part of the conversion process. We're moving toward automating the PDF creation process from our FM files, though, and I don't know if we'll be able to get it fully automated if we're having to run a plugin between importing from the settings file to switch conditions and variable definitions, and then generating the PDF. So, it would be better if we could just get the paragraph formats behaving properly despite changing conditions along the way for the various flavors of output. Right now it takes 8-12 hours for a team of 4 to generate our 7 documents, and this Frame Above / Frame Below problem with the paragraph formats is one of the main hindrances to automation. Rene Steve Rickaby wrote: At 12:16 -0700 11/4/07, Rene Stephenson wrote: >I can't trigger it without changing the show/hide conditions. I wonder if it >could be something triggered by show/hide conditions causing the para formats >to reapply the ref pages or something... Just did a show/hide switch a few times with one of my problem docs, but the problem didn't trigger. -- Steve
Maddening problem with frame below
At 05:37 -0700 12/4/07, Rene Stephenson wrote: >We're moving toward automating the PDF creation process from our FM files, >though, and I don't know if we'll be able to get it fully automated if we're >having to run a plugin between importing from the settings file to switch >conditions and variable definitions, and then generating the PDF. So, it >would be better if we could just get the paragraph formats behaving properly >despite changing conditions along the way for the various flavors of output. >Right now it takes 8-12 hours for a team of 4 to generate our 7 documents, and >this Frame Above / Frame Below problem with the paragraph formats is one of >the main hindrances to automation. If I get of whiff of what might trigger it, I'll be sure to post it here. Tell you something that might be vaguely relevant. In another book and template entirely, I've made extensive use of the method of negative vertical spacing to 'slide' graphics behind paras, mainly because of the limitations of the 'frame below' option - mainly, that 'below' means 'below'. I think the original idea came from Hedley Finger, for which, thanks. It might be a solution to your problem, although it carries other issues, such as triggering the screen redraw bug big-time. I have a demo file I can send you offline if you're interested. -- Steve
Maddening problem with frame below
At 13:43 +0100 12/4/07, Steve Rickaby wrote: > I think the original idea came from Hedley Finger, for which, thanks. Grovel: it was Hayden Jones. Thanks anyway: Hedley's a hero too ;-) -- Steve
RE: Maddening problem with frame below
We have the same problem with 2 similar BlockLine paragraph tags that use 2 pt font w/ 6 pt space above and paragraph below pointing to a line on the reference page. Both are aligned across all columns and sideheads. Incientally, it doesn't happen with our Spacer paragraph tag, which is also 2 pt. with no space above or below but doesn't include a paragraph below setting and is in-column formatted. So, I don't know if it's due to sidehead involvement or the reference page use. I have found that every time I change show/hide conditions where this paragraph format is adjacent to text that gets hidden or shown in the operation, it reverts to the default settings for font size and space above, and the only way to fix it is to reimport paragraph formats. This happens in all of our documents, regardless of which condition tags are used or shown or hidden, so it seems to be dependent upon the point sizes I've tweaked the formats and round-tripped everything through MIF to no avail, even ran several plugins to clean out and remap the paragraph formats. I have just come to consider it as a bug and work around it (just as I limit my path length and dept to work around that particular bug). Therefore, as part of my production sequence, before I run Silicon Prairie's Paragraph Tools Remove Overrides. It's another manual step, but it only takes a couple of seconds. Doing so is only problematic if the writer has been using manual format overrides, which at this shop is taboo anyway. If there's a better solution, I'd love to know about it! Rene Stephenson Steve Rickaby [EMAIL PROTECTED] wrote: At 08:42 +0200 11/4/07, Reng, Winfried Dr. wrote: I have a similar problem. I have an infoicon paragraph in the sidehead area with a Frame below which holds the info icon. The paragraph font size is 2 pt, the space above is 22 pt. Now and then the font size and the space above change to normal values (font size 10 pt and space above 110 pt). As a consequence the info icon moves down by 6 cm. I didn't pay much attention to this problem yet. I have the feeling that this happens when I hide/show conditions. Eventually your problem is also caused by a very small font size which changes now and then. What exactly changes when your rule moves down? Maybe you should convert to MIF and compare all properties of this paragraph with the correct properties. Good question. Sadly in the single most recent instance I corrected it by reapplying the paragraph tag as soon as I'd checked that -L didn't do so. Next time it happens, I'll run forensics on the para tags involved to see if anything's changed, and if so, what. Thanks for the tip. If font sizes are changing at random in para tags, though, why don't we notice such an apparently gross problem elsewhere? If this is happening, maybe its's something specifically to do with para tags in association with reference frames? (You are perhaps a native German speaker, Winfried? Your use of 'eventually' suggests it, matching the German word 'Eventuell'.) -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/rinnie1%40yahoo.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. Rene L. Stephenson eNovative Solutions, Inc. Business Phone: 678-513-0051 Email: [EMAIL PROTECTED] ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Maddening problem with frame below
I believe that earlier FrameMaker releases were limited to 4pt as the smallest font size. With the 2pt minimum now allowed, perhaps it's possible that the conditional text programming wasn't changed accordingly. I think earlier in this thread a larger point size was noted also to fail, so perhaps that's not the issue. HTH Regards, Peter Gold KnowHow ProServices Rene Stephenson wrote: We have the same problem with 2 similar BlockLine paragraph tags that use 2 pt font w/ 6 pt space above and paragraph below pointing to a line on the reference page. Both are aligned across all columns and sideheads. Incientally, it doesn't happen with our Spacer paragraph tag, which is also 2 pt. with no space above or below but doesn't include a paragraph below setting and is in-column formatted. So, I don't know if it's due to sidehead involvement or the reference page use. I have found that every time I change show/hide conditions where this paragraph format is adjacent to text that gets hidden or shown in the operation, it reverts to the default settings for font size and space above, and the only way to fix it is to reimport paragraph formats. This happens in all of our documents, regardless of which condition tags are used or shown or hidden, so it seems to be dependent upon the point sizes I've tweaked the formats and round-tripped everything through MIF to no avail, even ran several plugins to clean out and remap the paragraph formats. I have just come to consider it as a bug and work around it (just as I limit my path length and dept to work around that particular bug). Therefore, as part of my production sequence, before I run Silicon Prairie's Paragraph Tools Remove Overrides. It's another manual step, but it only takes a couple of seconds. Doing so is only problematic if the writer has been using manual format overrides, which at this shop is taboo anyway. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Maddening problem with frame below
At 10:16 -0700 11/4/07, Rene Stephenson wrote: We have the same problem with 2 similar BlockLine paragraph tags that use 2 pt font w/ 6 pt space above and paragraph below pointing to a line on the reference page. Both are aligned across all columns and sideheads. Incientally, it doesn't happen with our Spacer paragraph tag, which is also 2 pt. with no space above or below but doesn't include a paragraph below setting and is in-column formatted. So, I don't know if it's due to sidehead involvement or the reference page use. I guess by the 'same problem', you're referring to Winifried's, not mine. I'm not using sideheads here, so I'd guess that if it's a bug, it's related to the reference page graphic. I have found that every time I change show/hide conditions where this paragraph format is adjacent to text that gets hidden or shown in the operation, it reverts to the default settings for font size and space above, and the only way to fix it is to reimport paragraph formats. Show/hide as in conditional text? Well, I'm not using conditional text anywhere near this problem para, but as I said before, I've not yet managed to trap what actually does trigger it. What do you mean by the 'default' setting for font sizes and spacing? The settings before overrides, or something else? (I'm not applying overrides.) This happens in all of our documents, regardless of which condition tags are used or shown or hidden, so it seems to be dependent upon the point sizes Bummer. I've tweaked the formats and round-tripped everything through MIF to no avail, even ran several plugins to clean out and remap the paragraph formats. I have just come to consider it as a bug and work around it (just as I limit my path length and dept to work around that particular bug). Therefore, as part of my production sequence, before I run Silicon Prairie's Paragraph Tools Remove Overrides. It's another manual step, but it only takes a couple of seconds. Doing so is only problematic if the writer has been using manual format overrides, which at this shop is taboo anyway. As here: the only overrides I permit myself are a few 'keep with nexts' when doing final page balancing. -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Maddening problem with frame below
Hi Steve, I have a similar problem. I have an infoicon paragraph in the sidehead area with a Frame below which holds the info icon. The paragraph font size is 2 pt, the space above is 22 pt. Now and then the font size and the space above change to "normal" values (font size 10 pt and space above 110 pt). As a consequence the info icon moves down by 6 cm. I didn't pay much attention to this problem yet. I have the feeling that this happens when I hide/show conditions. Eventually your problem is also caused by a very small font size which changes now and then. What exactly changes when your rule moves down? Maybe you should convert to MIF and compare all properties of this paragraph with the correct properties. Best regards Winfried > -Original Message- > From: framers-bounces+wreng=tycoint.com at lists.frameusers.com > [mailto:framers-bounces+wreng=tycoint.com at lists.frameusers.com > ]On Behalf > Of Steve Rickaby > Sent: Tuesday, April 10, 2007 5:43 PM > To: Art Campbell; Framers; Ridder, Fred > Subject: Re: Maddening problem with frame below > > > At 14:10 -0400 30/3/07, Art Campbell wrote: > > >It almost sounds like a display problem. Does it snap back into place > >when you do a Ctrl-L? > > ...and Fred wrote something similar. > > Well, it's just happened again, and no, it's not the screen > redraw bug. The misplaced rule survived a -L, and I had > to reapply the para format to correct it. > > > > >On 3/30/07, Steve Rickaby wrote: > >>I wonder if anyone can help me with an inexplicable irritation. > >> > >>I have a para format with an under-rule graphic taken off > the reference page and applied with the Frame blow pgf > feature in the Advanced pane of the para designer. > >> > >>When the format is initially applied to the para, the rule > appears correctly. Left to its own devices, however, (no, I > don't know, maybe during book update), the rule suddenly > appears about 18 points below where it should be, in fact in > the middle of the next line below. > >> > >>When I re-apply the format to the errant para, the rule > snaps back to where it's supposed to be. > >> > >>Any ideas? > >> > >>-- > >>Steve > >>___ > > > > > >-- > >Art Campbell > art.campbell at gmail.com > > "... In my opinion, there's nothing in this world beats a > '52 Vincent > > and a redheaded girl." -- Richard Thompson > >No disclaimers apply. > >DoD 358 > > > -- > Steve
Maddening problem with frame below
At 08:42 +0200 11/4/07, Reng, Winfried Dr. wrote: >I have a similar problem. I have an infoicon paragraph in the sidehead area >with a Frame below which holds the info icon. The paragraph font size is 2 pt, >the space above is 22 pt. Now and then the font size and the space above >change to "normal" values (font size 10 pt and space above 110 pt). As a >consequence the info icon moves down by 6 cm. I didn't pay much attention to >this problem yet. I have the feeling that this happens when I hide/show >conditions. > >Eventually your problem is also caused by a very small font size which changes >now and then. What exactly changes when your rule moves down? Maybe you should >convert to MIF and compare all properties of this paragraph with the correct >properties. Good question. Sadly in the single most recent instance I corrected it by reapplying the paragraph tag as soon as I'd checked that -L didn't do so. Next time it happens, I'll run forensics on the para tags involved to see if anything's changed, and if so, what. Thanks for the tip. If font sizes are changing at random in para tags, though, why don't we notice such an apparently gross problem elsewhere? If this is happening, maybe its's something specifically to do with para tags in association with reference frames? (You are perhaps a native German speaker, Winfried? Your use of 'eventually' suggests it, matching the German word 'Eventuell'.) -- Steve
Maddening problem with frame below
We have the same problem with 2 similar BlockLine paragraph tags that use 2 pt font w/ 6 pt space above and paragraph below pointing to a line on the reference page. Both are aligned across all columns and sideheads. Incientally, it doesn't happen with our Spacer paragraph tag, which is also 2 pt. with no space above or below but doesn't include a paragraph below setting and is in-column formatted. So, I don't know if it's due to sidehead involvement or the reference page use. I have found that every time I change show/hide conditions where this paragraph format is adjacent to text that gets hidden or shown in the operation, it reverts to the "default" settings for font size and space above, and the only way to fix it is to reimport paragraph formats. This happens in all of our documents, regardless of which condition tags are used or shown or hidden, so it seems to be dependent upon the point sizes I've tweaked the formats and round-tripped everything through MIF to no avail, even ran several plugins to clean out and remap the paragraph formats. I have just come to consider it as a bug and work around it (just as I limit my path length and dept to work around that particular bug). Therefore, as part of my production sequence, before I run Silicon Prairie's Paragraph Tools > Remove Overrides. It's another manual step, but it only takes a couple of seconds. Doing so is only problematic if the writer has been using manual format overrides, which at this shop is taboo anyway. If there's a better solution, I'd love to know about it! Rene Stephenson Steve Rickaby wrote: At 08:42 +0200 11/4/07, Reng, Winfried Dr. wrote: >I have a similar problem. I have an infoicon paragraph in the sidehead area >with a Frame below which holds the info icon. The paragraph font size is 2 pt, >the space above is 22 pt. Now and then the font size and the space above >change to "normal" values (font size 10 pt and space above 110 pt). As a >consequence the info icon moves down by 6 cm. I didn't pay much attention to >this problem yet. I have the feeling that this happens when I hide/show >conditions. > >Eventually your problem is also caused by a very small font size which changes >now and then. What exactly changes when your rule moves down? Maybe you should >convert to MIF and compare all properties of this paragraph with the correct >properties. Good question. Sadly in the single most recent instance I corrected it by reapplying the paragraph tag as soon as I'd checked that -L didn't do so. Next time it happens, I'll run forensics on the para tags involved to see if anything's changed, and if so, what. Thanks for the tip. If font sizes are changing at random in para tags, though, why don't we notice such an apparently gross problem elsewhere? If this is happening, maybe its's something specifically to do with para tags in association with reference frames? (You are perhaps a native German speaker, Winfried? Your use of 'eventually' suggests it, matching the German word 'Eventuell'.) -- Steve ___ You are currently subscribed to Framers as rinnie1 at yahoo.com. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/rinnie1%40yahoo.com Send administrative questions to listadmin at frameusers.com. Visit http://www.frameusers.com/ for more resources and info. Rene L. Stephenson eNovative Solutions, Inc. Business Phone: 678-513-0051 Email: rinnie1 at yahoo.com
Maddening problem with frame below
I believe that earlier FrameMaker releases were limited to 4pt as the smallest font size. With the 2pt minimum now allowed, perhaps it's possible that the conditional text programming wasn't changed accordingly. I think earlier in this thread a larger point size was noted also to fail, so perhaps that's not the issue. HTH Regards, Peter Gold KnowHow ProServices Rene Stephenson wrote: > We have the same problem with 2 similar BlockLine paragraph tags that use 2 > pt font w/ 6 pt space above and paragraph below pointing to a line on the > reference page. Both are aligned across all columns and sideheads. > Incientally, it doesn't happen with our Spacer paragraph tag, which is also 2 > pt. with no space above or below but doesn't include a paragraph below > setting and is in-column formatted. So, I don't know if it's due to sidehead > involvement or the reference page use. > > I have found that every time I change show/hide conditions where this > paragraph format is adjacent to text that gets hidden or shown in the > operation, it reverts to the "default" settings for font size and space > above, and the only way to fix it is to reimport paragraph formats. > > This happens in all of our documents, regardless of which condition tags are > used or shown or hidden, so it seems to be dependent upon the point sizes > > I've tweaked the formats and round-tripped everything through MIF to no > avail, even ran several plugins to clean out and remap the paragraph formats. > I have just come to consider it as a bug and work around it (just as I limit > my path length and dept to work around that particular bug). Therefore, as > part of my production sequence, before I run Silicon Prairie's Paragraph > Tools > Remove Overrides. It's another manual step, but it only takes a > couple of seconds. Doing so is only problematic if the writer has been using > manual format overrides, which at this shop is taboo anyway. >
Maddening problem with frame below
At 10:16 -0700 11/4/07, Rene Stephenson wrote: >We have the same problem with 2 similar BlockLine paragraph tags that use 2 pt >font w/ 6 pt space above and paragraph below pointing to a line on the >reference page. Both are aligned across all columns and sideheads. >Incientally, it doesn't happen with our Spacer paragraph tag, which is also 2 >pt. with no space above or below but doesn't include a paragraph below setting >and is in-column formatted. So, I don't know if it's due to sidehead >involvement or the reference page use. I guess by the 'same problem', you're referring to Winifried's, not mine. I'm not using sideheads here, so I'd guess that if it's a bug, it's related to the reference page graphic. >I have found that every time I change show/hide conditions where this >paragraph format is adjacent to text that gets hidden or shown in the >operation, it reverts to the "default" settings for font size and space above, >and the only way to fix it is to reimport paragraph formats. Show/hide as in conditional text? Well, I'm not using conditional text anywhere near this problem para, but as I said before, I've not yet managed to trap what actually does trigger it. What do you mean by the 'default' setting for font sizes and spacing? The settings before overrides, or something else? (I'm not applying overrides.) >This happens in all of our documents, regardless of which condition tags are >used or shown or hidden, so it seems to be dependent upon the point sizes Bummer. >I've tweaked the formats and round-tripped everything through MIF to no avail, >even ran several plugins to clean out and remap the paragraph formats. I have >just come to consider it as a bug and work around it (just as I limit my path >length and dept to work around that particular bug). Therefore, as part of my >production sequence, before I run Silicon Prairie's Paragraph Tools > Remove >Overrides. It's another manual step, but it only takes a couple of seconds. >Doing so is only problematic if the writer has been using manual format >overrides, which at this shop is taboo anyway. As here: the only overrides I permit myself are a few 'keep with nexts' when doing final page balancing. -- Steve
Maddening problem with frame below
Steve Rickaby wrote:>I guess by the 'same problem', you're referring to Winifried's, not mine. Yes, sorry. >I'm not using sideheads here, so I'd guess that if it's a bug, it's related to >the reference page graphic. OK, in light of this and Peter's comment about earlier in this thread larger point sizes being affected, I think you're right. Actually, I must correct myself: the graphic on the reference page is included in the BlockLine para format via Frame Above Pgf, not below; so, that would lead me to believe it doesn't matter whether it's a Frame Above Pgf or Frame Below Pgf, as much as it is just the fact that it involves the Reference page. >Show/hide as in conditional text? Yes. >Well, I'm not using conditional text anywhere near this problem para, but as I >said before, I've not yet managed to trap what actually does trigger it. I just did a test and found it happening when condition-tagged text is not adjacent to the BlockLine para tag, too. But, I can't trigger it without changing the show/hide conditions. I wonder if it could be something triggered by show/hide conditions causing the para formats to reapply the ref pages or something... >What do you mean by the 'default' setting for font sizes and spacing? By "default" settings, I was just echoing Winfried. Although when I select one of the errant BlockLine paragraphs and view it in Paragraph Designer, everything appears correct without overrides, it shows as *BlockLine in the Formatting bar, and when I check Format > Size, it shows 11 pt (which is the size it appears to be) checked rather than 2 pt. Rene
Re: Maddening problem with frame below
At 14:10 -0400 30/3/07, Art Campbell wrote: It almost sounds like a display problem. Does it snap back into place when you do a Ctrl-L? ...and Fred wrote something similar. Well, it's just happened again, and no, it's not the screen redraw bug. The misplaced rule survived a ctrl-L, and I had to reapply the para format to correct it. On 3/30/07, Steve Rickaby [EMAIL PROTECTED] wrote: I wonder if anyone can help me with an inexplicable irritation. I have a para format with an under-rule graphic taken off the reference page and applied with the Frame blow pgf feature in the Advanced pane of the para designer. When the format is initially applied to the para, the rule appears correctly. Left to its own devices, however, (no, I don't know, maybe during book update), the rule suddenly appears about 18 points below where it should be, in fact in the middle of the next line below. When I re-apply the format to the errant para, the rule snaps back to where it's supposed to be. Any ideas? -- Steve ___ -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Maddening problem with frame below
Weird. There isn't a lot of white space in the container around the rule on the Ref Page, is there? No chance there's any other container there, maybe an empty/invisible one? If it looks clean, I'd try the Wash-to-MIF maneuver just to make sure that the file isn't corrupted (the original text is clean? not a Word import?). Art On 4/10/07, Steve Rickaby [EMAIL PROTECTED] wrote: At 14:10 -0400 30/3/07, Art Campbell wrote: It almost sounds like a display problem. Does it snap back into place when you do a Ctrl-L? ...and Fred wrote something similar. Well, it's just happened again, and no, it's not the screen redraw bug. The misplaced rule survived a ctrl-L, and I had to reapply the para format to correct it. On 3/30/07, Steve Rickaby [EMAIL PROTECTED] wrote: I wonder if anyone can help me with an inexplicable irritation. I have a para format with an under-rule graphic taken off the reference page and applied with the Frame blow pgf feature in the Advanced pane of the para designer. When the format is initially applied to the para, the rule appears correctly. Left to its own devices, however, (no, I don't know, maybe during book update), the rule suddenly appears about 18 points below where it should be, in fact in the middle of the next line below. When I re-apply the format to the errant para, the rule snaps back to where it's supposed to be. Any ideas? -- Steve ___ -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 -- Steve -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Maddening problem with frame below
At 11:50 -0400 10/4/07, Art Campbell wrote: There isn't a lot of white space in the container around the rule on the Ref Page, is there? No chance there's any other container there, maybe an empty/invisible one? I've just pulled it apart, and, sadly, no. 'Sadly' because it would have been a good explanation. If it looks clean, I'd try the Wash-to-MIF maneuver just to make sure that the file isn't corrupted (the original text is clean? not a Word import?). Oh no! Word... sheesh. (When I first read 'the original text is clean', I thought you were referring to my language ;-). The only vaguely unusual feature is that this is the title of a bullet list that's sitting inside a one-column one-row table, but I'm pretty sure that the bug used to manifest itself with this para tag even before I rejigged the template to put the list in a table. It's 30 chapters, and it's got to go off today, so I'm just going to live with it at the moment, but I would like to find out what's going on, particularly as it's intermittent and always catches me off guard. -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Maddening problem with frame below
Hi, Art: Is it possible that the character tag used in the bullet paragraph has a font-size attribute that varies sometimes, perhaps due to a rounding error? Similarly, have you looked at the line-space (leading) and font size of the paragraph format? Oh, and one more thing: in a narrow column, perhaps the width of the reference frame is bumping into the column and pseudo-wrapping to the lower position. Have you tried using an anchored frame below, with a rule, instead of the reference frame, just to see if it's stable? HTH Regards, Peter Gold KnowHow ProServices Steve Rickaby wrote: At 11:50 -0400 10/4/07, Art Campbell wrote: There isn't a lot of white space in the container around the rule on the Ref Page, is there? No chance there's any other container there, maybe an empty/invisible one? I've just pulled it apart, and, sadly, no. 'Sadly' because it would have been a good explanation. If it looks clean, I'd try the Wash-to-MIF maneuver just to make sure that the file isn't corrupted (the original text is clean? not a Word import?). Oh no! Word... sheesh. (When I first read 'the original text is clean', I thought you were referring to my language ;-). The only vaguely unusual feature is that this is the title of a bullet list that's sitting inside a one-column one-row table, but I'm pretty sure that the bug used to manifest itself with this para tag even before I rejigged the template to put the list in a table. It's 30 chapters, and it's got to go off today, so I'm just going to live with it at the moment, but I would like to find out what's going on, particularly as it's intermittent and always catches me off guard. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Maddening problem with frame below
At 11:50 -0500 10/4/07, Mike Wickham wrote: Grasping at straws, here, but I vaguely recall a problem I had with similar reference line. After testing it, I had decided that I wanted to move the line up closer to the text it followed. So I went to the reference page to tweak it. I can't absolutely recall the problem my tweaking caused-- except that the line was not falling where I expected-- but I do remember the fix. It turned out that, instead of selecting the line and moving it up closer to the top border of its reference frame, I had selected the reference frame and moved the top of it down closer to the line. Apparently, this didn't remove space between the line and the top of the reference frame, it only hid the extra space from my eye. FrameMaker still managed to find that space and display it on the body page. Good idea, but no: this line is very carefully positioned, and under 1600% zoom it's well clear of the top of the reference frame, by about 0.4 mm. At 11:52 -0500 10/4/07, Peter Gold wrote: Hi, Art: Steve... Is it possible that the character tag used in the bullet paragraph has a font-size attribute that varies sometimes, perhaps due to a rounding error? Similarly, have you looked at the line-space (leading) and font size of the paragraph format? They are 11.5 point and 10.5 point Frutiger. Oh, and one more thing: in a narrow column, perhaps the width of the reference frame is bumping into the column and pseudo-wrapping to the lower position. Reference frame is 1 mm shorter than table column width. Maybe I should make it a lot shorter. Have you tried using an anchored frame below, with a rule, instead of the reference frame, just to see if it's stable? Nope. I guess I could try that, but I'm pretty much done working with these files now, and as the bug only manifests itself occasionally, so occasionally that I cannot put my finder on what triggers it, it might take me a while to even know if this was stable. As this under-rule is only used on a single para per document, there doesn't seem to be a lot of point in having it on the reference page anyway. Thanks, everyone. -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Maddening problem with frame below
At 14:10 -0400 30/3/07, Art Campbell wrote: >It almost sounds like a display problem. Does it snap back into place >when you do a Ctrl-L? ...and Fred wrote something similar. Well, it's just happened again, and no, it's not the screen redraw bug. The misplaced rule survived a -L, and I had to reapply the para format to correct it. > >On 3/30/07, Steve Rickaby wrote: >>I wonder if anyone can help me with an inexplicable irritation. >> >>I have a para format with an under-rule graphic taken off the reference page >>and applied with the Frame blow pgf feature in the Advanced pane of the para >>designer. >> >>When the format is initially applied to the para, the rule appears correctly. >>Left to its own devices, however, (no, I don't know, maybe during book >>update), the rule suddenly appears about 18 points below where it should be, >>in fact in the middle of the next line below. >> >>When I re-apply the format to the errant para, the rule snaps back to where >>it's supposed to be. >> >>Any ideas? >> >>-- >>Steve >>___ > > >-- >Art Campbell art.campbell at >gmail.com > "... In my opinion, there's nothing in this world beats a '52 Vincent > and a redheaded girl." -- Richard Thompson >No disclaimers apply. >DoD 358 -- Steve
Maddening problem with frame below
Weird. There isn't a lot of white space in the container around the rule on the Ref Page, is there? No chance there's any other container there, maybe an empty/invisible one? If it looks clean, I'd try the Wash-to-MIF maneuver just to make sure that the file isn't corrupted (the original text is clean? not a Word import?). Art On 4/10/07, Steve Rickaby wrote: > At 14:10 -0400 30/3/07, Art Campbell wrote: > > >It almost sounds like a display problem. Does it snap back into place > >when you do a Ctrl-L? > > ...and Fred wrote something similar. > > Well, it's just happened again, and no, it's not the screen redraw bug. The > misplaced rule survived a -L, and I had to reapply the para format to > correct it. > > > > >On 3/30/07, Steve Rickaby wrote: > >>I wonder if anyone can help me with an inexplicable irritation. > >> > >>I have a para format with an under-rule graphic taken off the reference > >>page and applied with the Frame blow pgf feature in the Advanced pane of > >>the para designer. > >> > >>When the format is initially applied to the para, the rule appears > >>correctly. Left to its own devices, however, (no, I don't know, maybe > >>during book update), the rule suddenly appears about 18 points below where > >>it should be, in fact in the middle of the next line below. > >> > >>When I re-apply the format to the errant para, the rule snaps back to where > >>it's supposed to be. > >> > >>Any ideas? > >> > >>-- > >>Steve > >>___ > > > > > >-- > >Art Campbell art.campbell at > >gmail.com > > "... In my opinion, there's nothing in this world beats a '52 Vincent > > and a redheaded girl." -- Richard Thompson > >No disclaimers apply. > >DoD 358 > > > -- > Steve > -- Art Campbell art.campbell at gmail.com "... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl." -- Richard Thompson No disclaimers apply. DoD 358
Maddening problem with frame below
At 11:50 -0400 10/4/07, Art Campbell wrote: >There isn't a lot of white space in the container around the rule on >the Ref Page, is there? >No chance there's any other container there, maybe an empty/invisible one? I've just pulled it apart, and, sadly, no. 'Sadly' because it would have been a good explanation. >If it looks clean, I'd try the Wash-to-MIF maneuver just to make sure >that the file isn't corrupted (the original text is clean? not a Word >import?). Oh no! Word... sheesh. (When I first read 'the original text is clean', I thought you were referring to my language ;-). The only vaguely unusual feature is that this is the title of a bullet list that's sitting inside a one-column one-row table, but I'm pretty sure that the bug used to manifest itself with this para tag even before I rejigged the template to put the list in a table. It's 30 chapters, and it's got to go off today, so I'm just going to live with it at the moment, but I would like to find out what's going on, particularly as it's intermittent and always catches me off guard. -- Steve
Maddening problem with frame below
Hi, Art: Is it possible that the character tag used in the bullet paragraph has a font-size attribute that varies sometimes, perhaps due to a rounding error? Similarly, have you looked at the line-space (leading) and font size of the paragraph format? Oh, and one more thing: in a narrow column, perhaps the width of the reference frame is bumping into the column and pseudo-wrapping to the lower position. Have you tried using an anchored frame below, with a rule, instead of the reference frame, just to see if it's stable? HTH Regards, Peter Gold KnowHow ProServices Steve Rickaby wrote: > At 11:50 -0400 10/4/07, Art Campbell wrote: > > >> There isn't a lot of white space in the container around the rule on >> the Ref Page, is there? >> No chance there's any other container there, maybe an empty/invisible one? >> > > I've just pulled it apart, and, sadly, no. 'Sadly' because it would have been > a good explanation. > > >> If it looks clean, I'd try the Wash-to-MIF maneuver just to make sure >> that the file isn't corrupted (the original text is clean? not a Word >> import?). >> > > Oh no! Word... sheesh. (When I first read 'the original text is clean', I > thought you were referring to my language ;-). > > The only vaguely unusual feature is that this is the title of a bullet list > that's sitting inside a one-column one-row table, but I'm pretty sure that > the bug used to manifest itself with this para tag even before I rejigged the > template to put the list in a table. > > It's 30 chapters, and it's got to go off today, so I'm just going to live > with it at the moment, but I would like to find out what's going on, > particularly as it's intermittent and always catches me off guard. > >
Maddening problem with frame below
At 11:50 -0500 10/4/07, Mike Wickham wrote: >Grasping at straws, here, but I vaguely recall a problem I had with similar >reference line. After testing it, I had decided that I wanted to move the line >up closer to the text it followed. So I went to the reference page to tweak >it. I can't absolutely recall the problem my tweaking caused-- except that the >line was not falling where I expected-- but I do remember the fix. It turned >out that, instead of selecting the line and moving it up closer to the top >border of its reference frame, I had selected the reference frame and moved >the top of it down closer to the line. Apparently, this didn't remove space >between the line and the top of the reference frame, it only hid the extra >space from my eye. FrameMaker still managed to find that space and display it >on the body page. Good idea, but no: this line is very carefully positioned, and under 1600% zoom it's well clear of the top of the reference frame, by about 0.4 mm. At 11:52 -0500 10/4/07, Peter Gold wrote: >Hi, Art: Steve... >Is it possible that the character tag used in the bullet paragraph has a >font-size attribute that varies sometimes, perhaps due to a rounding error? >Similarly, have you looked at the line-space (leading) and font size of the >paragraph format? They are 11.5 point and 10.5 point Frutiger. >Oh, and one more thing: in a narrow column, perhaps the width of the reference >frame is bumping into the column and pseudo-wrapping to the lower position. Reference frame is 1 mm shorter than table column width. Maybe I should make it a lot shorter. >Have you tried using an anchored frame below, with a rule, instead of the >reference frame, just to see if it's stable? Nope. I guess I could try that, but I'm pretty much done working with these files now, and as the bug only manifests itself occasionally, so occasionally that I cannot put my finder on what triggers it, it might take me a while to even know if this was stable. As this under-rule is only used on a single para per document, there doesn't seem to be a lot of point in having it on the reference page anyway. Thanks, everyone. -- Steve
Maddening problem with frame below
I wonder if anyone can help me with an inexplicable irritation. I have a para format with an under-rule graphic taken off the reference page and applied with the Frame blow pgf feature in the Advanced pane of the para designer. When the format is initially applied to the para, the rule appears correctly. Left to its own devices, however, (no, I don't know, maybe during book update), the rule suddenly appears about 18 points below where it should be, in fact in the middle of the next line below. When I re-apply the format to the errant para, the rule snaps back to where it's supposed to be. Any ideas? -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Maddening problem with frame below
It almost sounds like a display problem. Does it snap back into place when you do a Ctrl-L? Art On 3/30/07, Steve Rickaby [EMAIL PROTECTED] wrote: I wonder if anyone can help me with an inexplicable irritation. I have a para format with an under-rule graphic taken off the reference page and applied with the Frame blow pgf feature in the Advanced pane of the para designer. When the format is initially applied to the para, the rule appears correctly. Left to its own devices, however, (no, I don't know, maybe during book update), the rule suddenly appears about 18 points below where it should be, in fact in the middle of the next line below. When I re-apply the format to the errant para, the rule snaps back to where it's supposed to be. Any ideas? -- Steve ___ -- Art Campbell [EMAIL PROTECTED] ... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl. -- Richard Thompson No disclaimers apply. DoD 358 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Maddening problem with frame below
I wonder if anyone can help me with an inexplicable irritation. I have a para format with an under-rule graphic taken off the reference page and applied with the Frame blow pgf feature in the Advanced pane of the para designer. When the format is initially applied to the para, the rule appears correctly. Left to its own devices, however, (no, I don't know, maybe during book update), the rule suddenly appears about 18 points below where it should be, in fact in the middle of the next line below. When I re-apply the format to the errant para, the rule snaps back to where it's supposed to be. Any ideas? -- Steve
Maddening problem with frame below
It almost sounds like a display problem. Does it snap back into place when you do a Ctrl-L? Art On 3/30/07, Steve Rickaby wrote: > I wonder if anyone can help me with an inexplicable irritation. > > I have a para format with an under-rule graphic taken off the reference page > and applied with the Frame blow pgf feature in the Advanced pane of the para > designer. > > When the format is initially applied to the para, the rule appears correctly. > Left to its own devices, however, (no, I don't know, maybe during book > update), the rule suddenly appears about 18 points below where it should be, > in fact in the middle of the next line below. > > When I re-apply the format to the errant para, the rule snaps back to where > it's supposed to be. > > Any ideas? > > -- > Steve > ___ -- Art Campbell art.campbell at gmail.com "... In my opinion, there's nothing in this world beats a '52 Vincent and a redheaded girl." -- Richard Thompson No disclaimers apply. DoD 358
