RE: Track Edits in FrameMaker 10
Hi Rick, Similarly to Linda I moved from FM 8 to FM 10 on Windows 7 early this year. I use the Track Text Edits feature for all documents. My experience: o Mandatory for me to see exact changes: What exactly has changed. Which change do I have to communicate to others. Which file must be translated. o It's difficult to manage Track Text Edits and Conditions for the same text. Track Text Edits cover condition indicators. Conditions are often not maintained when I type in a section with conditions. Therefore I have to check the conditions for all new text. o Less crashes with FM 10 than with FM 8 in relationship with conditions and Track Text Edits. My FM 10 crashes seem to be related to that FM 10 expects books which are createad in FM 10. Best regards Winfried -Original Message- From: framers-boun...@lists.frameusers.com [mailto:framers- boun...@lists.frameusers.com] On Behalf Of LGLists Sent: Wednesday, September 12, 2012 7:43 PM To: 'Rick Quatro'; framers@lists.frameusers.com Subject: RE: Track Edits in FrameMaker 10 Rick, I've been using FM 10 on Win 7 since January. I find that the track edits feature works well and similarly to FM 8. The advantage that FM 10 has, if I recall correctly, is that I can enable and disable tracking edits for a single document or for all documents in the book. That's very handy. I can also accept or reject changes at both levels. As others have reported, I, too, sometimes see instability that seems to be associated with using track edits. I'm not completely sure about why it happens sometimes and not other times, but track edit does seem to have issues after I've worked on a draft for while with track edits on and the book also uses conditions. The instability manifests itself as FM crashes when I try to update or save the book. It seems to accumulate somehow. I can use track edits for a while (several days, lots of changes), then the crashing starts. I've only solved the crashing by turning off track edits. Hope this helps. ~ Linda G. Gallagher TechCom Plus, LLC lindag at techcomplus dot com www.techcomplus.com 303-450-9076 or 800-500-3144 -Original Message- From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Rick Quatro Sent: Wednesday, September 12, 2012 10:32 AM To: framers@lists.frameusers.com Subject: Track Edits in FrameMaker 10 I have a client that wants to know the pros and cons of the FrameMaker 10 Track Edits feature. I am not familiar enough with it to give them useful information. Any feedback from those using it would be appreciate it. Thank you very much. Rick Rick Quatro Carmen Publishing Inc. 585-283-5045 r...@frameexpert.com This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments. ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@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: Unstructured to Structured: Question about retaining pragraph formats
Jang, I think we're in agreement. I wasn't suggesting format rules over formats stored in catalogs. I was only saying that the formatting *triggers* have to be stored in the EDD. Maybe I didn't make the point clearly, but that was what I meant to say. I personally prefer to use formats stored in the template catalogs, rather than format rules in the EDD. Even for something as simple as changing from numbered to bulleted lists, I'd rather have individual pgf formats for each instance I have in mind. Then, if I want to change the look of the output, it's typical FrameMaker work -- import a different set of formats. Since they all must have the same names in the old and new template, import formats works very well. (As you described below) It's hard to force users not to make local formatting changes. But in this case, if they do they have to understand they're not using the system correctly. If they really need that format change, then you have no choice but to implement its *trigger* through the EDD. That's the only way to bring them back to using the system correctly. In the ideal XML world, there's no formatting effect that doesn't correspond to a structural declaration (or a specific attribute in the structure). The ideal may never be achieved, but trying for it is always appreciated... cud JANG SAID: = Hi Chris, In my structured FM projects, I keep formatting out of the EDD as much as possible. The EDD, as you correctly note in your posting, should be concerned with the structure of the content. By using only paragraph and character format tags, which are applied according to the rules in the EDD, I leave the formatting basically to the customer. But I do first of all tell them that any indiviual overrides should not be made, and also I give them a simple method to remove all such individual formatting: re-import the Element Definitions from the same file while checking the option Remove All Format Overrides. This re-applies the format tags according to the rules in the EDD and also removes all overrides that may have been introduced by the author. In my setup, a customer may have different style sheets for different product families, all using the same content with the same structure and the same paragraph and character format tags, i.e. no changes to the EDD. Whether the customer is going to stick to their style guide is not something to enforce by moving all formatting into a domain (the EDD) where it does not really belong. If all else fails, there is still the option to write a simple ExtendScript that removes the formatting toolbars and pods, including the paragraph and character designer, and making the keyboard shortcuts for those commands inactive. If authors cannot listen, you should basically cut off the fingers that make the mess, in a manner of speaking? That is my 2 cents in this discussion. I do agree with Scott that going via true XML might be a good solution, but only if the authors are not pulled out of their comfort zone too much. Ciao Jang ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@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: Unstructured to Structured: Question about retaining, paragraph formats
Just my two cents on this. There is no right answer. Depends where you want the control to be and maybe your philosophical approach - as in no formatting in the EDD. When I went structured, it was an opportunity to reduce paragraph format bloat. I analyzed what I needed, pared down the paragraph and character formats and tried to stay that way. I didn't want a different format for every possible different formatting issue that might come up. In part this means that if you are strict about things you don't let users deviate from the set of formats that are provided. But you can cover acceptable deviations by putting formatting in the EDD (if your philosophy permits this). As a practical matter, I have found that due to limitations in the EDD, there are times when putting formatting in the EDD works well and times when it just doesn't seem to work right. The conditions get too complicated and it isn't worth it. Of course, as a lone writer, I get to make all the decisions, but I try to act as if it were a bigger setup - no changes to para formats and no new on-the-fly formats allowed. With multiple books using the same EDD, they all have to comply or they get blasted every time I update the EDD, so there is a strong incentive to do things right. A previous respondent said: The idea with structure is (as has already been said) to separate structure from display.? I am not sure that I entirely agree with that. The idea of structure, particularly in FrameMaker, is that the computer enforces the formatting based on the element structure rather than writers needing to apply formatting via paragraph tags as they go along. If you are in a non-WYSIWYG environment, then you don't get the display. In FrameMaker you get the display too, but you don't have to be responsible for it, just for applying the correct element tags. Whether the computer enforces the formatting based entirely on what is in the EDD or on a mix of EDD coding and para formats is an implementation detail. Either way the application of formatting is done by the computer, not by the user. Fred -- Fred Wersan VT MÄK, Principal Technical Writer 68 Moulton Street, Cambridge, MA 02138 T: +1.617.876.8085 x124 Email: fwer...@mak.com Get Realistic Background Traffic - up to 75% off! www.mak.com/YourPatternOfLife | Offer ends September 25, 2012 ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@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: Unstructured to Structured: Question about retaining, paragraph formats
I like Fred's arguments here. I have mainly advocated the Paragraph/Character format approach in EDDs for two main reasons: 1) It is generally easier to have a single EDD work with multiple templates, which is advantageous for some document sets. 2) It allows the client a bit of flexibility in determining the look and feel of their templates. I do the EDD work and they can do the template work with the Paragraph and Character Designer interface that they are familiar with. Because the large number of formats that this approach can entail, you need to plan your format names carefully so they make sense to the template designer. Over time, I have become less strict, and moved to more of a mixed approach. For certain types of formatting, I will use a base paragraph format and specify exceptions in the EDD; for example, page breaks, extra space at the end of a list, etc. This still allows template changes with the Designers, but cuts back on the number of exception formats in the paragraph and character catalogs. I have found that this works well and still supports the two reasons above. Rick Rick Quatro Carmen Publishing Inc. 585-283-5045 r...@frameexpert.com -Original Message- From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Fred Wersan Sent: Thursday, September 13, 2012 1:29 PM To: framers@lists.frameusers.com Subject: Re: Unstructured to Structured: Question about retaining, paragraph formats Just my two cents on this. There is no right answer. Depends where you want the control to be and maybe your philosophical approach - as in no formatting in the EDD. When I went structured, it was an opportunity to reduce paragraph format bloat. I analyzed what I needed, pared down the paragraph and character formats and tried to stay that way. I didn't want a different format for every possible different formatting issue that might come up. In part this means that if you are strict about things you don't let users deviate from the set of formats that are provided. But you can cover acceptable deviations by putting formatting in the EDD (if your philosophy permits this). As a practical matter, I have found that due to limitations in the EDD, there are times when putting formatting in the EDD works well and times when it just doesn't seem to work right. The conditions get too complicated and it isn't worth it. Of course, as a lone writer, I get to make all the decisions, but I try to act as if it were a bigger setup - no changes to para formats and no new on-the-fly formats allowed. With multiple books using the same EDD, they all have to comply or they get blasted every time I update the EDD, so there is a strong incentive to do things right. A previous respondent said: The idea with structure is (as has already been said) to separate structure from display.? I am not sure that I entirely agree with that. The idea of structure, particularly in FrameMaker, is that the computer enforces the formatting based on the element structure rather than writers needing to apply formatting via paragraph tags as they go along. If you are in a non-WYSIWYG environment, then you don't get the display. In FrameMaker you get the display too, but you don't have to be responsible for it, just for applying the correct element tags. Whether the computer enforces the formatting based entirely on what is in the EDD or on a mix of EDD coding and para formats is an implementation detail. Either way the application of formatting is done by the computer, not by the user. Fred -- Fred Wersan VT MÄK, Principal Technical Writer 68 Moulton Street, Cambridge, MA 02138 T: +1.617.876.8085 x124 Email: fwer...@mak.com Get Realistic Background Traffic - up to 75% off! www.mak.com/YourPatternOfLife | Offer ends September 25, 2012 ___ You are currently subscribed to framers as r...@rickquatro.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/rick%40rickquatro.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info. ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@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: Track Edits in FrameMaker 10
Hi Rick, I'll just split this up into a pro and con list. :) Bottom line up front: its a decent solution if you are using it for a small team with three writers or less but it does not scale well at all in terms of content OR the number of users making edits. You'd be better off just using the commenting functionality in acrobat reader if there's a lot of edits/lots of editors etc. Pros: -allows you to track new text added in and deleted text. Deleted text appears in red and new text appears in green. Note these are in fact hidden conditional text. -allows you track which user has made a change so you can search for particular edits by user. You can also filter the edits so you only see edits by a particular user or users. -TT edits can be controlled on the document and book level so you can flip on TT edits for a particular book or for just a single document. -enable or disable TT edits across an entire book via a single click. -accept or reject all TT edits across an entire book via a single click Cons: -no commenting functionality. If you want to make a comment, it will appear as new text. -no way to visually distinguish between editors. For example, if John Doe inserts text and George Smith also inserts text they both appear as green text. You just know its newly inserted text, you have to pay careful attention via other subtle visual cues that its separate editors. -can be really had to use if you use conditional text especially if the text is the same color as the hidden conditional text of the insertion and deletion edits. Note also that if you apply conditional text to TT edit text that this can corrupt the book and cause the book to crash each time you do an update and save. -each time you turn TT edits it generates the stupid back up files for each file in the book which you'll have to clean up each time. -if you have a collaborative editing process where many people need to review text, make edits, and comments, then the process becomes nightmarish because its really hard to tell how is commenting on what or who is responding to what comment. -overall stability of framemaker seems to go down when the TT edits is turned on. It might be better in framemaker 11. Joe ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@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: Unstructured to Structured: Question about retaining, paragraph formats
Hi guys If you're planning to roundtrip through XML, with different authors using different XML editors, you'd need to have all the formatting in the EDD, right? Or am I on completely the wrong track in my ignorance? Thanks Rebecca Rick Quatro r...@rickquatro.com 14/09/12 10:02 I like Fred's arguments here. I have mainly advocated the Paragraph/Character format approach in EDDs for two main reasons: 1) It is generally easier to have a single EDD work with multiple templates, which is advantageous for some document sets. 2) It allows the client a bit of flexibility in determining the look and feel of their templates. I do the EDD work and they can do the template work with the Paragraph and Character Designer interface that they are familiar with. Because the large number of formats that this approach can entail, you need to plan your format names carefully so they make sense to the template designer. Over time, I have become less strict, and moved to more of a mixed approach. For certain types of formatting, I will use a base paragraph format and specify exceptions in the EDD; for example, page breaks, extra space at the end of a list, etc. This still allows template changes with the Designers, but cuts back on the number of exception formats in the paragraph and character catalogs. I have found that this works well and still supports the two reasons above. Rick Rick Quatro Carmen Publishing Inc. 585-283-5045 r...@frameexpert.com -Original Message- From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Fred Wersan Sent: Thursday, September 13, 2012 1:29 PM To: framers@lists.frameusers.com Subject: Re: Unstructured to Structured: Question about retaining, paragraph formats Just my two cents on this. There is no right answer. Depends where you want the control to be and maybe your philosophical approach - as in no formatting in the EDD. When I went structured, it was an opportunity to reduce paragraph format bloat. I analyzed what I needed, pared down the paragraph and character formats and tried to stay that way. I didn't want a different format for every possible different formatting issue that might come up. In part this means that if you are strict about things you don't let users deviate from the set of formats that are provided. But you can cover acceptable deviations by putting formatting in the EDD (if your philosophy permits this). As a practical matter, I have found that due to limitations in the EDD, there are times when putting formatting in the EDD works well and times when it just doesn't seem to work right. The conditions get too complicated and it isn't worth it. Of course, as a lone writer, I get to make all the decisions, but I try to act as if it were a bigger setup - no changes to para formats and no new on-the-fly formats allowed. With multiple books using the same EDD, they all have to comply or they get blasted every time I update the EDD, so there is a strong incentive to do things right. A previous respondent said: The idea with structure is (as has already been said) to separate structure from display.? I am not sure that I entirely agree with that. The idea of structure, particularly in FrameMaker, is that the computer enforces the formatting based on the element structure rather than writers needing to apply formatting via paragraph tags as they go along. If you are in a non-WYSIWYG environment, then you don't get the display. In FrameMaker you get the display too, but you don't have to be responsible for it, just for applying the correct element tags. Whether the computer enforces the formatting based entirely on what is in the EDD or on a mix of EDD coding and para formats is an implementation detail. Either way the application of formatting is done by the computer, not by the user. Fred -- Fred Wersan VT MÄK, Principal Te chnical Writer 68 Moulton Street, Cambridge, MA 02138 T: +1.617.876.8085 x124 Email: fwer...@mak.com Get Realistic Background Traffic - up to 75% off! www.mak.com/YourPatternOfLife | Offer ends September 25, 2012 ___ You are currently subscribed to framers as r...@rickquatro.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/rick%40rickquatro.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info. ___ You are currently subscribed to framers as rebecca.offi...@alliedtelesis.co.nz. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/rebecca.officer%40alliedtelesis.co.nz Send administrative questions to listad...@frameusers.com.
Re: Unstructured to Structured: Question about retaining, paragraph formats
You don't need to use structured FM for that. My paragraph tags map to different formats / tags depending on whether the output is PDF, Web help, Confluence XHTML, or 7-bit ASCII with layout. On Thu, Sep 13, 2012 at 10:29 AM, Fred Wersan fwer...@mak.com wrote: A previous respondent said: The idea with structure is (as has already been said) to separate structure from display.? I am not sure that I entirely agree with that. The idea of structure, particularly in FrameMaker, is that the computer enforces the formatting based on the element structure rather than writers needing to apply formatting via paragraph tags as they go along. If you are in a non-WYSIWYG environment, then you don't get the display. In FrameMaker you get the display too, but you don't have to be responsible for it, just for applying the correct element tags. Whether the computer enforces the formatting based entirely on what is in the EDD or on a mix of EDD coding and para formats is an implementation detail. Either way the application of formatting is done by the computer, not by the user. ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@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.
Automatic PDF Form
Goal: Upon generating a PDF, checkboxes appear next to each paragraph of a particular type, aligned right against the page margin. Can not use autonumbering, because the paragraph tag already has numbers. Can not manually create them in the PDF post-distillation, because we're talking about hundred of steps needing checkboxes--WAY too time-consuming. I am currently considering this method, using only FM 8 and Acrobat 9 Pro: 1) Manually place a checkbox glyph into a text frame within an anchor frame that is set to Run Into Paragraph and aligned right. 2) Add some kind of label within the text frame (e.g., Y, OK or Done). 3) Copy-and-paste the anchor for that frame at then end of every a new para of that type. 4) Distill to PDF. 5) Open PDF in AcroPro. 6) Let the Form Wizard detect the labelled checkboxes and auto-create them. Works, but error-prone in many ways: a) Writers forget to add the manually-placed frame. b) TONS of other stuff can be detected as form fields; and their auto-created fields have to be deleted (could be more work than adding fields manually post-PDFing!). Ideas? I suspect there's a plug-in that will automatically do this, if setup right initially (or will do it wherever a special type of marker is placed--half automatic so to speak). Thanks in advance; David Artman david artman designs ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@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.
Track Edits in FrameMaker 10
Hi Rick, Similarly to Linda I moved from FM 8 to FM 10 on Windows 7 early this year. I use the Track Text Edits feature for all documents. My experience: o Mandatory for me to see exact changes: What exactly has changed. Which change do I have to communicate to others. Which file must be translated. o It's difficult to manage Track Text Edits and Conditions for the same text. Track Text Edits cover condition indicators. Conditions are often not maintained when I type in a section with conditions. Therefore I have to check the conditions for all new text. o Less crashes with FM 10 than with FM 8 in relationship with conditions and Track Text Edits. My FM 10 crashes seem to be related to that FM 10 expects books which are createad in FM 10. Best regards Winfried > -Original Message- > From: framers-bounces at lists.frameusers.com [mailto:framers- > bounces at lists.frameusers.com] On Behalf Of LGLists > Sent: Wednesday, September 12, 2012 7:43 PM > To: 'Rick Quatro'; framers at lists.frameusers.com > Subject: RE: Track Edits in FrameMaker 10 > > Rick, > > I've been using FM 10 on Win 7 since January. I find that the track edits > feature works well and similarly to FM 8. The advantage that FM 10 has, if I > recall correctly, is that I can enable and disable tracking edits for a > single document or for all documents in the book. That's very handy. I can > also accept or reject changes at both levels. > > As others have reported, I, too, sometimes see instability that seems to be > associated with using track edits. I'm not completely sure about why it > happens sometimes and not other times, but track edit does seem to have > issues after I've worked on a draft for while with track edits on and the > book also uses conditions. > > The instability manifests itself as FM crashes when I try to update or save > the book. It seems to accumulate somehow. I can use track edits for a while > (several days, lots of changes), then the crashing starts. I've only solved > the crashing by turning off track edits. > > Hope this helps. > > > ~ > Linda G. Gallagher > TechCom Plus, LLC > lindag at techcomplus dot com > www.techcomplus.com > 303-450-9076 or 800-500-3144 > > > > > -Original Message- > From: framers-bounces at lists.frameusers.com > [mailto:framers-bounces at lists.frameusers.com] On Behalf Of Rick Quatro > Sent: Wednesday, September 12, 2012 10:32 AM > To: framers at lists.frameusers.com > Subject: Track Edits in FrameMaker 10 > > I have a client that wants to know the pros and cons of the FrameMaker 10 > Track Edits feature. I am not familiar enough with it to give them useful > information. Any feedback from those using it would be appreciate it. Thank > you very much. > > Rick > > Rick Quatro > Carmen Publishing Inc. > 585-283-5045 > rick at frameexpert.com This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
Unstructured to Structured: Question about retaining pragraph formats
Jang, I think we're in agreement.? I wasn't suggesting format rules over formats stored in catalogs.? I was only saying that the formatting *triggers* have to be stored in the EDD.? Maybe I didn't make the point clearly, but that was what I meant to say.? I personally prefer to use formats stored in the template catalogs, rather than format rules in the EDD.? Even for something as simple as changing from numbered to bulleted lists, I'd rather have individual pgf formats for each instance I have in mind.? Then, if I want to change the look of the output, it's typical FrameMaker work -- import a different set of formats.? Since they all must have the same names in the old and new template, import formats works very well.? (As you described below) It's hard to force users not to make local formatting changes.? But in this case, if they do they have to understand they're not using the system correctly.? If they really need that format change, then you have no choice but to implement its *trigger* through the EDD.? That's the only way to bring them back to using the system correctly.? In the ideal XML world, there's no formatting effect that doesn't correspond to a structural declaration (or a specific attribute in the structure).? The ideal may never be achieved, but trying for it is always appreciated... cud JANG SAID: = Hi Chris, In my structured FM projects, I keep formatting out of the EDD as much as possible. The EDD, as you correctly note in your posting, should be concerned with the structure of the content. By using only paragraph and character format tags, which are applied according to the rules in the EDD, I leave the formatting basically to the customer. But I do first of all tell them that any indiviual overrides should not be made, and also I give them a simple method to remove all such individual formatting: re-import the Element Definitions from the same file while checking the option "Remove All Format Overrides". This re-applies the format tags according to the rules in the EDD and also removes all overrides that may have been introduced by the author. In my setup, a customer may have different style sheets for different product families, all using the same content with the same structure and the same paragraph and character format tags, i.e. no changes to the EDD. Whether the customer is going to stick to their style guide is not something to enforce by moving all formatting into a domain (the EDD) where it does not really belong. If all else fails, there is still the option to write a simple ExtendScript that removes the formatting toolbars and pods, including the paragraph and character designer, and making the keyboard shortcuts for those commands inactive. If authors cannot listen, you should basically cut off the fingers that make the mess, in a manner of speaking? That is my 2 cents in this discussion. I do agree with Scott that going via true XML might be a good solution, but only if the authors are not pulled out of their comfort zone too much. Ciao Jang -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20120913/c81463f2/attachment.html>
Unstructured to Structured: Question about retaining, paragraph formats
Just my two cents on this. There is no right answer. Depends where you want the control to be and maybe your philosophical approach - as in "no formatting in the EDD". When I went structured, it was an opportunity to reduce paragraph format bloat. I analyzed what I needed, pared down the paragraph and character formats and tried to stay that way. I didn't want a different format for every possible different formatting issue that might come up. In part this means that if you are strict about things you don't let users deviate from the set of formats that are provided. But you can cover acceptable deviations by putting formatting in the EDD (if your philosophy permits this). As a practical matter, I have found that due to limitations in the EDD, there are times when putting formatting in the EDD works well and times when it just doesn't seem to work right. The conditions get too complicated and it isn't worth it. Of course, as a lone writer, I get to make all the decisions, but I try to act as if it were a bigger setup - no changes to para formats and no new on-the-fly formats allowed. With multiple books using the same EDD, they all have to comply or they get blasted every time I update the EDD, so there is a strong incentive to do things right. A previous respondent said: " The idea with structure is (as has already been said) to separate structure from display.?" I am not sure that I entirely agree with that. The idea of structure, particularly in FrameMaker, is that the computer enforces the formatting based on the element structure rather than writers needing to apply formatting via paragraph tags as they go along. If you are in a non-WYSIWYG environment, then you don't get the display. In FrameMaker you get the display too, but you don't have to be responsible for it, just for applying the correct element tags. Whether the computer enforces the formatting based entirely on what is in the EDD or on a mix of EDD coding and para formats is an implementation detail. Either way the application of formatting is done by the computer, not by the user. Fred -- Fred Wersan VT M?K, Principal Technical Writer 68 Moulton Street, Cambridge, MA 02138 T: +1.617.876.8085 x124 Email: fwersan at mak.com Get Realistic Background Traffic - up to 75% off! www.mak.com/YourPatternOfLife | Offer ends September 25, 2012
Unstructured to Structured: Question about retaining, paragraph formats
I like Fred's arguments here. I have mainly advocated the Paragraph/Character format approach in EDDs for two main reasons: 1) It is generally easier to have a single EDD work with multiple templates, which is advantageous for some document sets. 2) It allows the client a bit of flexibility in determining the look and feel of their templates. I do the EDD work and they can do the template work with the Paragraph and Character Designer interface that they are familiar with. Because the large number of formats that this approach can entail, you need to plan your format names carefully so they make sense to the template designer. Over time, I have become less strict, and moved to more of a mixed approach. For certain types of formatting, I will use a base paragraph format and specify "exceptions" in the EDD; for example, page breaks, extra space at the end of a list, etc. This still allows template changes with the Designers, but cuts back on the number of "exception" formats in the paragraph and character catalogs. I have found that this works well and still supports the two reasons above. Rick Rick Quatro Carmen Publishing Inc. 585-283-5045 rick at frameexpert.com -Original Message- From: framers-boun...@lists.frameusers.com [mailto:framers-bounces at lists.frameusers.com] On Behalf Of Fred Wersan Sent: Thursday, September 13, 2012 1:29 PM To: framers at lists.frameusers.com Subject: Re: Unstructured to Structured: Question about retaining, paragraph formats Just my two cents on this. There is no right answer. Depends where you want the control to be and maybe your philosophical approach - as in "no formatting in the EDD". When I went structured, it was an opportunity to reduce paragraph format bloat. I analyzed what I needed, pared down the paragraph and character formats and tried to stay that way. I didn't want a different format for every possible different formatting issue that might come up. In part this means that if you are strict about things you don't let users deviate from the set of formats that are provided. But you can cover acceptable deviations by putting formatting in the EDD (if your philosophy permits this). As a practical matter, I have found that due to limitations in the EDD, there are times when putting formatting in the EDD works well and times when it just doesn't seem to work right. The conditions get too complicated and it isn't worth it. Of course, as a lone writer, I get to make all the decisions, but I try to act as if it were a bigger setup - no changes to para formats and no new on-the-fly formats allowed. With multiple books using the same EDD, they all have to comply or they get blasted every time I update the EDD, so there is a strong incentive to do things right. A previous respondent said: " The idea with structure is (as has already been said) to separate structure from display.?" I am not sure that I entirely agree with that. The idea of structure, particularly in FrameMaker, is that the computer enforces the formatting based on the element structure rather than writers needing to apply formatting via paragraph tags as they go along. If you are in a non-WYSIWYG environment, then you don't get the display. In FrameMaker you get the display too, but you don't have to be responsible for it, just for applying the correct element tags. Whether the computer enforces the formatting based entirely on what is in the EDD or on a mix of EDD coding and para formats is an implementation detail. Either way the application of formatting is done by the computer, not by the user. Fred -- Fred Wersan VT M?K, Principal Technical Writer 68 Moulton Street, Cambridge, MA 02138 T: +1.617.876.8085 x124 Email: fwersan at mak.com Get Realistic Background Traffic - up to 75% off! www.mak.com/YourPatternOfLife | Offer ends September 25, 2012 ___ You are currently subscribed to framers as rick at rickquatro.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/rick%40rickquatro.com Send administrative questions to listadmin at frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Unstructured to Structured: Question about retaining, paragraph formats
You don't need to use structured FM for that. My paragraph tags map to different formats / tags depending on whether the output is PDF, Web help, Confluence XHTML, or 7-bit ASCII with layout. On Thu, Sep 13, 2012 at 10:29 AM, Fred Wersan wrote: > A previous respondent said: " > > The idea with structure is (as has already been said) to separate structure > from display.?" > > > I am not sure that I entirely agree with that. The idea of structure, > particularly in FrameMaker, is that the computer enforces the formatting > based on the element structure rather than writers needing to apply > formatting via paragraph tags as they go along. If you are in a non-WYSIWYG > environment, then you don't get the display. In FrameMaker you get the > display too, but you don't have to be responsible for it, just for applying > the correct element tags. Whether the computer enforces the formatting based > entirely on what is in the EDD or on a mix of EDD coding and para formats is > an implementation detail. Either way the application of formatting is done > by the computer, not by the user.
Automatic PDF Form
Goal: Upon generating a PDF, checkboxes appear next to each paragraph of a particular type, aligned right against the page margin. Can not use autonumbering, because the paragraph tag already has numbers. Can not manually create them in the PDF post-distillation, because we're talking about hundred of steps needing checkboxes--WAY too time-consuming. I am currently considering this method, using only FM 8 and Acrobat 9 Pro: 1) Manually place a checkbox glyph into a text frame within an anchor frame that is set to "Run Into Paragraph" and aligned right. 2) Add some kind of label within the text frame (e.g., "Y", "OK" or "Done"). 3) Copy-and-paste the anchor for that frame at then end of every a new para of that type. 4) Distill to PDF. 5) Open PDF in AcroPro. 6) Let the Form Wizard detect the labelled checkboxes and auto-create them. Works, but error-prone in many ways: a) Writers forget to add the manually-placed frame. b) TONS of other stuff can be detected as "form fields"; and their auto-created fields have to be deleted (could be more work than adding fields manually post-PDFing!). Ideas? I suspect there's a plug-in that will automatically do this, if setup right initially (or will do it wherever a special type of marker is placed--"half automatic" so to speak). Thanks in advance; David Artman david artman designs
