inconsistent color definitions

[_aliceqiuwuyan_]

Hi, all,

I have a problem concerning inconsistent color definitions when I print a book file on the Linux system.

The error message says:
Color definition: Color8 is inconsistent

This may relate to the fact that this .fm file is copied from Windows version FrameMaker file.

How can I solve the problem?

Thank you in advance for any help.
Alice

[_Thomas_Michanek_]

The message means that a color named "Color8" is defined in
more than one of the files in the book, and that the definition
differs between the files. This could be highly undesirable if
the color is being used and you are doing color productions.
The remedy is to make all color definitions the same in all
files by importing color definitions to the entire book.
BTW, the message is a warning and should not prevent you from
printing the book.

If you're familiar with the files in the book, and you feel
confident that "Color8" is not used for anything important,
and you're not doing high-quality color productions, then:

1. In the book window, select all the files in the book.
2. In the book windows, select File > Import > Formats
3. Deselect everything except "color definitions"
4. At the top, select the file you copied from Windows in
"import from document"
5. Click "import"
6. Save all files and try printing again.

If you're not familiar with the files and you're not sure if
"Color8" could be used for anything important, you should
either consult with someone who designed the files, or at
least select one of the other files in the book to import
colors from. In this case, find a file in the book that contains
the color "Color8" (use View > Color > Definition). Once you've
found such a file, follow the instructions above and use this
file to import colors from.

Even better is if you have access to a template file for the
book that contains all definitions of formats. Then open that
file in FM and use it to import from.

--
/Thomas Michanek

[HeCK]

I used the same template for every single document in my book. How can it be defined differently? Mine has this for both color 8 & 9. The only color I'm using is defined as blue. There is no instance of two colors being used. The one that lists both colors as inconsistent, only has one instance of non-black text, and that is the blue. Janet, there is no earlier version of these files. These were created from a template, all the same template, and copy and pasted over from the Adobe Acrobat. I have 10 files. Four are throwing this error, with one of them naming 2 colors, as specified above.

I realize that the template may have some problem with color #8. The guy who created these doesn't seem to know much about sensible formatting or naming conventions. He also said that FM doesn't have templates a bare 4 1/2 months ago, then suddenly had templates available a month or so later. The question from me is:

Why is this being thrown as an error in some of the files that are using the blue, but not all of them, given that they are all created with the same template. I'm assuming that it's the hyperlink blue, because there are no other colors in-use in the files. Three other files use the same font definition, but don't have errors.

So, where can we look to find which colors are being used? Mine are: 1 - no error; 2 - no error/no non-black; 3 - no error; 4 - no error; 5 - error; 6 - error; 7 - no error, multiple instances of non-black text; 8 - no error/no non-black; 9 - error for 2 colors, only one instance of non-black; 10 - no error.

I see no logic behind this configuration. The first file created was either 2 or 3. Next was either 3 or 4, then either 4 or 5; 2, 3, and 4 have non-black text. Why would 5 throw and error, if neither 3 nor 4 do. I'm going to delete the color, since it's not in 7, which is an ungodly huge file. We'll see what happens, but your explanations aren't making sense, given what I'm seeing here.

[Jeff_Coatsworth]

As Bob says, they may have snuck in from images being placed in your docs. If importing the correct color definitions into all the "inconsistent" docs doesn't fix it, you might have to go the MIF route to see where the colors are being used.

[HeCK]

Two of these chapters have no graphics.

[FieryPantone]

Watch the log to see which file is flagged as having an inconsistent colour, then open that file. Go to View > Colour > Definitions and try deleting the "inconsistent" colour: if it's used by anything, you'll get a warning.

If you save a problem file as .mif and examine it (carefully, because .mif files can be a bit sensitive) in a text editor, you can search for the string "Color8" and find out exactly where the colour is being used.

[Bob_Niland]

> If you save a problem file as .mif and examine it (carefully, because .mif files can be a bit sensitive) in a text editor, you can search for the string "Color8" and find out exactly where the colour is being used.

That only works in the easy cases. If the named color is coming in with an external object (EPS, DWG, DXF, PDF) the name may or may not appear in the <ColorCatalog> tags, but you won't be able to find it in the main <TextFlow>.

[kmacdowe+brdcom]

Error7103, you are correct, I don't recall ever seeing it in the mif code.

This raises the question then, is it coming from external objects? And if so, why is it always "Color8"? Maybe "Color8" is some kind of catch all?

