Suppose you are exporting a .pdf from Dorico. You previously have exported several hundred files from another music notation program into a pdf reading program. The default filename from that music notation program included the number sign (#) that you had used in the title of the score to be exported (e.g. Hymn Name #52).
The pdf reading program into which you exported the file allows you to search #52 and returns “Hymn Name #52”.
When you try to export your pdf from Dorico, it assigns the filename “Hymn Number -52” even though the title of the work was entered as “Hymn Name #32”.
As a result, your pdf reading program does not return the Dorico version of Hymn Name #32 because it thinks the name of the file is Hymn Name -32.
Is there a work around to force Dorico to use the number sign (#) in the filename?
The number sign is usually not recommended for use in filenames, and on some file systems is ‘forbidden’.
Dorico uses a cross-platform framework that underpins much of its functionality; it maybe that the # character is purposefully stripped out to avoid problems in certain environments.
There are of course any number of command line scripts that can be applied to change “hyphen number number” to “# number number”, or to strip the symbol entirely from all files.
If you are on a Mac, there is an easy “rename” function - right in the finder.
After selecting all your relevant files:
Rename “ -“ to “ #” (I included the space before the hyphen).
Be careful not to use the hyphen at another place in your file name…
Can I run that function in Dorico so that the file gets exported with the number sign? The reason is that when I import the file to the pdf reading program, if an earlier version of that file exists, a prompt to “overwrite” appears. This is useful because one does not have to reenter metadata and delete the old file in the pdf reading program.
It will just update the file in all the setlist in which it appears.
As a long time Dorico user I find this limitation annoying. # sign is not legitimate for filenames on the Web, but is is fine for MacOS and Windows. Let me make my own mistakes.
We as normal users of these operating systems might not have completely knowledge and expertise.
As an example, once you export to music.xml these characters in filenames might raise issues.
As I said, experts will know better and why not give them some trust?
If Dorico really let you do things which caused problems, you can be sure that many people would cry out (not unreasonably) “Why would you allow that to happen?”
This is a long-standing peeve of mine as well. I’d note that it also impacts using certain key signatures in a title as well.
I often need to export lead sheets in multiple keys and my naming convention for decades has been to put the key sig in parentheses after the song title. It’s annoying that a file named “Lead Sheet (C#m)” won’t output a pdf with that name, but instead will give me “Lead Sheet (C-m)”.
We try to be conservative in the way we handle non-alphanumeric characters in filenames in an effort to prevent you from running into problems. These days, # is allowed on both NTFS and APFS/HFS+, but because it’s commonly used as part of encoding sequences for characters beyond the ASCII 0-127 range, we avoid using it in filenames. Similarly, & and % can cause problems in filenames if the file is going to be used in other workflows, e.g. processed by scripts.
We certainly don’t want to add options for this kind of thing. Dorico is overburdened with options already, and adding more doesn’t seem like the ideal way to approach this. We can instead consider in future whether allowing # and & is safe enough.
That’s a good point. Right now I’m trying to work around the limitation by renaming the file in the location to which the Dorico file is sent (in my case, the Documents folder in iCloud).
I can see that the solution is ad hoc and might only be useful as long as the user remembers what he did - the problem being that Dorico will not be able to replace the previously saved version of the file with a second, revised iteration it. The name of the first file on iCloud won’t match the name on the revised file from Dorico.
I suggest to enhance Dorico’s scripting capabilities and allow it to call scripts at different spots, e.g. even after having printed or exported a layout, with the filename as a parameter. Thus, a user can change a filename as he wishes and Dorico could keep its (well justified!) conservative file naming approach.
“Now that Dorico scripts can write to the file system, I’ve made this script you might like to try.
… Go on, – run it… What’s the worst thing that could happen…?”