Keeping track of graphics
At 11:49 am -0600 8/12/05, Peter Gold wrote: >Hi, Steve: > >Thanks for the feedback. Do you think there was a problem with Classic's >ability to handle the length of the filename or pathname? No, I don't think so, as the folder concerned was just called 'Graphics' ;-) I expected it to work, but it didn't. Surprise. Ah, I see what you mean... the combined length of the pathname might have been too long. Er, ok - will run simple test now... no, it doesn't work even when the combined path lengths come nowhere near the 31 character limit. FrameMake doesn't want to follow an alias to a graphics folder that has the same name as the original. However, once you've told it to use the alias and chosen the 'update document to use new path', all is well, and remains so. I realise I'm not being as clear as I might here: what is happening is that FrameMaker, after using an actual folder to source graphics, cannot identify an alias to that folder as being the same thing until it's told to. After that, it uses the alias ok. Sorry if I confused anyone earlier. -- Steve
Keeping track of graphics
At 11:39 am -0600 8/12/05, Peter Gold wrote: >Has anyone successfully employed operating system links, aliases, or shortcuts >in project-specific graphics folders for this purpose? The idea is that you >can have project-specific directory structures that only contain links to the >source graphics that are stored in a central location. Each project's graphics >directory contains only the project's graphic links. FM files in each project >refer to the link, not to the source. I tried alising a graphic folder within a book folder in FrameMaker 6 on Mac, but FrameMaker could not follow the link. -- Steve
Keeping track of graphics
I use a mixed method, but reference *all* my graphics. All scaps (screen captures) are in PNG format. I have a Directory tree like so: | -- || | | Pix P1P2Help | | ---- | || | P1_Only P2_Only P1_Help P2_Help NOTES: P1, P2 ... Have the FM files in them Pix has all the images except product-specific ones. I also use a naming pattern: but_ (scap of graphic button) btxt_ (scap of text button) dlg__ (scap of dialog -- with feature selected if required) dtl_ (scap of detail -- usually just a part of a screen.) emess_(scap of message dialog) ill_ (externally created line drawing, flowchart, etc.) pic_ (scap of a displayed function; for example the chart of a stock) menu_(scap of menu) rmenu_ (scap of right-click menu) tbar_ (scap of toolbar) wiz__P (scap of wizard page 1-n) This makes themn easy to sort/locate. For ease of use, the product specific versions are all prefixed by a 3-character code and an underscore (example: PRO_dlg_YAxis_Props_Grid.png = Professional version, Y-axis Properties dialog, Grid tab ) I also have a number of naming conventions that are peculiar to this particular product interface (candlestick, sample, and others) Grant -Original Message- From: Peter Gold Sent: Thursday, December 08, 2005 10:40 AM To: Martinek, Carla Cc: framers at lists.frameusers.com Subject: RE: Keeping track of graphics Carla's point about using one graphic for all linked uses is the simplest. However, the single central folder of all graphics could be confusing. Has anyone successfully employed operating system links, aliases, or shortcuts in project-specific graphics folders for this purpose? The idea is that you can have project-specific directory structures that only contain links to the source graphics that are stored in a central location. Each project's graphics directory contains only the project's graphic links. FM files in each project refer to the link, not to the source. The advantages are fewer graphics (links) to manage for each project, and a single graphic source for multiple uses. The disadvantage is setting it up and retraining authors to use the new approach. I know that unix links are reliable, and that the reliable Macintosh aliases are not an option past FM 7.0. Is anyone using Windows shortcuts? Regards, Peter Gold KnowHow ProServices peter at knowhowpro.com
Keeping track of graphics
Hi, Steve: Thanks for the feedback. Do you think there was a problem with Classic's ability to handle the length of the filename or pathname? Regards, Peter Gold KnowHow ProServices At 5:44 PM + 12/8/05, Steve Rickaby wrote: >At 11:39 am -0600 8/12/05, Peter Gold wrote: > >>Has anyone successfully employed operating system links, aliases, >>or shortcuts in project-specific graphics folders for this purpose? >>The idea is that you can have project-specific directory structures >>that only contain links to the source graphics that are stored in a >>central location. Each project's graphics directory contains only >>the project's graphic links. FM files in each project refer to the >>link, not to the source. > >I tried alising a graphic folder within a book folder in FrameMaker >6 on Mac, but FrameMaker could not follow the link. >-- >Steve
Keeping track of graphics
Carla's point about using one graphic for all linked uses is the simplest. However, the single central folder of all graphics could be confusing. Has anyone successfully employed operating system links, aliases, or shortcuts in project-specific graphics folders for this purpose? The idea is that you can have project-specific directory structures that only contain links to the source graphics that are stored in a central location. Each project's graphics directory contains only the project's graphic links. FM files in each project refer to the link, not to the source. The advantages are fewer graphics (links) to manage for each project, and a single graphic source for multiple uses. The disadvantage is setting it up and retraining authors to use the new approach. I know that unix links are reliable, and that the reliable Macintosh aliases are not an option past FM 7.0. Is anyone using Windows shortcuts? Regards, Peter Gold KnowHow ProServices peter at knowhowpro.com At 11:09 AM -0600 12/8/05, Martinek, Carla wrote: >We reference all graphics into our documents. Currently we have a >couple of thousand graphics stored centrally in the same folder >location. While it can be a bit cumbersome to maintain that many >graphics in the same folder, it ends up helping us in the long run >because if a graphic is updated, it gets updated in *all* locations >where it is used. Previously we had project-specific graphic folders, >and we found that the same graphic might be updated for one manual, but >not for another.
Keeping track of graphics
Pearl, We only reference graphics and don't have any trouble keeping track of them (well, mostly no trouble). We name graphics according to their figure number or use and UNF for un-numbered graphics. The rub comes when an author inserts a figure and all the figure numbers in the book change --- you end up with actual figure numbers being different than the figure number in the book, unless you renumber. Our books are done by chapter, so the quantity of graphics is usually small enough that we renumber to keep things in sync. If the author adds a graphic its not as bad: you just add an alpha to the numbering scheme for the graphic (UNF1-1, UNF1-1b, UNF 1-2). -bob Robert Kern President, TIPS Technical Publishing, Inc. 108 E. Main Street, Suite 4 Carrboro, NC 27510 www.technicalpublishing.com bob at technicalpublishing.com 919-933-2629 phone and fax pearlrosenberg at nc.rr.com wrote: >Hi Dominick, > >I do not reference my graphics, but this may be a good reason to do >so. Altho having the graphics in the files makes them larger, I also >thought it would be easier to manage the book without a directory of >graphics. > >I'd be interested to hear from those of you who reference graphics >about how hard it is (or isn't) to keep track of the graphic files. > >Pearl Rosenberg >TeleHealth Services > >- Original Message - >From: "DeFlorio, Dominick" >Date: Thursday, December 8, 2005 10:28 am >Subject: RE: Can't Open a FM File > > > >>If it is hanging-up on a graphic, and you reference your graphics, >> >> >try > > >>renaming the graphics folder. If the file is not corrupt, Frame >>shouldopen the file and issue an error message. >> >> >>Dominick A. DeFlorio >>Senior Technical Writer >>Plug Power, Inc. >>968 Albany-Shaker Road >>Latham, NY 12110 >>(518) 738-0389 >> >> >>-Original Message- >>From: >>framers-bounces+dominick_deflorio=plugpower.com at lists.frameusers.com >>[mailto:framers- >>bounces+dominick_deflorio=plugpower.com at lists.frameusers.com] On >>Behalf Of pearlrosenberg at nc.rr.com >>Sent: Thursday, December 08, 2005 10:25 AM >>To: Peter Gold >>Cc: framers at lists.frameusers.com >>Subject: Re: Can't Open a FM File >> >>Unfortunately this doesn't work either. I guess I'm going to have >>to try >>to pull this info out of my memory and rewrite the chap again. >> >>- Original Message - >>From: Peter Gold >>Date: Thursday, December 8, 2005 9:41 am >>Subject: Re: Can't Open a FM File >> >> >> >>>Hi, Pearl: >>> >>>It's more likely a corrupt file than a memory issue. >>> >>>Have you tried the "open heroic" method? In FM, tap and rekease >>> >>> >>these >> >> >>>keys in sequence: >>> >>>Escape >>>lowercase o >>>uppercase H >>> >>>Then select the file in the Open dialog box. If it opens >>> >>> >>successfully, >> >> >>>save it immediately to a new name. >>> >>>At 9:29 AM -0500 12/8/05, pearlrosenberg at nc.rr.com wrote: >>> >>> Hi Framers, FM 7.0p578 Windows XP Professional 512 MB RAM I hope somebody can help me open this file. When I try to open >>it, FM >> >> >> tells me I do not have enough memory. The file is a little >>under 2.7 >> >> MB, and there are larger FM files in the book >>>that FM >>> >>> does open. I've tried closing everything and rebooting and then opening only that file, but I get the same message. >>>-- >>> >>>Regards, >>> >>>Peter Gold >>> >>> >>> >___peter at knowhowpro.com > > >>_ >> >> >>>KnowHow ProServices >>> >>>http://www.knowhowpro.com >>> >>>612.823.7113 >>> >>> >>> >>___ >> >> >>You are currently subscribed to Framers as >>dominick_deflorio at plugpower.com. >> >>To unsubscribe send a blank email to >>framers-unsubscribe at lists.frameusers.com >>or visit >> >> >> >http://lists.frameusers.com/mailman/options/framers/dominick_deflorio% >40 > > >>plugpower.com >> >>Send administrative questions to lisa at frameusers.com. Visit >>http://www.frameusers.com/ for more resources and info. >> >> >> >___ > > >You are currently subscribed to Framers as bob at technicalpublishing.com. > >To unsubscribe send a blank email to >framers-unsubscribe at lists.frameusers.com >or visit >http://lists.frameusers.com/mailman/options/framers/bob%40technicalpublishing.com > >Send administrative questions to lisa at frameusers.com. Visit >http://www.frameusers.com/ for more resources and info. > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- next part -- An HTML attachment was scrubbed... URL: http://lists.frameusers.com/pipermail/framers/attachments/20051208/036c8f92/attachment.html
Keeping track of graphics
We reference all graphics into our documents. Currently we have a couple of thousand graphics stored centrally in the same folder location. While it can be a bit cumbersome to maintain that many graphics in the same folder, it ends up helping us in the long run because if a graphic is updated, it gets updated in *all* locations where it is used. Previously we had project-specific graphic folders, and we found that the same graphic might be updated for one manual, but not for another. We avoid naming files by document name or figure number because of the reasons Bob Kern mentioned (if you insert one in the middle, what happens to the numbering?). Also, most graphics are used in multiple locations, such as in the User Guide and in the Maintenance Manuals, so the fig. numbering really didn't apply for all uses. Instead, we set up a naming scheme that incorporates the product/s the graphic is used for and a pre-defined set of procedural/descriptive words. It took some time on the front end for our graphics team to set this up, but it seems to be working pretty well for the most part. Also, if links are broken, there is only one folder to point to for updating the path. -Carla cmartinek at zebra.com - CONFIDENTIAL- This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.
RE: Keeping track of graphics
I use a mixed method, but reference *all* my graphics. All scaps (screen captures) are in PNG format. I have a Directory tree like so: | -- || | | Pix P1P2Help | | ---- | || | P1_Only P2_Only P1_Help P2_Help NOTES: P1, P2 ... Have the FM files in them Pix has all the images except product-specific ones. I also use a naming pattern: but_ (scap of graphic button) btxt_ (scap of text button) dlg__ (scap of dialog -- with feature selected if required) dtl_ (scap of detail -- usually just a part of a screen.) emess_(scap of message dialog) ill_ (externally created line drawing, flowchart, etc.) pic_ (scap of a displayed function; for example the chart of a stock) menu_(scap of menu) rmenu_ (scap of right-click menu) tbar_ (scap of toolbar) wiz__P (scap of wizard page 1-n) This makes themn easy to sort/locate. For ease of use, the product specific versions are all prefixed by a 3-character code and an underscore (example: PRO_dlg_YAxis_Props_Grid.png = Professional version, Y-axis Properties dialog, Grid tab ) I also have a number of naming conventions that are peculiar to this particular product interface (candlestick, sample, and others) Grant -Original Message- From: Peter Gold Sent: Thursday, December 08, 2005 10:40 AM To: Martinek, Carla Cc: framers@lists.frameusers.com Subject: RE: Keeping track of graphics Carla's point about using one graphic for all linked uses is the simplest. However, the single central folder of all graphics could be confusing. Has anyone successfully employed operating system links, aliases, or shortcuts in project-specific graphics folders for this purpose? The idea is that you can have project-specific directory structures that only contain links to the source graphics that are stored in a central location. Each project's graphics directory contains only the project's graphic links. FM files in each project refer to the link, not to the source. The advantages are fewer graphics (links) to manage for each project, and a single graphic source for multiple uses. The disadvantage is setting it up and retraining authors to use the new approach. I know that unix links are reliable, and that the reliable Macintosh aliases are not an option past FM 7.0. Is anyone using Windows shortcuts? Regards, Peter Gold KnowHow ProServices [EMAIL PROTECTED] ___ You are currently subscribed to Framers as [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: Keeping track of graphics
At 11:49 am -0600 8/12/05, Peter Gold wrote: >Hi, Steve: > >Thanks for the feedback. Do you think there was a problem with Classic's >ability to handle the length of the filename or pathname? No, I don't think so, as the folder concerned was just called 'Graphics' ;-) I expected it to work, but it didn't. Surprise. Ah, I see what you mean... the combined length of the pathname might have been too long. Er, ok - will run simple test now... no, it doesn't work even when the combined path lengths come nowhere near the 31 character limit. FrameMake doesn't want to follow an alias to a graphics folder that has the same name as the original. However, once you've told it to use the alias and chosen the 'update document to use new path', all is well, and remains so. I realise I'm not being as clear as I might here: what is happening is that FrameMaker, after using an actual folder to source graphics, cannot identify an alias to that folder as being the same thing until it's told to. After that, it uses the alias ok. Sorry if I confused anyone earlier. -- Steve ___ You are currently subscribed to Framers as [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: Keeping track of graphics
At 11:39 am -0600 8/12/05, Peter Gold wrote: >Has anyone successfully employed operating system links, aliases, or shortcuts >in project-specific graphics folders for this purpose? The idea is that you >can have project-specific directory structures that only contain links to the >source graphics that are stored in a central location. Each project's graphics >directory contains only the project's graphic links. FM files in each project >refer to the link, not to the source. I tried alising a graphic folder within a book folder in FrameMaker 6 on Mac, but FrameMaker could not follow the link. -- Steve ___ You are currently subscribed to Framers as [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: Keeping track of graphics
Hi, Steve: Thanks for the feedback. Do you think there was a problem with Classic's ability to handle the length of the filename or pathname? Regards, Peter Gold KnowHow ProServices At 5:44 PM + 12/8/05, Steve Rickaby wrote: At 11:39 am -0600 8/12/05, Peter Gold wrote: Has anyone successfully employed operating system links, aliases, or shortcuts in project-specific graphics folders for this purpose? The idea is that you can have project-specific directory structures that only contain links to the source graphics that are stored in a central location. Each project's graphics directory contains only the project's graphic links. FM files in each project refer to the link, not to the source. I tried alising a graphic folder within a book folder in FrameMaker 6 on Mac, but FrameMaker could not follow the link. -- Steve ___ You are currently subscribed to Framers as [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: Keeping track of graphics
Carla's point about using one graphic for all linked uses is the simplest. However, the single central folder of all graphics could be confusing. Has anyone successfully employed operating system links, aliases, or shortcuts in project-specific graphics folders for this purpose? The idea is that you can have project-specific directory structures that only contain links to the source graphics that are stored in a central location. Each project's graphics directory contains only the project's graphic links. FM files in each project refer to the link, not to the source. The advantages are fewer graphics (links) to manage for each project, and a single graphic source for multiple uses. The disadvantage is setting it up and retraining authors to use the new approach. I know that unix links are reliable, and that the reliable Macintosh aliases are not an option past FM 7.0. Is anyone using Windows shortcuts? Regards, Peter Gold KnowHow ProServices [EMAIL PROTECTED] At 11:09 AM -0600 12/8/05, Martinek, Carla wrote: We reference all graphics into our documents. Currently we have a couple of thousand graphics stored centrally in the same folder location. While it can be a bit cumbersome to maintain that many graphics in the same folder, it ends up helping us in the long run because if a graphic is updated, it gets updated in *all* locations where it is used. Previously we had project-specific graphic folders, and we found that the same graphic might be updated for one manual, but not for another. ___ You are currently subscribed to Framers as [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: Keeping track of graphics
We reference all graphics into our documents. Currently we have a couple of thousand graphics stored centrally in the same folder location. While it can be a bit cumbersome to maintain that many graphics in the same folder, it ends up helping us in the long run because if a graphic is updated, it gets updated in *all* locations where it is used. Previously we had project-specific graphic folders, and we found that the same graphic might be updated for one manual, but not for another. We avoid naming files by document name or figure number because of the reasons Bob Kern mentioned (if you insert one in the middle, what happens to the numbering?). Also, most graphics are used in multiple locations, such as in the User Guide and in the Maintenance Manuals, so the fig. numbering really didn't apply for all uses. Instead, we set up a naming scheme that incorporates the product/s the graphic is used for and a pre-defined set of procedural/descriptive words. It took some time on the front end for our graphics team to set this up, but it seems to be working pretty well for the most part. Also, if links are broken, there is only one folder to point to for updating the path. -Carla [EMAIL PROTECTED] - CONFIDENTIAL- This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email. ___ You are currently subscribed to Framers as [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.
Keeping track of graphics
Pearl, We only reference graphics and don't have any trouble keeping track of them (well, mostly no trouble). We name graphics according to their figure number or use and UNF for un-numbered graphics. The rub comes when an author inserts a figure and all the figure numbers in the book change --- you end up with actual figure numbers being different than the figure number in the book, unless you renumber. Our books are done by chapter, so the quantity of graphics is usually small enough that we renumber to keep things in sync. If the author adds a graphic its not as bad: you just add an alpha to the numbering scheme for the graphic (UNF1-1, UNF1-1b, UNF 1-2). -bob Robert Kern President, TIPS Technical Publishing, Inc. 108 E. Main Street, Suite 4 Carrboro, NC 27510 www.technicalpublishing.com [EMAIL PROTECTED] 919-933-2629 phone and fax [EMAIL PROTECTED] wrote: Hi Dominick, I do not reference my graphics, but this may be a good reason to do so. Altho having the graphics in the files makes them larger, I also thought it would be easier to manage the book without a directory of graphics. I'd be interested to hear from those of you who reference graphics about how hard it is (or isn't) to keep track of the graphic files. Pearl Rosenberg TeleHealth Services - Original Message - From: "DeFlorio, Dominick" <[EMAIL PROTECTED]> Date: Thursday, December 8, 2005 10:28 am Subject: RE: Can't Open a FM File If it is hanging-up on a graphic, and you reference your graphics, try renaming the graphics folder. If the file is not corrupt, Frame shouldopen the file and issue an error message. Dominick A. DeFlorio Senior Technical Writer Plug Power, Inc. 968 Albany-Shaker Road Latham, NY 12110 (518) 738-0389 -Original Message- From: [EMAIL PROTECTED] [mailto:framers- [EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, December 08, 2005 10:25 AM To: Peter Gold Cc: framers@lists.frameusers.com Subject: Re: Can't Open a FM File Unfortunately this doesn't work either. I guess I'm going to have to try to pull this info out of my memory and rewrite the chap again. - Original Message - From: Peter Gold <[EMAIL PROTECTED]> Date: Thursday, December 8, 2005 9:41 am Subject: Re: Can't Open a FM File Hi, Pearl: It's more likely a corrupt file than a memory issue. Have you tried the "open heroic" method? In FM, tap and rekease these keys in sequence: Escape lowercase o uppercase H Then select the file in the Open dialog box. If it opens successfully, save it immediately to a new name. At 9:29 AM -0500 12/8/05, [EMAIL PROTECTED] wrote: Hi Framers, FM 7.0p578 Windows XP Professional 512 MB RAM I hope somebody can help me open this file. When I try to open it, FM tells me I do not have enough memory. The file is a little under 2.7 MB, and there are larger FM files in the book that FM does open. I've tried closing everything and rebooting and then opening only that file, but I get the same message. -- Regards, Peter Gold [EMAIL PROTECTED] _ KnowHow ProServices http://www.knowhowpro.com 612.823.7113 ___ You are currently subscribed to Framers as [EMAIL PROTECTED]. To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/dominick_deflorio% 40 plugpower.com Send administrative questions to [EMAIL PROTECTED]. Visit http://www.frameusers.com/ for more resources and info. ___ You are currently subscribed to Framers as [EMAIL PROTECTED]. To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/bob%40technicalpublishing.com Send administrative questions to [EMAIL PROTECTED]. Visit http://www.frameusers.com/ for more resources and info. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ You are currently subscribed to Framers as [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.