Today I also was reminded when I look in the Color Definitions, often there is a "Color 8"; with a space that is, in the definition also, that causes no problems. 

[FieryPantone]

So, .eps could occasionally be the culprit! well worth knowing.

[Bob_Niland]

DWGs are a particular nuisance in this regard.

If I import the ACAD 13 stuff common around here (which rarely has more than a few colors used), the Color Definitions dialog instantly gets polluted with a large number of new colors in the name range "RGB 000,000,000" through "RGB 255,255,255".

These names do not appear in the MIF.

They do not go away if the culprit object is deleted.

Delete. Save as .fm binary. Re-open. Still there.

MIF wash: RGB infestation now gone.

Key learning: never import DWGs (or EPSs that are mere re-saves of a DWG - same problem). DXFs probably have the same problem. PDF re-saves don't seem to have the problem.

We routinely post-process DWGs in Illustrator when we need them (remove title blocks, etc.), then saving them as EPS, and this is also deleting that huge list of RGB colors.

[kmacdowe+brdcom]

Thanks Error7103! Perhaps you should change your name to Fix7103 🙂

[FieryPantone]

No risk of .dwg with this client, but (once again) it's good to be aware of this whole area. I'll pay special attention next time I import an .svg derived from Visio … just in case.

.rtf files can bring a lot of baggage with them, of course, but I try to avoid that by tagging the Word source as mml and using .txt instead

N

[kmacdowe+brdcom]

I have seen this error consistantly pop up in Framemaker over many years and many versions. I have never gotten a suitable explanation of why it happens. That said, Niels is correct, remove it. Ha! today is Feb. 1, 2013 and I just got the warning again today. If anyone actaully finds the origin of this erros please share with us. I suspect it may be coming in from imported files but can not confirm this.

[gary.knighting]

