Just wanted to add my vote for this feature as well. I was hoping it would get added in Dorico 3.5. Export individual flows as PDF, with the option to name the files based on a flow text token. Would be a HUGE time-saver for me.
Also would love more options for filenaming when exporting flows or musicXMLs.
Another vote here. What’s the point of this miserable idea “Flows”, if the idea does not concern the output of project!
If I had read this thread before your other question about multi bar rests, I would probably have taken the view that given your attitude in calling something you don’t like “a miserable idea” I wouldn’t bother to answer your question. Just sayin’ 
FWIW I’ve been using Dorico pretty much every day since version 1 came out, and I haven’t ever wanted to print an individual flow on its own yet, unless it was already in a separate layout for some other good reason. But I don’t call you or other people in this thread “miserable” because you want a feature in the program that I will probably never use.
Apology for the bad language “miserable”. I did not intend to leave an uncomfortable remark.
Just meant to emphasize the demand.
Two threads regarding print/export flow have about 4000 view counts in total. Demand is not low.
Some of that demand (certainly most of mine) may have already been alleviated by Graphic Slices, which are new in 3.5. For that matter, the fact that locally set properties can now be set globally makes it much less tedious to create a new layout specifically containing one flow. Also new in 3.5.
Thank you! I will try the new feature.
Unfortunately, neither of those additions are particularly helpful in my case, which often involves extracting 20+ flows with 10+ players. Separate projects for each flow or splitting the PDFs are still the ways to go for me. Those features are great for other stuff, though!
After trying out the new features in 3.5, it did not help much with my case. My feature request is still on.
I have gigs where I have to split the file into separate files for each flow due to not being able to print individual flows for every instrument (or already laid out pages containing any part of a flow).
As the OP, I appreciate all of the discussion of workarounds and other technical difficulties, but will second my disappointment that something more directly addressing these use cases hasn’t yet been implemented as of Dorico 3.5.
The concept of separate flows, for my use cases, is wonderfully useful and powerful, and I use it constantly. But the “story” of my use case is similar to those who have talked about musical theatre settings: We’re making tons of revisions, across large files with lots of flows and players, but then distributing those documents as PDFs, separated by flow, to all of the musicians, actors, etc. The changes are randomly distributed each time, so it’s possible but cumbersome to be updating separate layouts as a workaround.
Everyone often has their own systems for managing their own PDF scores, but in general the flexibility afforded by separate PDFs is extremely valuable. The ability to make a few quick changes, then export just those flows that we need, feels to me like the logical conclusion to the whole “Flows” concept: You get to manage everything under one umbrella, but you can still do everything you would do with separate files (and in fact, it would be even faster to, say, print 5 out of 20 flows all at once, rather than opening up 5 separate files and running 5 graphics exports).
@Daniel Spreadbury, I totally hear you about the technical complications. I can offer a few thoughts on that:
- For anyone NOT allowing multiple flows on the same page, it seems like that would not be an issue (which is my own selfish use case most of the time)
- For anyone who IS allowing multiple flows on the same page (and trying to print flows separately), I think they would understand the added complexity. I think you’re right to observe that users wouldn’t want their layouts changed, so perhaps Dorico could either present a warning that music may get printed multiple times in this case, or even better: allow the user to choose whether pages with multiple flows on them appear multiple times or not (since I could imagine edge cases for both situations).
I’m just such a big fan of Flows that I want the concept to be realized throughout the workflow, rather than getting to the end of the workflow and having Dorico’s Print page seeming to treat the file as one big PDF, and forgetting all of the wonderful semantic information that’s been implemented up to that point!
1 Like
Hi,
Just doing some work for a client, and popped here in frustration at the clumsy end-of-workflow sequence of exporting all flows as separate files, then renaming all of those files before going into them each individually, just to export separate PDFs, in the knowledge that if I need to tweak any tiny thing with the global layout of the pieces, that i’m going to have to do all of this again.
I support mdgrandy’s suggested solution to the not-underestimated technical challenges outlined by Daniel (all those years ago!)
Hi Daniel,
Just coming up against this problem once more. The desire (as @mdgrandy puts it so well) to be make use of the power of Flows while still delivering to my required final format, which is separate PDFs per piece, remains.
I am still very much holding my breath that a soluition for this kind output might be found, and it’s going to makes a different to how I take on moving a couple of big sets of pieces from Sibelius to Dorico.
Any news on this please?
There’s no news, no. But I know that this is something that a number of users would find useful, so it’s something we are thinking about for future versions.
I’m also missing this feature. All my flows start on a separate page, so printing a page range is fine for me. The only problem is, that I need figure out what page the flow starts and ends on. The ten movements take over hundred pages, so it takes a while to find. As I need to do this multiple times, it quickly gets annoying.
A real easy-to-implement solution for me would be a listbox next to the PageRange button. This list would contain the names of all the flows, selecting a flow would pre-populate the page range. Problem solved!
1 Like
The Flow option in Print Rage in 4.1 feels like a big step towards this, but still not quite the full feature. (I got so excited when I saw the mention of this in Anthony’s video… but now realise it’s not QUITE the thing we’ve been waiting for).
But now we have this, could there be an option to Export Seperate PDF per Flow added?
1 Like
That would be a very nice addition, but the new feature is already a great step.
1 Like
So…I haven’t thoroughly tested different use cases yet, BUT, it seems that Dorico 4.1 actually DOES export separate PDFs when selecting multiple flows! It’s slightly clunky, in that it tries to export them with the same filename, so you get a pop-up asking if you want to overwrite the same file, and you have to click “Keep both”, but then you do get each flow in its own PDF.
So, this is pretty excellent! To really finish this off as a polished feature, it would be great to be able to tell Dorico to auto-name the PDFs with the flow name, but I recognize that the current file naming system is not designed to work on a per-flow basis, so I don’t know how challenging that is dev-wise.
But, props to the Dorico team for continuing to chip away at long-standing customer requests, it’s this kind of stuff that makes me an avid advocate for Dorico and the team behind it!
I may have spoken too soon, as I’m now not able to replicate the “separate PDFs” behavior. Maybe I confused myself with my many similarly-named export files (itself a symptom of the reason I made this request in the first place 
)
In any case, selecting individual flows is definitely progress, and I’m still looking forward to the day I can hit “Export” and get all my flows, automatically named as separate PDFs, into one beautiful folder 
1 Like
+1 to this feature of printing separate PDFs from all flows in one go.
A lot of musicians prefer to have each flow/song/movement as separated PDFs.
+1 for this and a related feature: when printing to PDF, a filename token for Flow Name would be a great help
3 Likes