Background: We are required to print our sheets in Greyscale by one of our clients, BUT we have everything setup in our template to only work with printing in Black Lines. Greyscale is required so that the sheet number on their titleblock will print properly (white label text on black background). So we have come up with a dynamo script that will change all of our standard system colors to black and remove any filters that have color overrides. Then there are some other steps but they’re unimportant to this conversation.
After this process has completed and they’ve printed their sheets, they would then be required to Undo the entire process including the dynamo script run. Then they could sync and continue working.
The issue is that we ran into users who would forget to undo and now a few of our models look like garbage on-screen.
A workaround was to force the user to detach the model and save it with a specific wording at the end of the filename to allow the script to run.
Next issue, BIM 360. When we implement this same workflow, they need to open the model, and then save-as. Problem is, when they save as, the links will all unload and now they can’t print properly…
So back to my topic, I want to break the central file or do something so that they are not able to sync with central until they undo the process outlined above.
Anyone have any bright ideas?
I thought that maybe we could change the central file path (you know, the one displayed in the sync dialog)?
Or is there a way to cause an incorrect schema error that would still allow the user to print?
My gut is telling me that Dynamo really isn’t the answer for this workflow, but its all we have the capability to use at the moment.
1 Like
Is the logo the only thing getting in your way? If that is the case - I’d just redo the sheet number titleblock to work with your current standard.
Is there anything else that needs to be gray?
Seems the simplest thing to do would be print to PDF with the PDF driver set to grayscale. Then send that to the plotter or whatever.
But…
If you really have to have two standards - well - that’s what transfer project standards are exactly for.
Set up two templates one with office standards - which you have. And another with client standards. Anytime you want to switch between the two - just transfer project standards. Which is what it sounds like your script is doing. Who cares if someone forgets to reset? Just re-run transfer project standards to the right one.
Or have users open from central with a fresh local. Transfer project standards to client settings. Print. Close Revit and don’t save to central. No fuss, no muss. If someone forgets and does save - just transfer project standards and transfer the right standard into the project.
I agree, this doesn’t sound like a job for Dynamo. But we’d need to know more details to suggest a better solution.
2 Likes
Thanks for the reply Aaron
The logo is not part of this conversation, but you brought up good points on how to deal with the issue.
I guess we started down a path and just never looked back at the simpler option of TPS.
The funny part is that we have TPS as a secondary part of the workflow already. I wonder if Pipe/Duct System Types were not available categories to transfer in 2017/2018 when we created the workflow, and that was why we went to dynamo for part of the solution.
We’ve had the same issue come up with some of our clients and it’s almost never an easy solution.
This is pretty important. Not sure how you’re handling the conversion to grayscale now, but I would suggest using Dynamo to add a filter to all sheet views and view templates. The filter would simply apply a black color override to everything in the view (halftone still shows) and allow you to print in grayscale. You could then create a second Dynamo script to remove the filters so that if they get forgotten you have a quick fix. This also keeps you from having to open a separate model.
It seems like a strange client requirement in this day & age- but agree with earlier replies:
either
print the PDFs in grayscale
or post-process the PDFs from colour to grayscale. Easy to do with a batch job in Acrobat or any other PDF editor, or a simple Ghostscript batch file
All of our MEP elements are different colors (set via the system type settings) to help the designers quickly differentiate between the different systems while designing, so its not as simple as ‘just print it in grayscale’ b/c when we ‘just print it in grayscale’, all of our elements appear in varying shades of gray, which could mean new work or existing work, or be practically invisible.
Therefore it is important to remove/override any color settings prior to printing.
We will be going the route of a dynamo script that applies a filter and another script that removes the filter. This will remove the need for work instructions and the need for the user to open another file with the proper settings prior to using TPS. Thanks for your help @Nick_Boyts & @aaronrumple
So you don’t use working views and print views?
We have separate plans/views set up for working - where colors and other things are set to make it easier to work. And then we have views for sheets that are for printing and go on sheets. We never work in the print sheets except for notes belonging to the final output. Everything else is designed in the working views. We may have multiple view of the same plan - each for a different task to eliminate clutter.
@adbryson if you didn’t want to use Dynamo for this task, then I would say that you can do what you are asking for using a Revit API plugin that overrides the Synch command. The idea would be to just catch the Synch button press, and check your color settings/update them before allowing Synch to proceed. unfortunately that’s not a job for Dynamo, and would require someone with programming skills.
Actually I would go after the Print command in this particular example. I would catch when Print command is executed in Revit, and override the visibility settings to make them B&W, then wait for Print to finish and change it back to color. That way your users wouldn’t have to think about it. Revit has appropriate print events, so this should be doable with a little bit of programming chops.
Just my thoughts.
Cheers!
-K
1 Like
@aaronrumple, no we do not. I view all those extra views as clutter lol. IMO, all those extra views and likely extra elements in those views lead to model bloat. And maybe its not as big of an issue these days, but I’ve always stayed away from having extra stuff in our models.
@Konrad_K_Sobon, thanks for this response! I was assuming this would be a job for an API call originally, but like I eluded to, we don’t currently have anyone in-house that can do the programming. I’m not sure if we would want to always print like your second solution, but its good to know its an option for the future.