How do I get rid of the ugly “PlanetPress Connect Demo” overlay when proof printing?
I need to present some proof prints to the board of directors and this overlay looks very unprofessional.
You could generate your proof print from a copy of Connect Designer installed on the server (Connect Server) or you could point your Designer system so that printing is done from the remote server. To do this, click on the Window tab on the Connect Designer menu bar, then open the Preferences. Under Print > General enter the hostname or IP address of the remote Connect Server and make sur ethe username and password for the remote server is correct. By default the username is “ol-admin” and the password is “secret”. Then click on Test Print Server URL to make sure you Designer communicates with the remote server.
Once this is all set up, go to File > Print, then click on the Advanced button and select “Output Local” in the Output options to make sure your PDF is written to disk on your local machine and not in a folder on the remote server.
Am I right to assume that for your technique to work one would need an activated/licensed printer in PP Workflow?
If so your technique won’t work for us as we don’t have any activated/licensed printers. We only print to pdf and an external print house uses these to print our documents and distribute them in whatever way needed (seperate envelope, in the box with sold goods, …)
You do not need to activate any printer. In fact, unless you are printing in Printer Centric mode using the PlanetPress Suite Classic templates or Designer version 7 templates, you do not need to activate a printer with Connect. That window is there to maintain backward compatibility with older version 7 templates for Printer Centric mode. Why not just give it a go and see what happens?
Hi Rod,
So I gave it a go and for the most part the result is satisfactory. There is one issue remaining though that I can’t get resolved.
In one of my designs I’m using images that are not included in the design (just because there are far too many) but picked up using a file:// path.
In the datamapper’s preprocessor I have a property constPublicityPath with scope Automation variable, type String and Default value Z:/images/Publicity. This Z: drive is effectively a drive mapping to a local drive in my pc (D:/Projects/VDP). This is done because other designers can have different paths (e.g. for my colleague next to me Z: is a mapping to C:/VDP).
In the datamapper’s extract step I create a field publicity in the data model which is filled with automation.variables.constPublicityPath + ‘/’ + result + ‘.jpg’; and where result (the image base name) is decided based on several data fields (a.o. language and productid).
In the designer I use this field publicity to show the correct image. When using the designer on my local pc the property constPublicityPath is empty and the default is used. When running in Workflow the value given to the global workflow variable constPublicityPath (D:/SOURCES/images/Publicity) is passed to the template and the images are correctly shown. This works correctly in debug mode and “live”.
However, when printing the way you have explained the images are not found, and I don’t understand why. Since I initiate the print from the designer om my local pc I assume that constPublicityPath doesn’t get its value from the global variable in workflow but uses it’s default instead which would be Z. So I made sure that also on the server Z correctly maps to D:/SOURCES so that Z:/images/Publicity would find the images. If my assumption is wrong and constPublicityPath is picked up from the workflow global variable thing should still work.
So I’m a bit baffled. Any ideas on how to solve this?
To start with, I would avoid drive letters such as D:, Z:\ when pulling network resources simply because they generally apply to specific Windows profiles. In this case, these mapped drives may not be available under the OLConnect_Server service account windows profile on the remote server.
It is always suggested to use a UNC Path ( file://///server/share/folder/file.ext ) instead of a mapped drive letter.
On your local system you could map it to D:\ and on the server to Z:\ and on colleagues systems to E:\ or F:\ but it won’t matter because as long as all those mapped drives refer to the same folder, if you are using the full UNC path and the OLConnect_Server service has read\write access to the UNC path, it should pull the images correctly both from the local clients, server or when printing via a remote server.
So when you print via a remote server, the server on the remote system will use the same full UNC path that you are using on the local system and still get access to the images.
So I recommend creating a shared network folder accessible by all clients and server. Then target it using its UNC path like so: file://///server/share/folder/file.ext