As we ramp up hymn singing once more in the UK (hooray!), I am looking into the best workflow of exporting image files of hymn tunes to place in congregational orders of service.
Ideally, I would like to use SVGs for this, as I think it would be beneficial to use a vector file format, not least as we’ve had problems with PNGs and TIFFs printing in a sub-optimal way following resizing in Word, not to mention the benefits of small file sizes. I’ve also had success in using the SVG format for image files of psalm chants when I re-typeset our psalter over last year’s lockdowns.
However, I’ve run into a problem regarding the embedding of fonts. My colleague who produces the orders of service (on MS Word) reports that a text font is not embedded in the SVG file, so that if he does not have that font installed the text will display in a substitute.
My question is: is this expected behaviour in the SVG file format, and the way that Dorico exports to it? Is there any way that Dorico can embed fonts into SVG files, or should it be doing so and there is something wrong in our workflow here that is causing this to go awry?
A supplementary question/feature request! I really miss the ‘smallest bounding box’ export option from the purple app, which I used to use all the time for this purpose. Whilst graphic slices are great in their own way, I want the program to calculate the boundaries of the graphics export so that there are no margins whatsoever on the graphic, which cannot really be done by human hand. Is there any chance of this functionality making its way into Dorico at some point, please?
Until such functionality is native to Dorico, to reach that ‘smallest bounding box’ status for my exports, I have been using Inkscape to do this to my exported SVG files. Simply opening the full-page exports from Dorico, running the ‘Resize page to content’ command, saving the file and exiting Inkscape. Might the use of Inkscape in this way be mucking up my fonts in my exported SVGs?
Many thanks to all for any advice on this one - I appreciate it’s a bit of a technical and detailed subject!
Now this is my ignorance showing - I simply cannot conceive of a PDF file being anything other than a ready-to-print page-sized document, as opposed to a graphics format that can be any size and embedded into Word (or a.n.other application) just like a JPG or PNG! But I suspect that the use of PDFs has changed a bit and I’m rather stuck in the past!
I’m really keen to set up a sustainable workflow for these files that successors and other colleagues can use. Do you know if Word handles PDF as a graphic import format and how well it handles it? I’ve simply never considered PDF as a suitable format for this kind of workflow before!
Word is a rather inefficient way to go about designing worship aids.
My current workflow is to decide on a format (in my case, 11x17 trifold), then standardize all my settings for each file I wish to include (custom layout 5.66” wide[matches the trifold column width], 0.5” margins, custom rastral size thats between two default options) and then I export PDFs. These PDFs are then brought into Affinity Publisher and since the margins of the pdf and the margins of the columns in my worship aid match, the files can just be plopped in and it all snaps into place.
Yes, PDF has been used as a graphic image format for years. (I had a job placing PDF quarter-page adverts into magazines about 15 years ago.)
Any workflows where EPS files were used, PDFs can be substituted without any effort.
You can certainly add PDFs to Word, and it should handle them ‘as well as it does any other image’. But really Word isn’t the ideal tool for decent page layout. I’d suggest Affinity Publisher, or Scribus (which is free). If you’ve got lots of money, there’s Adobe’s InDesign.
Recent versions of Word seem to handle PDF imports just fine. Certainly historically there were issues in that Word would convert the PDF into a raster image on import, meaning that subsequent scaling would be subject to pixellation. This seems no longer to be the case (at least in Word for Mac, v16.52 with an Office 365 subscription).
Thanks, all - I’ve learnt quite a bit over the last couple of hours, as I hoped I would!
I’m afraid that the use of Word for the creation of these documents is a non-negotiable. I don’t create the orders of service, I’m just supplying a few graphics files each week, and there’s no appetite to change the program in which the orders of service are created. But points taken on board for any future projects that I might create under my own steam (and I already own a licence for Affinity Publisher).
Thanks @dan_kreider for the suggestion of CloudConvert - I think this might be the way forward. And sorry to miss the fact that you had already requested the conversion to curves within an SVG file exported from Dorico. I certainly second that feature request, alongside the request for a ‘smallest bounding box’ export option for graphics.
Yes I use it constantly for PDF—>SVG and “convert to path.” It’s become a regular part of my workflow. Even paid the monthly subscription a couple times to facilitate large projects.
The PDF was exported from Dorico 4.1.10 so I guess it was.
I’m also having issues with Illustrator 26.3.1 which is deforming every PDF imported and then saved as AI file …
Even so, Benwiggy, there are still many reasons why .svg files are preferable to PDF for print design applications.
I have found that the music fonts do not embed with .svg export, and I also do not have the option to include a white background (though there is a check box there for it).
I understand that some people like to use PDFs. On the other hand, I think it is important to recognize that there are others who have reasons to prefer .SVG. In any case, since .svg export is offered in Dorico, why not make it fully functional so that those who wish to use that format can do so?
I understand that this is an old topic, but just two days ago I got a call from the book designer who’s working on a project I set the notation for. She wondered why none of the .svgs had the key signatures and clefs. Of course when I open the .svgs on my computer those elements are there. (sent her the fonts and it solved the problem).
From conversations with other book designers I was given to understand that the standard for .svg was that any font symbols/glyphs(??) should embed with the file. Is that not an appropriate expectation?
The answers to these questions are important for a number of publishing projects I’m working on. Is it conceivable that embedded fonts and white background for .svg slice output could be added to the feature request list?
Embedding fonts within SVGs is generally unreliable, compared to PDFs, both in the creation and the parsing; because it was subsequently added to the format as a workaround by encoding the font as a resource. Outlining text into curves is essential when using SVG.
I note that neither Affinity suite nor Inkscape embed fonts in their SVGs: though you do have the option of outlining.
I agree that it would be useful for Dorico to outline SVGs, but that may depend on what graphics libraries are available for it to use with this function. I wouldn’t expect, or want, the team to spend time writing it themselves.
PDF has been a solid, flexible and comprehensive graphic format used in the print industry for 25 years.
SVGs are slightly easier to edit in a text editor, if you’re into that.
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.
I had a conversation specifically on this topic with our book designer and he would prefer to have SVG over PDF for our projects, precisely because of the text editing possibility. In this case (and in the case of the other book designer I was working with – who also preferred .svg btw) I can solve the font problem by just sending the fonts.
But it remains true that I can’t really use SVG on the web because I can’t export with a white background and I can’t export with the fonts embedded or outlined.
Speaking of use of developer time, would it be possible to devote some developer time to having the file type selection box in the slices panel not revert to pdf every time I create a new slice?
If I’m defining and exporting .svg files in a project, why can’t the dialog remain as the “last used” file format, or alternatively, how about a setting in preferences that could be set as the ‘default file format’ for slices in a particular project?
Having to make a manual selection every. single. time. not only adds time to the work flow, it introduces an avoidable potential for error if one doesn’t remember to change the file format for every slice.
I would hope that compared to outlining graphics for .svg this kind of UX improvement would require less developer time.
