Hi, Rene,

I would suggest the same-name issue could be overcome by establishing a
naming convention that indicates the version or date of the graphic in
the file name in cases where it's important that the file name be
unique.

Regarding the second point: Yes, you would create additional copies at
first. Initially, the problem Archive would solve would be locating
those graphic files (which now hide in your network's nooks and crannies
with paths showing only ellipses) and putting them all in one accessible
spot for further action. This is what came to mind when you wrote, "We
really need to simplify and find a way to quickly locate and identify
the graphics files!" After you have your graphics firmly in hand, then
you can define a logical folder structure for their permanent home(s)
that suits your purposes in the future. 

Once you have the actual graphics files in a known and accessible place,
then you could, for instance, copy or move the graphic once to a new
master folder and have all the books that use that graphic in that form
reference the master copy going forward. In other words, you would
create some duplication at the outset (unless you go back and delete the
originals and point them to the new master folder, too). But you also
have a feasible base for single-sourcing repeated graphics in future
iterations of your books.

It can be formidable to retroactively fix an inherited structure that no
longer makes sense or perhaps never really had a clear organizing
principle. But you can begin to tame the tiger from here on out, and
then chunk out fixing the old stuff, if that really has to be done, as
time permits.

HTH,
Jim

________________________________

From: Rene Stephenson [mailto:rinn...@yahoo.com] 
Sent: Wednesday, March 05, 2008 3:22 PM
To: Pinkham, Jim; framers at lists.frameusers.com
Subject: Re: Is there an easy way to manage graphics shared in many FM
files?


We do have the Archive plugin (LOVE IT) and use it for creating a zip
file that we put into our version control and release system. The one
beef I have with it is that whatever date you do the archive becomes the
date for all the files in the archived folder, so if I have several
books with graphic files by the same name, I can't tell which one is
truly the latest file after I use Archive.

I think you lost me a little, though. I  know Archive solves the path
problems when it creates the archive folder containing all the files
necessary to reproduce the project, but in my mind I'm thinking when I
have several books that already share graphics, running this plugin
would create additional copies of those graphics rather than creating
fewer... What am I missing?

Rene





----- Original Message ----
From: "Pinkham, Jim" <jim.pink...@voith.com>
To: Rene Stephenson <rinnie1 at yahoo.com>; framers at lists.frameusers.com
Sent: Wednesday, March 5, 2008 4:07:09 PM
Subject: RE: Is there an easy way to manage graphics shared in many FM
files?

This at least slightly tangential to your question, Rene, but I've found
the Archive plug-in a wonderful tool in pulling graphics and insets in a
book that are scattered hither and yon on the network into a single
folder tied to that book. From there, you can move, copy, or reuse the
graphics in a place or places where you want them to be going forward. 

-----Original Message-----
From: framers-boun...@lists.frameusers.com
[mailto:framers-bounces at lists.frameusers.com] On Behalf Of Rene
Stephenson
Sent: Wednesday, March 05, 2008 1:08 PM
To: framers at lists.frameusers.com
Subject: OT: Is there an easy way to manage graphics shared in many FM
files?

Hi All,

We have a library of a few dozen books (about 10,000 pages), and many of
the files use the same graphics or composites built from shared
graphics. We've run upon a challenge, though, in that things have gotten
complex enough that we can't always use subfolders to group the graphics
in a logical way so that we know where to look to find them. To
complicate matters, we have recently endured several rounds of layoffs
that have rather drastically diminished our team to just me and a
trainer and our boss. :-\  The graphic artist was the last of our
casualties.

I am now discovering how much our artist was keeping in his head. Now, I
know the idea of cataloging or browsing graphics is really probably out
of scope for any desktop publishing application, but when you're dealing
with graphic-intensive books in FM, with so much content to manage...!
We have single-sourced about 75% of the projects, so the text part of
the FM files is in manageable condition, thanks to insets, shared files,
conditional text, variables, and the like. But the graphics...! Egads!
We really need to simplify and find a way to quickly locate and identify
the graphics files!

I'm wondering whether we could use the source graphics rather than the
output files. The source files include CDR, AI, DWG, DXF, and VSD files.
All of those were being output to TIFF or JPG for use in FM. I have
heard that FM is supposed to import CDR files, but using FM 7.2 I
haven't had very good luck (possibly my mistakes).

I'm also thinking about file structure in that right now, we have the
books grouped by product and the output graphics in the product
directories at the same "tree" or path level as the FM files folder for
the product. Aren't there some limitations about how long the path can
be or how many folders up and down the path between the container doc
and the graphic you're inserting that can impact FM ability to display
the images? It seems like about 5 of the ..\..\..\ things in the
referenced file path causes an issue...?

And the other thing that's brewing in my mind is, surely there's some
program somewhere that catalogs graphics of various file formats when
you provide a path or group of paths for a repository...??

Given the tech market and economic rollercoaster of the last few years,
I know I'm not the only writer to find myself in this position. Any
insight that any of you can provide would be greatly appreciated!

Rene L. Stephenson




_______________________________________________


You are currently subscribed to Framers as jim.pinkham at voith.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/jim.pinkham%40voith.
com

Send administrative questions to listadmin at frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.


Reply via email to