'.' (dot) not adding to file names PDF & DWG Exporting

Hi all

I am having some trouble with getting some of the nodes to add a ‘.’ (dot) value to the files name when exporting PDF & DWG. Which is a slight pain as its my companies standard.

I am using the crumple nodes by @GavinNicholls and I think maybe an Archilab node too.

I have been playing around trying different nodes. Some add the ‘.’, some don’t. I have had a bit of google and it seems it is known about problem or bug maybe. The scripts appear to recognise the ‘.’ either side of the ‘exporting’ node, but are missing in the values in the node.

If anyone has anyone has any ideas or pointers on this it would really appreciated!

Shout out to Gavin! I did email you about it also, hope you don’t mind.

Many thanks, Sam

1 Like

Hi Sam, from what I have read dots should be accepted if using the export to pdf API/toolkit that is available from 2022+ onwards. Maybe try using my crumple nodes/workflow for that instead of the print nodes.

1 Like

Hey Gavin

So currently working in 2022. I originally used @Revit.printToPdf but that wouldn’t accept it. I switched to the @Revit.ExportToPdf which I think are ones you are referring too? They are really great! But when I tried the @Revit.ExportToDwg it wouldn’t accept the dot. I gave the ‘Export DWG in Document’ node a try, (actually GeniusLoci) which did accept it.

Anyway, actually just had a chat here and we are going to abandon the dot with something else now. So going back to the @Revit.ExportToDwg.

Cheers Gavin,
Sam

@GavinNicholls I think the file naming issue may be caused by this line in © Revit.PrintToPdf
As the node prints each pdf individually this could be set to False?

    # Check if printer is virtual and set print to file
    print_manager.CombinedFile = True

To my understanding the export pdf api requires a naming rule unless you merge a set. In this case i merge each individual pdf so it can take a single provided name to work around this. I suspect this is unrelated as the no dots in filename thing occurs in lots of programs and API’s.

I suspect wherever it happens it is likely a helper behind the scenes stripping them out below what the API lets us achieve.

If that’s the print manager based node then I’ve generally always done that to avoid dealing with lists of sheets/views which comes with its own challenges/quirks, as the print API takes a list vs a single view/sheet as input. I think archilab/genius loci follow a similar approach.

1 Like

Some thing just rang a bell here. You guys are way ahead of me here, but for what its worth, I was playing around trying to get @Revit.PrintToPdf to accept the dot. One thing I tried was simply putting into list, which changed the depth. Then as single file the dot was accepted

Think I defiantly want to use the crumple Export nodes for my scripts However.

As I mentioned, we are going to keep away from the dots now, but interesting to know if there is way around it.

Maybe ill have a crack at changing that line of code. See what happens.

Sam

Save out the files with another character combination. I like two spaces ( ). Then after all PDFs are created use a second Dynamo graph to rename the files and replace the with a . using a String.Replace node and then rename the file with a FileSystem.MoveFile node.

As an added bonus you have a built in QA/QC check as you know any files with two spaces isn’t ready for distribution to the customer yet.

2 Likes

Thanks Jacob

Sounds like a good work around.