I know I have shared this before but I cannot seem to find that post. Nevertheless, I would very much like to have standard system file save dialogs when exporting audio and saving PDF files to disk. Not being able to choose a desired directory that makes sense to the user probably should not be forced workflow in Dorico.
For example, if I want to export audio files for the 31 flows in a project to my choice of (or a new) directory would eliminate the need to add a system step or two in order to put these audio files where I can batch process them. And, why would it be appropriate to send audio files to a folder Dorico defines with the flow name but not do that with a pdf export of that flow?
Not interested in creating dissonance with anyone about this but would be a seriously appreciated future update / upgrade utilizing normal OS file save capabilities for essentially any/all file save operations especially include exported data. Thanks!
I’m afraid I do not understand. My export screen lets me choose the destination of the audio export, for example. I sense you mean something else and would welcome a clarification.
The primary issue with the audio export is that, even after selecting a directory, it creates a subdirectory for each flow’s audio file when exporting as separate files. If we were using OS dialogs, we could make sure those files go where we want them rather than creating another level of arbitrary subdirectories.
In the Print Mode when saving PDFs / graphic files, there’s an unnecessary extra step to create one’s desired filename. On my Mac systems, the arbitrary filename using tokens does not always work sometimes resulting in all PDFs of different flows being named the same as the token values for the first flow and overwriting previously saved PDFs when saving PDFs of subsequent flows.
So, it’s messy as is and would be so much easier for the user to simply use OS file save dialogs. There’s no problem with initially pointing to the most probable directory but that should be easily overridden by the user as desired at the time of file save, well in my opinion anyway.
“Not always” is correct. It means you’ve previously copied and moved a Dorico project to a different location on the OS level and renamed it to use as a template for a new project. This will result in your outcome..
We do plan to revise the user interface for file export operations in future versions so that they are more consistent and more flexible. It’s on the backlog for future versions.
I would certainly appreciate the ability to export an audio file without Dorico’s putting it in a separate sub-folder. I’d prefer just to save the audio file in the same folder as the project.
This is a reproducible scenario, as a Dorico file saves the export path in its project file.
You may check this when you - before exporting a graphic file - have a look at the displayed path.
Dorico is very consistent in this regard; file export, despite having an unusual interface, is never a random experience.
@k_b, I truly appreciate what you are saying but none of the scenario that you described has ever been the case. Thank you, though, for lending your expertise. I will challenge the thought that Dorico or anything else is “never a random experience.” If we open our minds a bit to alternatives, we find that the random can sometimes insert itself in one way or another.
While Dorico is a fine, maturing product overall, no piece of software is immune to random unexplained behaviors because no coders, being human, are ever perfectly correct and error free in their work all the time. Never and always are lies we often tell ourselves to insist that our perspective is the only perspective that anyone should consider.
I would say “behaviors which appear random”. Everything that software does can be explained by the reasoning contained in its code, even though the explanation may not be apparent to someone unfamiliar with the code. Sometimes that behavior is not the developer’s desired or intended outcome, because of conditions that he or she failed to take into account, but it is not random. (Unless the code includes something like a random number generator.)
Well, that’s a whole other discussion! Some RNGs are more random than others, but yes, the most common type in code can be predictable if you know the seed value.
Well, sometimes there are idiosyncrasies in operating systems and even compilers that coders simply are not aware of being there. In my experience, these are the things that cause random issues. We can debate this ad infinitum so maybe we just agree to disagree, remain friends and move on…
