Re: [Framers] ANN: Impromptu Anti-Webinar: Using FrameSLT to Cleanup Structured Docs

2017-05-18 Thread Rick Quatro
I will have some open slots for this webinar starting at 2:00 pm EDT, but I
want to make sure that those that responded get a spot. I am using
GoToMeeting, which as a 26 attendee limit. So as soon as the meeting starts
and those that responded join, I will post the meeting link on the list.
Feel free to join in!

 

Rick Quatro

Carmen Publishing Inc.

r...@frameexpert.com

585-366-4017

 

 

___

This message is from the Framers mailing list

Send messages to framers@lists.frameusers.com
Visit the list's homepage at  http://www.frameusers.com
Archives located at http://www.mail-archive.com/framers%40lists.frameusers.com/
Subscribe and unsubscribe at 
http://lists.frameusers.com/listinfo.cgi/framers-frameusers.com
Send administrative questions to listad...@frameusers.com


Re: [Framers] ANN: Impromptu Anti-Webinar: Using FrameSLT to Cleanup Structured Docs

2017-05-18 Thread Bhavna Raghwani
Hi Rick,

This sounds great. I would like to attend it.
Regards,
Bhavna

On 18-May-2017 19:44, "Rick Quatro" <r...@rickquatro.com> wrote:

> Hi Framers,
>
>
>
> If you are using conversion tables to convert unstructured FrameMaker
> documents to structured FrameMaker, you know that conversion tables only
> get
> you part of the way to valid XML. Cleaning up the last 10-20% can be slow
> and tedious. Enter FrameSLT, Russ Ward's ingenious FrameMaker plugin that
> uses XPath and a simple, but powerful scripting language that can help
> automate the cleanup of structured documents.
>
>
>
> I am going to host a short webinar to introduce FrameSLT and how I used it
> to solve a simple structured cleanup problem for a client. The webinar will
> be at 2:00 pm EDT this afternoon. Please email me if you want to attend and
> I will send you an invitation.
>
>
>
> Remember, an anti-webinar means no sponsors, no boring slides, or
> promotional fluff, just simple demonstrations from the trenches. Email me
> as
> soon as possible and I will send you an invite.
>
>
>
> Rick
>
>
>
> Rick Quatro
>
> Carmen Publishing Inc.
>
> r...@frameexpert.com
>
> 585-366-4017
>
>
>
>
>
>
>
>
>
> ___
>
> This message is from the Framers mailing list
>
> Send messages to framers@lists.frameusers.com
> Visit the list's homepage at  http://www.frameusers.com
> Archives located at http://www.mail-archive.com/
> framers%40lists.frameusers.com/
> Subscribe and unsubscribe at http://lists.frameusers.com/
> listinfo.cgi/framers-frameusers.com
> Send administrative questions to listad...@frameusers.com
>
___

This message is from the Framers mailing list

Send messages to framers@lists.frameusers.com
Visit the list's homepage at  http://www.frameusers.com
Archives located at http://www.mail-archive.com/framers%40lists.frameusers.com/
Subscribe and unsubscribe at 
http://lists.frameusers.com/listinfo.cgi/framers-frameusers.com
Send administrative questions to listad...@frameusers.com


[Framers] ANN: Impromptu Anti-Webinar: Using FrameSLT to Cleanup Structured Docs

2017-05-18 Thread Rick Quatro
Hi Framers,

 

If you are using conversion tables to convert unstructured FrameMaker
documents to structured FrameMaker, you know that conversion tables only get
you part of the way to valid XML. Cleaning up the last 10-20% can be slow
and tedious. Enter FrameSLT, Russ Ward's ingenious FrameMaker plugin that
uses XPath and a simple, but powerful scripting language that can help
automate the cleanup of structured documents.

 

I am going to host a short webinar to introduce FrameSLT and how I used it
to solve a simple structured cleanup problem for a client. The webinar will
be at 2:00 pm EDT this afternoon. Please email me if you want to attend and
I will send you an invitation.

 

