Agreed, I think the potential of a vectored image being editable, or getting inadvertently changed somehow in the transfer process, would be a massive liability to me.
Hi Benwiggy,
I’m not a book designer, I am imply reporting back on what two different designers from two different projects have said about their preferred image format for the engraved music.
I can solve the font problem about embedded fonts by making sure that my designers have the music fonts we are using.
The outstanding issues that I have are now related to using .svg for web and other applications:
— option to have white background for .svg
— option to embed/outline music fonts in .svg
Lastly:
— option to set the default slice output per file either at the slice interface level or in dorico settings, or in project settings.
Our project teams are relying heavily on slices for a wide variety of applications. I’m seeing that I will need to create two or even possibly three different clone versions of project files to get output slices in the formats I need them to be in depending on the application: for print I want .svg. for Coda.io and other web applications I need .png (because no white background, no embedded fonts).
I do understand that it isn’t Dorico’s problem that there aren’t universal standard file formats that function across all platforms and different applications. That said, helping the .svg format function more like the old .eps standard (which had the fonts, and all of the vector scalability) would be extremely helpful.
In conclusion, I’m also perplexed that you would write this:
But: “if a vector graphic format designed for use on the web isn’t working for you on a print project, then the suggestion to use a vector graphics format designed for print seems entirely reasonable.”
when the .svg output from Dorico is completely unusable on the web without extensive workarounds (e.g. opening file in another program, adding white background then exporting, and also adding the font information/outlining – which is a whole topic I’d have to learn how to do in indesign or illustrator or photoshop or wherever one does such things).
Regards, JW
If it helps, it’s quite easy to change SVGs for use on the web. Export from Dorico, then use Cloud Convert to change to outlines or curves. This can be done as a batch operation in a matter of seconds.
Hi Dan,
So here’s the work flow?
define slice in Dorico
set file output to svg
set file location
set file name of slice
export to local folder
open cloud convert
upload file to cloud convert
execute outlines operation
export modified file with new file name to local folder
delete unmodified file from local folder
Do I have that right?
Sometimes we do batches, sometimes I’m working on things one at a time. Either way, five extra steps seems like a lot to do on every single file? We believed that one of the main advantages of Dorico compared to Sibelius was precisely the reduced number of workflow steps that Slices in Dorico seemed to offer. The more steps that are added to a proofreading workflow for editions (simultaneous online/web and print), the more opportunities there are for error to creep in.
Do I also get the white background in this operation or do I need to open the files in yet another application to do that?
Thanks for the information about Cloud Convert. I’m just perplexed that an application that is specifically marketing itself as the go-to solution for music engraving would offer export to .svg but not in such a way that it is usable for web applications without reliance on a transformation performed by a third party app (and that this is nowhere noted in the documentation).
Many thanks, JW
That looks about right. I agree I’d like to see these number of steps reduced a little bit, but I’ve done some pretty large projects in batches like this, and it works fine.
I do wish we had the ability to outline SVG exports.
2 Likes