Hello,
I tried to use the new glyph editor to add Saariaho-style bow overpressure png graphics. It works - except it can’t seem to save the png files with the project, so each time I go in the graphs are blank again and I have to go back into glyph editor to fix it.
Is this in Engrave > Music Symbols or Engrave > Playing Techniques? Are you clicking the star button (Save as Default) or just trying to make the change in a single project and then saving the score? Does the problem persist after restarting Dorico?
Hi Daniel,
I am doing this under Write mode in Playing Techniques on the right, by clicking on the pen icon at the bottom of the list of string techniques. I’m not clicking on the star button to make it a default, I’m just trying to make the change in this one project. I created four new overpressure techniques that use a graphic PNG as the image. I can place them in the score and they show up fine, but when I try to save the project, I get that error, although it saves all other changes. If I quit Dorico and go back in, and reopen the file, the glyphs have vanished but then when I go back into the techniques and add the graphic again, they come back in the score exactly where I originally placed them, but then again the error message above happens when I save and if I quit and go back in again they are gone. The “Select Existing” option under Edit Playing Technique → Graphic keeps getting longer and longer because each time I close and reopen and have to re-add the images, there are three new grey rectangles on the right side where the old graphics that didn’t save properly used to be (attaching a screenshot to make it clear).
I’m unable to reproduce this problem so far, unfortunately. Can you please attach the project and the PNG files you’re using in a zip file?
Hi Daniel, it is attached. The four graphics are used in the string techniques “Overpressure 1”, “Overpressure 1 - beginning only”, “Overpressure 1 - middle only”, and “Overpressure 1 - ending only”, and after adding the graphics to those techniques I scale them to 20% size horizontal and vertical in the dialog that I showed in the last screenshot I had sent, otherwise they make the playing techniques box too wide and there is no horizontal scroll. Then they appear in the score where I had put them (mostly about 3/4 of the way through), but saving gives the error.
Unfortunately no attachment has made it here. If you’re having trouble attaching it, you can email it to me at d dot spreadbury at steinberg dot de.
I tried with a new project and can reproduce it with a new project as well.
The behavior seems to vary when I use different images. It must be something about the images that I am attaching that Dorico does not like.
Yes, that would be my hypothesis too. I’m going to look into it today on a Windows computer and will report back. (I only use Macs and come out in hives when I have to use Windows, but I’ll do it for you!)
OK, after a morning of looking into this, the issue is that you are, through no fault of your own, falling foul of the limitation on the maximum number of characters in a Windows pathname (which is 260 characters). Because of the folder structure that Dorico uses when maintaining local copies of the files in your project, it’s not difficult for you to end up with a filename that’s too long. We will fix this in due course, but in the meantime, the workaround is to keep the length of your graphics filenames down to a minimum length: something like 8-10 characters plus the file extension should be OK.
Sorry for the inconvenience!
Thanks, Daniel, it works fine now.
Welcome to 1986. How can we possibly have such an OS limitation in 2018?
But at least it looks like there is some possibility this will change before we are all dead:
with the latest Windows 10 Insider preview, Microsoft is giving users the ability to increase the limit.
The recent most Windows 10 preview is enabling users to change the 260 characters limit. As mentioned in the description, “Enabling NTFS long paths will allow manifested win32 applications and Windows Store applications to access paths beyond the normal 260 char limit per node.”
It isn’t a limit. Your link (and note it is now more than 2 years out of date when it says “the most recent version”) talks about 32-bit applications, and Dorico is 64-bit.
32-bit apps on Windows have the limit by default, because Windows 10 will still run apps written 20 years ago (unlike another major computer brand!) and in the real world many companies still USE apps written 20 years ago.
The limit is now 255 characters per component of the path name, and (approximately) 32767 characters for the complete path name.
To work with these long names, the application has to use Unicode versions of the functions in the Windows API (but this should probably be done anyway for an international app like Dorico, aside from the path name issue).
See Naming Files, Paths, and Namespaces - Win32 apps | Microsoft Learn.
The reason Dorico is currently subject to this limitation is that, like many large-scale C++ applications, we are using the boost C++ library as an adjunct to the C++ standard library, because it provides a lot of useful functionality. One area in which we use boost’s capabilities is in file-handling, as it provides a nicely abstracted way of handling files in a cross-platform way. However, boost does not comprehensively support long filenames in NTFS, because it is a conservative library designed to provide maximal compatibility. So there will be some additional work for us to replace boost or update function calls in these areas, which we’ll do at some point.
Do you really need to support it comprehensively? The documentation at Filesystem Reference states that most of the Boost.Filesystem functions work with extended length prefixes. Or is Dorico using some functions that do not support extended length prefixes when saving items of this type?
This isn’t a programming forum, but “all paths must be absolute” sounds like a non-trivial restriction to work round in general, IMO.
“All paths must be absolute” is something that can be worked around rather easily. If I was dealing with a function where I could not use relative paths, I would simply concatenate together the folder I wanted with the relative path I wanted and pass it as a combined string to the function as an absolute path. It is really simple to do.
However, the problem may be what is stated a bit lower:
Certain Boost.Filesystem functions that decompose their argument path and then work on individual relative directories or files will not work properly with extended-length prefix paths.
That could be a problem if Dorico uses some of those Boost.Filesystem functions that actually split the path and do operations on the relative directories, and that may explain why they cannot do it. However, I am simply asking in case maybe in this case they are not using any functions that behave in that way for the act of saving the embedded graphic.
Well, if the Dorico development team can’t read straightforward software documentation without help, I think we have much more serious problems to worry about than not being able to save some graphics files 
Exactly what the team will choose to do about this problem is above my pay-grade, and it may even be that I have got one or other crucial detail wrong in my own understanding of the problem based on the discussion we had last week, and perhaps I have incorrectly ascribed part of the problem to boost when in fact it’s in the underlying Windows APIs. But either way I’m certain that they will come up with a good solution in due course: in the meantime, if you make sure that your graphic filenames are not super-long, you should not run into the problem.