Remember, an anti-webinar means no sponsors, no boring slides, or
promotional fluff, just simple demonstrations from the trenches. Email me as
soon as possible and I will send you an invite. 

 

Rick

 

Rick Quatro

Carmen Publishing Inc.

r...@frameexpert.com

585-366-4017

 

 

 

 

___

This message is from the Framers mailing list

Send messages to framers@lists.frameusers.com
Visit the list's homepage at  http://www.frameusers.com
Archives located at http://www.mail-archive.com/framers%40lists.frameusers.com/
Subscribe and unsubscribe at 
http://lists.frameusers.com/listinfo.cgi/framers-frameusers.com
Send administrative questions to listad...@frameusers.com


Possible Solution for Color Definition Cleanup

2010-01-16 Thread Orly Zimmerman
HI Fred,
We found that if you save the file as MIF and open in FM7 that you can delete 
these unwanted  colors in the MIF file.But if you're using conditional tags, in 
FM8, the mixed tags will give mixed colors. I'm just hoping I never find two 
colors that mix to give white :)
BTW, this is true also with the Deleted, Inserted  and Hidden FM tags that FM 
gives the file when saving as FM7 and then re-opening in FM8 (they are used 
even if you don't use track changes) - you get some funny tags that you don't 
see in your conditional text dialog box, but do show on the bottom of the 
screen (where tag names are shown). This usually happens when the engineer used 
all tags for some text except his/her product tag. It can get weird in some 
places. I've written a bug about it to Adobe, but haven't seen any response.
Orly.

Orly Zimmerman
Technical Writer
CP Documentation
Marvell Israel - Petach Tikva

___


You are currently subscribed to Framers as arch...@mail-archive.com.

Send list messages to fram...@lists.frameusers.com.

To unsubscribe send a blank email to 
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

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


Possible Solution for Color Definition Cleanup

2010-01-16 Thread Orly Zimmerman
HI Fred,
We found that if you save the file as MIF and open in FM7 that you can delete 
these unwanted  colors in the MIF file.But if you're using conditional tags, in 
FM8, the mixed tags will give mixed colors. I'm just hoping I never find two 
colors that mix to give white :)
BTW, this is true also with the Deleted, Inserted  and Hidden FM tags that FM 
gives the file when saving as FM7 and then re-opening in FM8 (they are used 
even if you don't use track changes) - you get some funny tags that you don't 
see in your conditional text dialog box, but do show on the bottom of the 
screen (where tag names are shown). This usually happens when the engineer used 
all tags for some text except his/her product tag. It can get weird in some 
places. I've written a bug about it to Adobe, but haven't seen any response.
Orly.

Orly Zimmerman
Technical Writer
CP Documentation
Marvell Israel - Petach Tikva



RE: Possible Solution for Color Definition Cleanup

2010-01-15 Thread Pinkham, Jim
Interesting, Fred. Thanks for adding to our store of knowledge on this.



From: Fred Ridder [mailto:docu...@hotmail.com] 
Sent: Thursday, January 14, 2010 4:29 PM
To: Pinkham, Jim; framers@lists.frameusers.com
Subject: RE: Possible Solution for Color Definition Cleanup


Jim Pinkham wrote:

 However, part of my clean-up process also includes a Wash All Files
in
 Book via MIF step. I did that first and then repeated my effort to
 delete the cantankerous color definitions using Toolbox - Format -
 Delete All Unused Color Definitions. They all disappeared without a
 further squeal of protest.
 
 I haven't attempted to replicate this on any other files yet, though I
 most certainly will be doing so in the not-too-distant future. I pass
 this along, though, in the hopes it may prove to be a solution for
 others in a similar situation. 

Yes, washing via MIF is the standard solution for removing spurious RGB
color definitions. But you'll sometimes find that it won't remove *all*
of them from a given file, and that always seems to relate to graphics.
I've got a handful of files where I've just learned to live with two or
three RGB color definitions.
 
But recently I discovered a new type of autogenerated color definitions
in some of my files (FM8) that cannot be purged a MIF wash. These show
up with names like fm_gen_106529 and fm_gen_98334. Some files had two or
three of these, and one had over 40. When you selected any of these
colors from the list, you'd see that the Add and Delete buttons were
grayed out. Washing via MIF wouldn't remove any of them. I whent into
the MIF with a text editor, and found that each color defintion had the
line ColorAttribute ColorIsReserved, which is what made them
undeletable. But I still had no clue where they were coming from.
 
Finally I realized that the files that had the largest numbers of these
spurious defintions were all owned by a writer who likes to manually
highlight text in color for her own purposes in addition to applying the
dozen or so defined conditions that we use to tag three different types
of comments, plus changes, additions, deletions, and content to be
reviewed. What I realized at that point was that these reserved colors
are ones that FrameMaker is defining on the fly to paint
multiply-conditionalized text with the average of the color definitions
for all of the overlapping conditions. 
 
So now I know why they exist, but I still haven't found any way of
making them go away other than (a) manually editing the MIF to delete
the definitions, or (b) cleaning up the overlapping conditions and
importing the content into a clean template. Maybe the all overlaping
conditions indicated in magenta scheme used in older versions of
FrameMaker wasn't so bad after all...
 
-Fred Ridder 

___


You are currently subscribed to Framers as arch...@mail-archive.com.

Send list messages to fram...@lists.frameusers.com.

To unsubscribe send a blank email to 
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

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


Possible Solution for Color Definition Cleanup

2010-01-15 Thread Pinkham, Jim
Interesting, Fred. Thanks for adding to our store of knowledge on this.



From: Fred Ridder [mailto:docu...@hotmail.com] 
Sent: Thursday, January 14, 2010 4:29 PM
To: Pinkham, Jim; framers at lists.frameusers.com
Subject: RE: Possible Solution for Color Definition Cleanup


Jim Pinkham wrote:

> However, part of my clean-up process also includes a "Wash All Files
in
> Book via MIF" step. I did that first and then repeated my effort to
> delete the cantankerous color definitions using Toolbox - Format -
> Delete All Unused Color Definitions. They all disappeared without a
> further squeal of protest.
> 
> I haven't attempted to replicate this on any other files yet, though I
> most certainly will be doing so in the not-too-distant future. I pass
> this along, though, in the hopes it may prove to be a solution for
> others in a similar situation. 

Yes, washing via MIF is the standard solution for removing spurious RGB
color definitions. But you'll sometimes find that it won't remove *all*
of them from a given file, and that always seems to relate to graphics.
I've got a handful of files where I've just learned to live with two or
three RGB color definitions.

But recently I discovered a new type of autogenerated color definitions
in some of my files (FM8) that cannot be purged a MIF wash. These show
up with names like fm_gen_106529 and fm_gen_98334. Some files had two or
three of these, and one had over 40. When you selected any of these
colors from the list, you'd see that the Add and Delete buttons were
grayed out. Washing via MIF wouldn't remove any of them. I whent into
the MIF with a text editor, and found that each color defintion had the
line , which is what made them
undeletable. But I still had no clue where they were coming from.

Finally I realized that the files that had the largest numbers of these
spurious defintions were all "owned" by a writer who likes to manually
highlight text in color for her own purposes in addition to applying the
dozen or so defined conditions that we use to tag three different types
of comments, plus changes, additions, deletions, and content to be
reviewed. What I realized at that point was that these reserved colors
are ones that FrameMaker is defining on the fly to paint
multiply-conditionalized text with the average of the color definitions
for all of the overlapping conditions. 

So now I know why they exist, but I still haven't found any way of
making them go away other than (a) manually editing the MIF to delete
the definitions, or (b) cleaning up the overlapping conditions and
importing the content into a clean template. Maybe the "all overlaping
conditions indicated in magenta" scheme used in older versions of
FrameMaker wasn't so bad after all...

-Fred Ridder 



Possible Solution for Color Definition Cleanup

2010-01-14 Thread Pinkham, Jim
Interesting situation today, folks: I was working on several books built
from an old, cluttered template and running into the zillion color
definitions with RGB numbers, and I was running into them on almost
every file. Recently, I've been circumventing this problem, when the
definitions won't delete nicely, by creating a new file from our clean,
new template and pasting the old content into the new document . Presto!
The bad color definitions don't carry over, so all is well.
 
I had 51 chapters from four different books in the master book I was
working on, so I thought I'd check the Web again and see if, on the
archives or elsewhere, there was an approach less tedious and
labor-intensive. I stumbled across the following from Adobe: Color
Definition in a FrameMaker Document Can't Be Deleted and Has a Strange
Name http://kb2.adobe.com/cps/323/323771.html .  Going at the MIF as
described in the Adobe item sounds plausible, but again it did not seem
to reasonably well address the need for handling that many files
efficiently.
 
However, part of my clean-up process also includes a Wash All Files in
Book via MIF step. I did that first and then repeated my effort to
delete the cantankerous color definitions using Toolbox - Format -
Delete All Unused Color Definitions. They all disappeared without a
further squeal of protest.
 
I haven't attempted to replicate this on any other files yet, though I
most certainly will be doing so in the not-too-distant future. I pass
this along, though, in the hopes it may prove to be a solution for
others in a similar situation. 
 
- Jim

___


You are currently subscribed to Framers as arch...@mail-archive.com.

Send list messages to fram...@lists.frameusers.com.

To unsubscribe send a blank email to 
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

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


Re: Possible Solution for Color Definition Cleanup

2010-01-14 Thread Art Campbell
If you have FrameScript, I believe they include a sample/demo script
that purges the colors catalog...

Art Campbell
   art.campb...@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



On Thu, Jan 14, 2010 at 4:05 PM, Pinkham, Jim jim.pink...@voith.com wrote:
 Interesting situation today, folks: I was working on several books built
 from an old, cluttered template and running into the zillion color
 definitions with RGB numbers, and I was running into them on almost
 every file. Recently, I've been circumventing this problem, when the
 definitions won't delete nicely, by creating a new file from our clean,
 new template and pasting the old content into the new document . Presto!
 The bad color definitions don't carry over, so all is well.

 I had 51 chapters from four different books in the master book I was
 working on, so I thought I'd check the Web again and see if, on the
 archives or elsewhere, there was an approach less tedious and
 labor-intensive. I stumbled across the following from Adobe: Color
 Definition in a FrameMaker Document Can't Be Deleted and Has a Strange
 Name http://kb2.adobe.com/cps/323/323771.html .  Going at the MIF as
 described in the Adobe item sounds plausible, but again it did not seem
 to reasonably well address the need for handling that many files
 efficiently.

 However, part of my clean-up process also includes a Wash All Files in
 Book via MIF step. I did that first and then repeated my effort to
 delete the cantankerous color definitions using Toolbox - Format -
 Delete All Unused Color Definitions. They all disappeared without a
 further squeal of protest.

 I haven't attempted to replicate this on any other files yet, though I
 most certainly will be doing so in the not-too-distant future. I pass
 this along, though, in the hopes it may prove to be a solution for
 others in a similar situation.

 - Jim

 ___


 You are currently subscribed to Framers as art.campb...@gmail.com.

 Send list messages to fram...@lists.frameusers.com.

 To unsubscribe send a blank email to
 framers-unsubscr...@lists.frameusers.com
 or visit 
 http://lists.frameusers.com/mailman/options/framers/art.campbell%40gmail.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 fram...@lists.frameusers.com.

To unsubscribe send a blank email to 
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

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


Re: Possible Solution for Color Definition Cleanup

2010-01-14 Thread Art Campbell
Just to follow up, the script isn't in the FrameScript version for FM9...

There is a version in Rick Quatro's set of web scripts, but I don't
know if it's available separately or not.
http://www.frameexpert.com/scripts/superwebbundle.htm


Art Campbell
   art.campb...@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



On Thu, Jan 14, 2010 at 4:14 PM, Art Campbell art.campb...@gmail.com wrote:
 If you have FrameScript, I believe they include a sample/demo script
 that purges the colors catalog...

 Art Campbell
               art.campb...@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



 On Thu, Jan 14, 2010 at 4:05 PM, Pinkham, Jim jim.pink...@voith.com wrote:
 Interesting situation today, folks: I was working on several books built
 from an old, cluttered template and running into the zillion color
 definitions with RGB numbers, and I was running into them on almost
 every file. Recently, I've been circumventing this problem, when the
 definitions won't delete nicely, by creating a new file from our clean,
 new template and pasting the old content into the new document . Presto!
 The bad color definitions don't carry over, so all is well.

 I had 51 chapters from four different books in the master book I was
 working on, so I thought I'd check the Web again and see if, on the
 archives or elsewhere, there was an approach less tedious and
 labor-intensive. I stumbled across the following from Adobe: Color
 Definition in a FrameMaker Document Can't Be Deleted and Has a Strange
 Name http://kb2.adobe.com/cps/323/323771.html .  Going at the MIF as
 described in the Adobe item sounds plausible, but again it did not seem
 to reasonably well address the need for handling that many files
 efficiently.

 However, part of my clean-up process also includes a Wash All Files in
 Book via MIF step. I did that first and then repeated my effort to
 delete the cantankerous color definitions using Toolbox - Format -
 Delete All Unused Color Definitions. They all disappeared without a
 further squeal of protest.

 I haven't attempted to replicate this on any other files yet, though I
 most certainly will be doing so in the not-too-distant future. I pass
 this along, though, in the hopes it may prove to be a solution for
 others in a similar situation.

 - Jim

 ___


 You are currently subscribed to Framers as art.campb...@gmail.com.

 Send list messages to fram...@lists.frameusers.com.

 To unsubscribe send a blank email to
 framers-unsubscr...@lists.frameusers.com
 or visit 
 http://lists.frameusers.com/mailman/options/framers/art.campbell%40gmail.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 fram...@lists.frameusers.com.

To unsubscribe send a blank email to 
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

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


RE: Possible Solution for Color Definition Cleanup

2010-01-14 Thread Fred Ridder

Jim Pinkham wrote:

 However, part of my clean-up process also includes a Wash All Files in
 Book via MIF step. I did that first and then repeated my effort to
 delete the cantankerous color definitions using Toolbox - Format -
 Delete All Unused Color Definitions. They all disappeared without a
 further squeal of protest.
 
 I haven't attempted to replicate this on any other files yet, though I
 most certainly will be doing so in the not-too-distant future. I pass
 this along, though, in the hopes it may prove to be a solution for
 others in a similar situation. 


Yes, washing via MIF is the standard solution for removing spurious RGB color 
definitions. But you'll sometimes find that it won't remove *all* of them from 
a given file, and that always seems to relate to graphics. I've got a handful 
of files where I've just learned to live with two or three RGB color 
definitions.

 

But recently I discovered a new type of autogenerated color definitions in some 
of my files (FM8) that cannot be purged a MIF wash. These show up with names 
like fm_gen_106529 and fm_gen_98334. Some files had two or three of these, and 
one had over 40. When you selected any of these colors from the list, you'd see 
that the Add and Delete buttons were grayed out. Washing via MIF wouldn't 
remove any of them. I whent into the MIF with a text editor, and found that 
each color defintion had the line ColorAttribute ColorIsReserved, which is 
what made them undeletable. But I still had no clue where they were coming from.

 

Finally I realized that the files that had the largest numbers of these 
spurious defintions were all owned by a writer who likes to manually 
highlight text in color for her own purposes in addition to applying the dozen 
or so defined conditions that we use to tag three different types of comments, 
plus changes, additions, deletions, and content to be reviewed. What I realized 
at that point was that these reserved colors are ones that FrameMaker is 
defining on the fly to paint multiply-conditionalized text with the average of 
the color definitions for all of the overlapping conditions. 

 

So now I know why they exist, but I still haven't found any way of making them 
go away other than (a) manually editing the MIF to delete the definitions, or 
(b) cleaning up the overlapping conditions and importing the content into a 
clean template. Maybe the all overlaping conditions indicated in magenta 
scheme used in older versions of FrameMaker wasn't so bad after all...

 

-Fred Ridder 
  
___


You are currently subscribed to Framers as arch...@mail-archive.com.

Send list messages to fram...@lists.frameusers.com.

To unsubscribe send a blank email to 
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

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


Possible Solution for Color Definition Cleanup

2010-01-14 Thread Pinkham, Jim
Interesting situation today, folks: I was working on several books built
from an old, cluttered template and running into the zillion color
definitions with RGB numbers, and I was running into them on almost
every file. Recently, I've been circumventing this problem, when the
definitions won't delete nicely, by creating a new file from our clean,
new template and pasting the old content into the new document . Presto!
The bad color definitions don't carry over, so all is well.

I had 51 chapters from four different books in the "master book" I was
working on, so I thought I'd check the Web again and see if, on the
archives or elsewhere, there was an approach less tedious and
labor-intensive. I stumbled across the following from Adobe: "Color
Definition in a FrameMaker Document Can't Be Deleted and Has a Strange
Name  ".  Going at the MIF as
described in the Adobe item sounds plausible, but again it did not seem
to reasonably well address the need for handling that many files
efficiently.

However, part of my clean-up process also includes a "Wash All Files in
Book via MIF" step. I did that first and then repeated my effort to
delete the cantankerous color definitions using Toolbox - Format -
Delete All Unused Color Definitions. They all disappeared without a
further squeal of protest.

I haven't attempted to replicate this on any other files yet, though I
most certainly will be doing so in the not-too-distant future. I pass
this along, though, in the hopes it may prove to be a solution for
others in a similar situation. 

- Jim



Possible Solution for Color Definition Cleanup

2010-01-14 Thread Art Campbell
If you have FrameScript, I believe they include a sample/demo script
that purges the colors catalog...

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



On Thu, Jan 14, 2010 at 4:05 PM, Pinkham, Jim  wrote:
> Interesting situation today, folks: I was working on several books built
> from an old, cluttered template and running into the zillion color
> definitions with RGB numbers, and I was running into them on almost
> every file. Recently, I've been circumventing this problem, when the
> definitions won't delete nicely, by creating a new file from our clean,
> new template and pasting the old content into the new document . Presto!
> The bad color definitions don't carry over, so all is well.
>
> I had 51 chapters from four different books in the "master book" I was
> working on, so I thought I'd check the Web again and see if, on the
> archives or elsewhere, there was an approach less tedious and
> labor-intensive. I stumbled across the following from Adobe: "Color
> Definition in a FrameMaker Document Can't Be Deleted and Has a Strange
> Name  ". ?Going at the MIF as
> described in the Adobe item sounds plausible, but again it did not seem
> to reasonably well address the need for handling that many files
> efficiently.
>
> However, part of my clean-up process also includes a "Wash All Files in
> Book via MIF" step. I did that first and then repeated my effort to
> delete the cantankerous color definitions using Toolbox - Format -
> Delete All Unused Color Definitions. They all disappeared without a
> further squeal of protest.
>
> I haven't attempted to replicate this on any other files yet, though I
> most certainly will be doing so in the not-too-distant future. I pass
> this along, though, in the hopes it may prove to be a solution for
> others in a similar situation.
>
> - Jim
>
> ___
>
>
> You are currently subscribed to Framers as art.campbell at gmail.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/art.campbell%40gmail.com
>
> Send administrative questions to listadmin at frameusers.com. Visit
> http://www.frameusers.com/ for more resources and info.
>


Possible Solution for Color Definition Cleanup

2010-01-14 Thread Art Campbell
Just to follow up, the script isn't in the FrameScript version for FM9...

There is a version in Rick Quatro's set of web scripts, but I don't
know if it's available separately or not.
http://www.frameexpert.com/scripts/superwebbundle.htm


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



On Thu, Jan 14, 2010 at 4:14 PM, Art Campbell  wrote:
> If you have FrameScript, I believe they include a sample/demo script
> that purges the colors catalog...
>
> 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
>
>
>
> On Thu, Jan 14, 2010 at 4:05 PM, Pinkham, Jim  
> wrote:
>> Interesting situation today, folks: I was working on several books built
>> from an old, cluttered template and running into the zillion color
>> definitions with RGB numbers, and I was running into them on almost
>> every file. Recently, I've been circumventing this problem, when the
>> definitions won't delete nicely, by creating a new file from our clean,
>> new template and pasting the old content into the new document . Presto!
>> The bad color definitions don't carry over, so all is well.
>>
>> I had 51 chapters from four different books in the "master book" I was
>> working on, so I thought I'd check the Web again and see if, on the
>> archives or elsewhere, there was an approach less tedious and
>> labor-intensive. I stumbled across the following from Adobe: "Color
>> Definition in a FrameMaker Document Can't Be Deleted and Has a Strange
>> Name  ". ?Going at the MIF as
>> described in the Adobe item sounds plausible, but again it did not seem
>> to reasonably well address the need for handling that many files
>> efficiently.
>>
>> However, part of my clean-up process also includes a "Wash All Files in
>> Book via MIF" step. I did that first and then repeated my effort to
>> delete the cantankerous color definitions using Toolbox - Format -
>> Delete All Unused Color Definitions. They all disappeared without a
>> further squeal of protest.
>>
>> I haven't attempted to replicate this on any other files yet, though I
>> most certainly will be doing so in the not-too-distant future. I pass
>> this along, though, in the hopes it may prove to be a solution for
>> others in a similar situation.
>>
>> - Jim
>>
>> ___
>>
>>
>> You are currently subscribed to Framers as art.campbell at gmail.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/art.campbell%40gmail.com
>>
>> Send administrative questions to listadmin at frameusers.com. Visit
>> http://www.frameusers.com/ for more resources and info.
>>
>


Possible Solution for Color Definition Cleanup

2010-01-14 Thread Fred Ridder

Jim Pinkham wrote:

> However, part of my clean-up process also includes a "Wash All Files in
> Book via MIF" step. I did that first and then repeated my effort to
> delete the cantankerous color definitions using Toolbox - Format -
> Delete All Unused Color Definitions. They all disappeared without a
> further squeal of protest.
> 
> I haven't attempted to replicate this on any other files yet, though I
> most certainly will be doing so in the not-too-distant future. I pass
> this along, though, in the hopes it may prove to be a solution for
> others in a similar situation. 


Yes, washing via MIF is the standard solution for removing spurious RGB color 
definitions. But you'll sometimes find that it won't remove *all* of them from 
a given file, and that always seems to relate to graphics. I've got a handful 
of files where I've just learned to live with two or three RGB color 
definitions.



But recently I discovered a new type of autogenerated color definitions in some 
of my files (FM8) that cannot be purged a MIF wash. These show up with names 
like fm_gen_106529 and fm_gen_98334. Some files had two or three of these, and 
one had over 40. When you selected any of these colors from the list, you'd see 
that the Add and Delete buttons were grayed out. Washing via MIF wouldn't 
remove any of them. I whent into the MIF with a text editor, and found that 
each color defintion had the line , which is 
what made them undeletable. But I still had no clue where they were coming from.



Finally I realized that the files that had the largest numbers of these 
spurious defintions were all "owned" by a writer who likes to manually 
highlight text in color for her own purposes in addition to applying the dozen 
or so defined conditions that we use to tag three different types of comments, 
plus changes, additions, deletions, and content to be reviewed. What I realized 
at that point was that these reserved colors are ones that FrameMaker is 
defining on the fly to paint multiply-conditionalized text with the average of 
the color definitions for all of the overlapping conditions. 



So now I know why they exist, but I still haven't found any way of making them 
go away other than (a) manually editing the MIF to delete the definitions, or 
(b) cleaning up the overlapping conditions and importing the content into a 
clean template. Maybe the "all overlaping conditions indicated in magenta" 
scheme used in older versions of FrameMaker wasn't so bad after all...



-Fred Ridder 



cleanup

2008-02-21 Thread Kelly McDaniel
I have about a dozen books of various ages, authors, formatting, etc.
The tag catalogs are different from file-to-file, and from book-to-book.
I am in the process of fixing this.

 

I want to make all Paragraph catalogs the same within all files. I know
the long ways to do this. Is there a bulk method?

___


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: cleanup

2008-02-21 Thread Art Campbell
You can certainly do it book-to-book.
And you can also add all the component files to a meta-book and update
them all in one pass. However, the FM method doesn't remove the old
tags -- it just updates.

So I'd look at CleanImport, which works with all formats, and also
removes the old ones -- a really nice touch when you're trying to make
things consistent.  from
http://www.electropubs.com/ez_cleanimport3.html

Art

On Thu, Feb 21, 2008 at 3:11 PM, Kelly McDaniel [EMAIL PROTECTED] wrote:
 I have about a dozen books of various ages, authors, formatting, etc.
  The tag catalogs are different from file-to-file, and from book-to-book.
  I am in the process of fixing this.



  I want to make all Paragraph catalogs the same within all files. I know
  the long ways to do this. Is there a bulk method?

  ___


-- 
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.


cleanup

2008-02-21 Thread Kelly McDaniel
I have about a dozen books of various ages, authors, formatting, etc.
The tag catalogs are different from file-to-file, and from book-to-book.
I am in the process of fixing this.



I want to make all Paragraph catalogs the same within all files. I know
the long ways to do this. Is there a bulk method?



cleanup

2008-02-21 Thread Mollye Barrett
In the past I used template mapper but can't seem to find it now.

Mollye

Mollye Barrett
ClearPath, LLC
414-331-1378

> I have about a dozen books of various ages, authors, formatting, etc.
> The tag catalogs are different from file-to-file, and from book-to-book.
> I am in the process of fixing this.
>
>
>
> I want to make all Paragraph catalogs the same within all files. I know
> the long ways to do this. Is there a bulk method?
>
> ___
>
>
> You are currently subscribed to Framers as mollye at clearpath.cc.
>
> 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/mollye%40clearpath.cc
>
> Send administrative questions to listadmin at frameusers.com. Visit
> http://www.frameusers.com/ for more resources and info.
>




cleanup

2008-02-21 Thread Art Campbell
You can certainly do it book-to-book.
And you can also add all the component files to a meta-book and update
them all in one pass. However, the FM method doesn't remove the old
tags -- it just updates.

So I'd look at CleanImport, which works with all formats, and also
removes the old ones -- a really nice touch when you're trying to make
things consistent.  from
http://www.electropubs.com/ez_cleanimport3.html

Art

On Thu, Feb 21, 2008 at 3:11 PM, Kelly McDaniel  
wrote:
> I have about a dozen books of various ages, authors, formatting, etc.
>  The tag catalogs are different from file-to-file, and from book-to-book.
>  I am in the process of fixing this.
>
>
>
>  I want to make all Paragraph catalogs the same within all files. I know
>  the long ways to do this. Is there a bulk method?
>
>  ___
>

-- 
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