ICS Improvements to Multi-File processing

If I may, let give a an example of our IPS file use:

• On a given project, the ELEC group creates an IPS file that lists 10 sheets.  The printer is set to a shared B-size laser printer on the IPlot server, and a matching printer settings file from the IPlot server is applied.  Users can now print the sheets to the laser printer.
• if the user then wants to print to a large-format shared printer instead,  he must open the IPS file, change to the shared large-format printer on the IPlot server, and apply the appropriate printer settings file from the IPlot server.  He can not print from the current IPlot  Organizer session without saving the IPS file.
• If the user instead wants to create a rendition of the IPS file, he must open the IPS file, change the printer to the shared ICS printer on the ICS server, then apply an appropriate settings file from ProjectWise.  The revised IPS file must be SAVED back to ProjectWise, and now renditions can be created (noting that "Presentation" is not a selection option).
• Finally, if for some reason someone needed to print directly to the shared laser printer again from the IPS file, the IPS file would have to be revised again.

I understand having to change printer and printer settings to print hardcopy to different printers.  I find it unfortunate that the same has to be done for creating renditions from IPS files.  It would be great to leave the IPS file as-is, and enable the Presentation choices the Create Rendition dialog.  Just a suggestion.

Your suggestion and Kevin's for IP_DCS_RENDITION_PRINTER and shared ICS printer are good.  I already implement these.

I'm not the best person to ask about documentation.  Like all documentation, I'm sure it could be improved.  The challenge for a writer is to ensure a basic explanation of what the product does while not being so verbose and detailed that nobody actually reads it (with that threshold seemingly going down rapidly).  When you start getting into the nitty-gritty, the style of documentation has to change; you end up needing blog-type articles on specific topics that are difficult to anticipate in advance.  IMHO that's why formal documentation on complex systems ends up being relatively sparse with forum threads and other channels picking up the slack.  Not ideal but just a fact of life.

The idea is that creating renditions from an IPS using iCS for PDF should not be very different from doing so from different PCs using InterPlot Organizer.  Just treat the iCS for PDF server as another user PC.  You can use a shared network printer connection on all the PCs as Kevin van Haaren suggests.  Or just create local printers on each PC and make sure they are named the same.  If you use the same printer driver, every PC will be on the same page concerning paper size names.  There should be no reason to have to edit the IPS every time it needs to be printed/renditioned from a different PC.

One ugly bit is that you need to edit ip.cfg on the iCS for PDF server to set IP_DCS_RENDITION_PRINTER to specify the name of your custom printer.  Otherwise it will use a generic printer with the standard Windows paper size names.  In the upcoming release, this configuration will be more visible in iCS Admin and can be accomplished without having to mess around with text files.

The design also doesn't work well if you have a single iCS for PDF server that serves multiple offices with different physical printers using different drivers with different paper sizes.  It would be nice if InterPlot Organizer supported abstract paper sizes not tied to a particular Windows printer, but it doesn't.  In that case, the printing situation likely already requires multiple IPS and settings files: one for each office.  Adding iCS for PDF to the mix would require choosing one printer to target for server renditions and making that office responsible for managing the IPS/.sets for server renditions.  Or adding IPS/.sets that target the generic "ProjectWise Dynamic Composition Server" printer.  In practice, that scenario doesn't come up often.

Andrew,

Your suggestion is exactly what I have been doing.  On the ICS server, I created a printer for ICS (LACSD_ICS_Printer) that uses our preferred KIP860 driver.  Works great!  Only problem is still having to visit that IPS file to change printers and apply settings file from PW server.

You're providing a lot of good detail that doesn't appear to be document.  Or am I not looking in the right place.

We also discourage our users from using IPS files for ICS because they've been unstable for us. Not sure what it is about our workflows that cause this but we find IPS files just stop working after a while.

We now try to setup renditions so users can just right-click on a file (or set of files), select Create Rendition and then Click OK and get exactly what they need for that project.  No need to mess with an IPS file at all. We typically use either the Sheet Model name or Sheet Description name for the PDF file name depending on the project.

We create a virtual printer queue on every plot server using the same driver and having the same name on each server, this printer is configured to plot to the NUL: port so it never actually prints anything that goes to it. We also setup a set of sheet sizes on every plot server. We do the same on our ICS server.

We recommend our users using InterPlot Organizer or Print Organizer to create PDFs to use that printer in their IPS/PSET files. If they are creating a IPS for use with renditions we tell them to specifically use the VirtualPlot queue shared from the ICS server.

We also put:

printer=\\ics_server_name\print_queue

in every SET file we setup for use with ICS.

About the only thing we have to do for this system now is add the occasional odd paper size that we don't already create.