#301 %d in Windows 7 not working - shows drive instead of directory

[Joe Winograd]

W7 Pro 64-bit
GraphicsMagick 1.3.20 Q8 (64-bit)

The %d (directory) choice of the -label option in the montage sub-command does not work. It shows the drive (such as C:), not the directory. Note that all of the other file-related choices work fine, that is, %b (file size), %e (filename extension), %f (filename), and %t (top of filename). Only %d (directory) fails. Regards, Joe

[Bob Friesenhahn]

The current release is 1.3.21. I am not able to reproduce this problem with 1.3.21. Can you please try try the current release and see if the issue is still present for you?

[Joe Winograd]

Hi Bob,
Thanks for the fast reply - much appreciated! I just installed 1.3.21 Q8 (64-bit). The behavior is different, but it still doesn't work. Now "-label %d" is producing no text at all (%f and %t still work fine). I'll be happy to help you in any way to troubleshoot this - just let me know what you need. Thanks, Joe

[Joe Winograd]

Hi Bob,

I'm hoping you can help to figure this out quickly, as this bug is preventing deployment of a solution. The full call to GM.EXE in the actual batch file is complex with many parameters, and it is inside a FOR /R loop that utilizes PUSHD and POPD, and it creates a PDF file, not a JPG. I was thinking that those complexities might be part of the problem here, since you said that you're not able to reproduce it with 1.3.21. But I am able to create the problem (rock solid - 100% of the time) with a simple call to GM.EXE, and not even in a batch file - simply in a command prompt. Please try this in your 1.3.21:

gm.exe montage -font Arial -label %d image1.jpg image2.jpg montage.jpg

It produces no text under the montage. As mentioned in my initial post, all other file-related choices work fine (%b, %e, %f, %t) - only %d fails. I attached the output of my five test runs so that you may see the problem clearly. Thanks for your helping in fixing this. Regards, Joe

[Bob Friesenhahn]

The good news is that I can reproduce the problem. The reason why there is no output is that there is no directory part (e.g. '/foo' in /foo/image2.jpg) in the provided filename. I think that this is not actually a bug but it is debatable. ImageMagick does the same as GraphicsMagick in this regard.

We could obtain the current directory from the operating system if it is not part of the file path. This may return a undesirable-seeming path since the operating system has just one path that it will return, but the user may have alternate paths which are much more desirable and lead to the same place.

Given this, what do you expect the behavior to be?

[Joe Winograd]

what do you expect the behavior to be?

In Windows, let's say that one of the source files for the montage is:

D:\foo project\screenshots\Welcome.jpg

I think that this should be in the %d variable:

D:\foo project\screenshots\

One could argue about whether or not there should be an ending backslash - I don't really care, as long as it's well-defined and consistent.

If there were a "drive" variable, I might argue that %d should contain:

\foo project\screenshots\

And that the drive variable should contain:

D:

I'd even be happy with none of this and simply have a "full file name" variable, which for this example would contain:

D:\foo project\screenshots\Welcome.jpg

Here's why this is so important. Consider a program that loops through lots of directories/sub-directories making [gm.exe montage] calls. When viewing a resulting montage, the user needs to know where each source JPG is located in order to know which file it really is. In other words, there could be many different files with the same file name (such as Welcome.jpg). With %f or %t, they can't tell what file it is. I was hoping to create a label in the montage from the concatenation of %d and %t (or %f, but in this case they're all JPGs, so %t is sufficient), and was stunned to find that %d was empty. Regards, Joe

P.S. Is it possible to get an email notification of a post in a thread? I see that your post was 14 hours ago, and I would have responded a lot sooner if I had known it was there. I happened to do a refresh of the browser tab this morning and saw your post, but an email notification saying you had posted would really be helpful. Is there a setting for this?

[Bob Friesenhahn]

Currently what is done is whatever arbitrary path component is supplied in front of the file name part is shown as the directory part. This means that you can have your program add the directory part in front of the file name part, and then the directory will be included just as you expect.

It is actually difficult to do this properly/reliably in GraphicsMagick. The %d is expanded by generic code which does not know about montage. If the program linked with the GraphicsMagick library (GraphicsMagick can also be used as a library) changes the current directory (from where the file was read) before the %d is expanded, then asking the operating system for the directory will obtain the wrong value. An alternative would be for GraphicsMagick to always immediately add the current directory to the file name if a full directory path was not supplied, but this will massively increase the amount of text and would likely break existing usages by other software which are not expecting the extra text to appear in file names. I don't want to break other software.

To summarize, you can fix the problem yourself by prepending the directory part in front of any bare file names, and then you can have full control over the path names added.

Note that %CD% obtains the current directory in Windows command shell so prepending the current directory to the filename like "%CD%\myfile.png" should do the trick.

Note that you can pass arbitrary text via the -label option to have complete control over the text which appears in the montage. The -label option can be specified for each image. For example:

gm montage -label %CD%"\%f" igloo.pdf -label %CD%"\%f" eskimo.ps montage.png

Will allow the Windows command shell to add the current directory, and then the %f will be expanded later by GraphicsMagick. Of course your own application should easily be able to add the desired directory part.

[Bob Friesenhahn]

Regarding email notification of updates to bug reports, if your SourceForge account is set to send email and the address is correct, and the address is enabled for email to be sent, then you should be receiving an email for every little change made to this bug report. This is also provided that the email is not intercepted as SPAM and discarded or put in a special mail folder.

[Bob Friesenhahn]

The current release works as I expect. Changing current %d behavior would harm other usages so I won't fix it. A work-around has been provided.

[Joe Winograd]

Hi Bob,

Thanks for your thorough response — very much appreciated! Btw, %CD% does not contain what one would expect inside the PUSHD/POPD of a FOR /R loop. So your example:

gm montage -label %CD%"\%f" igloo.pdf -label %CD%"\%f" eskimo.ps montage.png

does not produce the desired result - in other words, %CD% does not contain the directory into which PUSHD has just recursed.

In any event, I've abandoned the batch file approach in favor of a real program in a real programming language that calls GM. This gives me the flexibility to do whatever I need without the limitations of a Windows batch file. Thanks again for all of your efforts on this!

Regarding email notification of updates to bug reports, it is still not working. My SourceForge account is set to send email and the address is correct (I receive other emails from SF daily). I have spam filters turned off in my email server, as I'd rather hit the delete key many times daily than miss a single important one. I think it's a problem in SF. Regards, Joe