Yes, Shahnawaz, you'll have to go some other route as XPP does not have an option to greyscale the colors in images.

And while I'm here, I just want to make a comment in general to all who use this forum. I'm seeing a tendency in posts that they are very lacking in details. For example, here you talk about generating a PDF but in XPP there are two main workflows to do that: psfmtdrv (PS workflow) and divpdf (Direct to PDF). Each of those workflows has its own options and quirks, so it's always best that it be specified which workflow is being used. It doesn't hurt to also specify exact command lines that are being used, so it's known to readers what all the options are that are being used. Of course, the same applies to other XPP utilities that are being discussed, such as divxml, divhtml, etc. If everyone takes the time to provide more detail with their posts, I think you'll find that you'll probably receive more feedback and quicker feedback.

Also, when asking general "how to" questions it's also good to mention what you've read in the documentation about your subject or what you found was lacking in the documentation. As a reminder the XPP documentation is provided as a downloadable PDF Archive (with an Acrobat Index or Catalog) with capabilities to easily search across the entire set of XPP manuals.

Yes, Shahnawaz, you'll have to go some other route as XPP does not have an option to greyscale the colors in images.

And while I'm here, I just want to make a comment in general to all who use this forum. I'm seeing a tendency in posts that they are very lacking in details. For example, here you talk about generating a PDF but in XPP there are two main workflows to do that: psfmtdrv (PS workflow) and divpdf (Direct to PDF). Each of those workflows has its own options and quirks, so it's always best that it be specified which workflow is being used. It doesn't hurt to also specify exact command lines that are being used, so it's known to readers what all the options are that are being used. Of course, the same applies to other XPP utilities that are being discussed, such as divxml, divhtml, etc. If everyone takes the time to provide more detail with their posts, I think you'll find that you'll probably receive more feedback and quicker feedback.

Also, when asking general "how to" questions it's also good to mention what you've read in the documentation about your subject or what you found was lacking in the documentation. As a reminder the XPP documentation is provided as a downloadable PDF Archive (with an Acrobat Index or Catalog) with capabilities to easily search across the entire set of XPP manuals.

Thanks John for the confirmation and the comments. Next time, I will add more details while asking any questions in this forum.

I tried to generate the PDF using divpdf (Direct to PDF) workflow.

Warm Regards,

Shahnawaz

Thanks, Shahnawaz.

Just want to make sure it's clear that I wasn't picking on you. It's been a "general" trend I've been seeing with posts. I probably should have started my own post on that subject instead of piggybacking on your post. 

That's okay John. Apart from color images, the background shading should generate in greyscale but that is not generating.

I am using <fboxt;100;4;1;.......> macro to generate the background shading but when I am trying to generate the greyscale PDF its gone. 

Can you please advise why the background shading is getting off in the greyscale PDF.

Thanks!

Shahnawaz 

I can think of two possibilities. 1) The -nocolor option predates the ability to have background colors; or 2) it's intentional behavior.

The description of the -nocolor options states: This switch is useful for proofing colored text that might otherwise be difficult to read.

As such, I would guess that it's not intended to be a full-blown "color processing" option. There are much better third-party tools (such as the Print Production tools in Acrobat) for doing this kind of color processing (and also color separation).

I think there's a strong possibility that XPP intentionally drops the color backgrounds, in the context of "readability". Think of the case of having black text on a somewhat dark background, like a blue. If the blue background color was made into a "grey", it would be a pretty dark grey and then the black text on top of it might be obfuscated.

In any case if you feel that this is not desired behavior or is a "bug", then this is not the right forum for pursuing that.

You would need to open a Support Case (or ticket), explaining what you feel is a "problem" and providing a sample JOB.

Ok thanks for your comment.

 Hello Jonathan Dagresta - quick note on color conversion from what I've experienced.

The "out of the box" conversion from color to grayscale in applications like Acrobat / PitStop are rarely accepted by clients I've worked with. 

Instead, I've had to do a custom mapping from a defined color to a percentage of black. This is needed to preserve certain visual differences in graphics, charts etc... 

If the idea for extending the colorspec to include newer color models is one that's being considered - maybe adding another field for the percentage of black to use when converting a defined color to grayscale would help avoid the issue I described above. 

Related idea:
Add support for defining color using newer models in the XPP colorspec - XPP Ideas - Contenta Publishing Suite Ideas - RWS Community

Interesting stuff, Thomas.

But no matter what, my opinion (not official RWS response) is that any "fancy" color conversion process (like color conversions/greyscale or color separation) is best handled outside of XPP.

In any case, I suggest that you add your additional suggestion regarding the XPP Color Spec to your existing "newer color models" XPP Idea (if you haven't already done so).