Look at the color definition in either the first document in your book, or in the document listed right before the one shown in the error report. In my case, the error report was telling me that the color definition in my introduction chapter (document #2) was a problem. However, I was confused because the color definition was accurate in that one, as it was in all of the subsequent documents. However, when I looked at my title/legal page file (the first document in my book), the RGB color definition numbers had been transposed. Frame assumed the first document was the accurate one and color definitions in subsequent documents should match the first document. Does that make sense? The report is telling you that the document listed is where the color definition defined earlier has changed and not that there is a problem in that particular document. So, trying to delete the color definition in my second document (the one listed on the error report), and then importing color definitions from other files didn't help because the document listed never had the problem in the first place; the problem was in the earlier document. Hope that helps.

JD

[FieryPantone]

Frame assumed the first document was the accurate one and color definitions in subsequent documents should match the first document

It's always seems to me that's how it works, much the same thing as when Frame signals problems with conditions: it's not saying there's a problem with document 2, just that there's a discrepancy between the first place it found something defined and a different definition it's found later – it can be that document 1 is in fact set up just the way you want it.

Time-consuming, but if you start from View > Colour definitions and try deleting colours you're sure you don't want, you'll get a warning "Some items in {file} are assigned the colour {colour}". Save to .mif, find out where the offending colour is assigned, make necessary changes, repeat till done … If/when you get a new warning about "Colour separation out of range", post again here so I can learn from wiser answers.

[gary.knighting]

Thanks for your response Niels. That was my point. Everyone is telling the readers to save their file as .mifs and to delete colors, etc. when all they have to do is look to earlier documents and not the document generating the error. The error report led me to believe that the actual document listed had the issue, so I spent two days trying to figure out where I went wrong with THAT document. Saving to the .mif didn't work, and neither did deleting the color and adding it back in, or any of the other suggestions posted on other forums because the document listed wasn't where the problem was at all. When I went through the first document, I was able to spot and correct the problem in a matter of moments. Therefore, my post was basically geared to those users who are trying everyone's suggestions and missing the entire point of the report.

JD

[HeCK]

I just updated the same book, and received an error message that ALL colors in ALL documents are now magically inconsistent. Again, this includes documents without any pictures. When is Adobe going to fix this issue? I'm now stuck. This document is for work.

[Klaus Göbel]

Hi heather,

I'm just writing a script, that is searching and analysing colors.

So, where can we look to find which colors are being used? Mine are: 1 - no error; 2 - no error/no non-black; 3 - no error; 4 - no error; 5 - error; 6 - error; 7 - no error, multiple instances of non-black text; 8 - no error/no non-black; 9 - error for 2 colors, only one instance of non-black; 10 - no error.

This script also can tell you where these colores are used.

Could you please send me a document (ore more), where colors go crazy?

I'd like to analyse it to send you the results.

[HeCK]

Hi Klaus,

Sadly, the material contained in my work is copyrighted by FARO. I’m not at liberty to distribute it. I can only strip-down the content and send the documents with very limited content. The newest thing is that all of the chapters, except the front cover, now have inconsistencies in the pre-set colors: Dark Grey, Pale Green, Forest Green, Royal Blue, Mauve, Light Salmon, Olive, and Salmon. This is the same document that had the other errors, which I fixed by deleting the mysterious “user-defined” colors, which were neither defined nor used me. I could have understood these errors happening in 3 of the documents, where I had copied and pasted images in as place-holders, until I could get new screen captures to replace them properly using “Import By Reference”. As I stated in my post: all documents were based-off of the same template. The Release Notice, Foreword, Introduction, and License Agreement have no pictures and never have had. The only colors I have used are: yellow highlighting (limited to only certain chapters), red text (in the header for each document, including the front cover), blue (for my links, internal and external), and black. Nothing has been changed in ANY color definition. It’s interesting that this same document gave me different errors before. What has changed? Nothing that could possibly explain this, unless Adobe has changed something.

This was the only way to get that log. When I tried to publish it as a pfd, the FrameMaker hung at 0%, then crashed.

Sadly, I cannot send you the entire manual. I cut-down only certain chapters, and now the error message about the colors is gone, in the reduced version, which doesn’t solve my problem. After unlocking everything, I tried again to update the book. This was the result (below). I changed nothing in any of those three chapters, nor in the Introduction, Technical Support, or License Agreement. With the numbering, no matter how many times I renumber the chapters Technical Support and License Agreement, they revert back to the previous numbers, and I now get this error message. So, apparently, there are enough errors still left. As I stated: I’ve never changed any of these settings. I’ve not gotten this error before, updating the same book, I’m not even using these colors, and some of these never have had images.

Thank you so much for your help.

Cheers!

Heather Ceana Craig

[Arnis_Gubins]

Heather,

The inconsistent colour message is a FrameMaker warning, not an actual error. FM will happily proceed with processing once you acknowledge and ignore the message. If FM is hanging, then there is something else going on to cause the error.

To clear this warning, try importing only the colours from the original template into all files of the book.

[HeCK]

Hi Arnis,

No. It is in the Book Error log, not some pop-up window. I cannot accept and proceed.

Cheers!

Heather Ceana Craig

[Arnis_Gubins]

Which version of FM are you using? Have you imported the colours only from the template into all files (not just the inconsistent ones) of the book removing overrides?

[HeCK]

Hi Arnis,

I already wrote all of this above. I used a single template. Originally, the error was with custom colors. Not remotely logical – please see the relevant post – but easily solved. This same book, suddenly started giving me errors in standard colors. There was no importation of anything, other than a page from Adobe PhotoShop, which includes a picture and text. That is the Front Cover document. It is the last document that was created. It was the only document that didn’t have this error.

It wasn’t the first document created, so why were the other, older documents being compared to it? Also, the Front Cover uses none of those fonts. None of the documents use any of those fonts.

People claim FrameMaker is so great. My experience is that it is bulk and illogical. I’m using FrameMaker 2015 with the most recent update. It was re-installed on a fresh system beginning August, 2018.

There is absolutely no logical explanation for the behavior of this program.

Cheers!

Heather Ceana Craig

[Arnis_Gubins]

Heather,

The FM book file picks up the information from the first file in the list of files of the book and uses this to populate the internal definitions for colours, fonts, etc. of the book. This info in the book file is then used to compare against the other files in the book for consistency. Adding the cover last as the first file of the book, could have introduced the inconsistency. That is why re-importing the template colour definitions to all files in the book and removing any overrides on those should re-set the book to a uniform state for the colours.

The inconsistent message in the Book error log when updating the book is just a warning and not the cause of an error that would prevent the pdf from being created. I have several projects where a custom colour is re-defined in a single file to accommodate a client's wishes and I get that message all of the time. However, the PDF always comes out with the correct colours as expected. I strongly suspect that there is something else going on to prevent your pdf from being created.

If you set the cover to Exclude in the book, does creating the pdf advance further?

Sometimes the Book file does get borked and the internal definitions are out of whack with the those of the files. It's easier to create a new Book file instead of trying to fix it and then try to create your output.

[HeCK]

Hi Arnis,

No. That explains this case, but not the last one.

Cheers!

Heather Ceana Craig