Can someone help me understand why the file name (formula) I use in one file somehow ends up being copied into a different file if I open it up?
I’ve never encountered this in any program I can remember using. usually the file name I set for a file stays the same each time I open it. In Dorico, for some reason, when I open a file the file name (formula) changes to file name of the last file I opened and worked with.
This peculiar behavior has resulted in my folders being littered with with mis-named files because I forgot to check the file name before saving and it ends up reverting to some other random file name from the last thing I was working on.
My question is – is there any way to change this to keep file names durable to the specific file they’re associated with?
Sometimes I want a formula with various tokens, but just as often I want to use bespoke file names, and I don’t understand why what I type in for one file ends up in the next file I open?
Are you talking about the filename recipe for exported files, e.g. PDFs?
If so, that’s a program preference, specific to your Dorico installation; it’s not something that is stored within the Dorico project.
If you type a variant of the project name into the Filename Recipe, Dorico doesn’t know that it’s a variant of the project name: to Dorico it’s just custom text. As such, that custom text will be kept in all subsequent projects you export, until you change or remove it from the Filename recipe.
You’ll need to either stick to recipes that are entirely produced by tokens, or be more careful.
I have to say that’s the most cockamamie method I’ve ever encountered for naming files. Why does Dorico demand that I use a token formula to name a file?
I have to say I’ve never, ever, encountered a computer program that insists that I use a token system to name file in order for the file name to be durable to file name I’m working on.
I realize that there is absolutely zero chance that Dorico will change this convention, but I would just like to let you and the project team know that having the text I type into the file name forumula box in one file hold over when I open a different file in Dorico is an absolute disaster for anyone who works with multiple files with multiple flows.
Because of this design choice by the Dorico project team I can inadvertently re-name one project with the name of an entirely different file name unless I check what the file name is EVERY SINGLE TIME I WORK WITH THAT FILE.
How can this possibly not be a problem with other users?
I guess I’ve not bothered to complain about it because I’ve been conditioned by the same functionality being broken in Sibelius for as many years as I can remember…
On the other hand, Finale basically didn’t have any functionality for automatically naming exported PDFs.
I never ever had this problem in Sibelius. You named the file and it stayed with the file. and if you wanted to export something as a PDF I never remember having a problem with exports being named for some other random name I’d called another file. It’s been a hot minute but wasn’t there a system dialog for that?
In Dorico, If I want to save a PDF, if I don’t go to check the file name every. single. time. I get ridiculous stuff like this:
Since clicking the export button doesn’t trigger a file name/location dialog (like basically every other program I can think of) the whole system is set up to mislabel file names.
Like, if my chosen export file name at least stayed with the project I was working on that would at least keep me in the ball park. but because the text string stays in Dorico across files it’s a setup for maximum file-name error and maximum difficulty when looking for exported PDFs. Save dialogs may be old fashioned and boring, but good god are people used to using them in the way that makes sense to them individually. Dorico’s “innovation” to completely abandon that system in favor of a token system that isn’t nearly flexible enough for what I need it to do is a deeply unfortunate choice.
Hi @jakeysworld, what you are missing is an automatic reset to default preference for filenames in new projects (the default can be specified in the Preferences/Files/Exporting Files/Filenames for exporting graphics). I agree that this could avoid unwanted/unpredictable naming.
The specific problem in Sibelius is that if you import a House Style into a Sibelius file, it will bring the export filename of whatever was specified in the Sibelius file from which the House Style was exported (but I have to thank you for giving me cause to work out exactly what the problem is there).
…and no, a file name/location dialog isn’t raised by Sibelius either, but the path and filename is in front of you in a more visible way than in Dorico:
I’m really sorry but I don’t understand what you’re proposing at all.
The screen shot I showed is indicating that a file name that I typed into a completely different document has now appeared as the pdf export file name in the document I’m now working in.
If I had had a file export name in the “MMB Northern dance set” file I’m in, it has now been obliterated by the “multidimensional citation example” name that I used on a completely different file.
This just makes no sense to me whatsoever.
With regard to the settings you propose I change I don’t get how this will help. I don’t want to have file names get erased every time I close a file, I want the export file name I’m working with in one file to stay in that file not transfer over to a totally different file.
You’ve made your point.
Hopefully you can comprehend that for some people (such as those of us working for publishers or in session environments) it’s desirable to be able to export files with absolutely predictable file names, always generated using the same formula, regardless of the provenance of the file.
Sorry, I didn’t grasp completely the issue: now I see it more clearly.
At least an automatic reset to default for new projects, would not cause the issue of renaming files with names assigned to other projects, but would at least use names/titles/ etc. of the current Project, using the default tokens.
But yes, the issue you describe is there, and I understand that it is undesirable (if you don’t want to use tokens).
Tokens can be useful in some instances, but I don’t understand why the Dorico team would design a largely hidden PDF output dialog that essentially forces you to use their token system to get semi-reliable results. The lack of a post-“click the export button” system dialog – say that would allow the user to choose a token file name or a bespoke name – is IMHO a major UX design flaw in this platform.
Because Dorico apparently stores whatever the last thing you’ve typed into the “Filename recipe” across any files you open (rather than keeping the combined tokens you set, which seems to stay with the file you’re in) you’re just constantly in danger of hitting export accidentally and ending up with a misnamed pdf, which may also be in the wrong folder if you haven’t remembered to select the destination (which for me is also highly dependent on the name of the file since I prepare workshop materials in batches that are stored in different folders).
Most of us have been trained for years on many kinds of programs that when you want to save a file (whether it’s the dorico file itself) or a pdf export from a file (like in Indesign), but not just those programs – think of pdf downloads from Google suite, or basically any browser, and also in programs like Canva, pdf download in mail, and other apps – you get the system dialog to select file name and folder destination after you click to export/download.
Choosing to go against the grain to not have any prompt to verify file name and location is a UX choice on the part of the Dorico design team that is non-standard and non-intuitive for many users.
I really appreciate your help on this issue. Like many others, I just have to live with the system that has been created, and the collateral damage of having deeply unreliable file names scattered across my folders.
One difference from other programs is that exporting will usually create many related files for separate layout files and/or flows. Thus a filename recipe approach is entirely appropriate. Whether that should be presented to the user each time for review seems, to me, to be an unnecessary additional step.
