Profiling for print and paper

[david]

When preparing proofs do you typically use one profile that includes both the printing standard and the paper coloring - or do you use two profiles one for the printing process and another one for the target paper?

For example:
Starting from an online web order point for printed materials and given a range of paper types to select from and then assuming some target printing process.
On the input side of a CMS - is it more common to have just one profile that represents both the printing process and the paper, or to have two profiles linked together where one is the printing process and the other is the paper?

IE...
| PDF Color Original | --> SWOP_Process.icc + Paper.icc --> FinalViewer.icc --> My Eyes ~OO~

or

| PDF Color Original | --> SWOP_and_Paper.icc --> FinalViewer.icc --> My Eyes ~OO~

 

[rich apollo]

I'm a little unclear about your question. What are you referring to as "Paper.icc"?

Going to something like an inkjet proofer, the flow looks like: SWOP_Process.icc --> PCS(XYZ - Lab) --> Proofer.icc.

Viewing color on a monitor looks like: SWOP_Process.icc --> PCS(XYZ - Lab) --> monitor.icc.

Your example almost looks like you're throwing in a simulation profile. That would be used in a scenario where you're trying to 'simulate' another device entirely. The most common example would be in previewing ICC color conversions or softproofing RGB files during non-destructive editing. That might look like:
SWOP_Process.icc --> PCS --> Newsprint.icc --> PCS --> monitor.icc

or

sRGB.icc --> PCS --> SWOP_Process.icc --> PCS --> monitor.icc

In each of these cases you're not actually committing to the conversion. You're asking Photoshop (as an example) to perform these conversions in RAM and display the results without altering the actual file.