Are image sub-folders a bad idea?

[dorcutt]

So, I've been merrily documenting with Capture (ish), and when I went to review my output I've noticed that the images in my PDF output are sometimes the wrong image, but they are correct in the XML editor, preview, and online output. In the internal text editor, the filepath is correct. Right-clicking and editing with Capture opens the correct image. And yet, the PDF has the completely wrong image.

Digging a little deeper, I've noticed the problem occurs every time that I have a file in a sub-file of the Image folder and a file in the default Image folder with the same name. The PDF output just finds the image in the main folder with the correct name, says "Oh here it is!," ignores the filepath, and blithely stuffs it into the PDF output.

Due to the erratic way that Capture manages image saving (the "Screen Capture" window filepath does not update by default when you change to a different profile with a default filepath, and I'm far to spacey to correct that flawlessly every time), I have many images where this is happening.

Is this a known bug? Has anyone else encountered this? I guess I am going to be spending far more time than I expected today renaming and reorganizing my images folder

[kwag_myers]

I don't see the advantage of using sub-folders within the Image folder, personally. I put a Graphics folder in the project directory and import the file through Flare (letting Flare decide where the file is stored). I've never had an issue with file paths.

I have, on the other hand, recently had an issue with an image file that I replaced with the same name, but the first character was lower-case. That caused me all kinds of grief.

[dorcutt]

I was just trying to stay a little organized, but it seems like it just opens up a giant can of worms.

I'll consolidate to one folder and that should fix this issue. Rather frustrating, though...

[RamonS]

Maybe you can add the folder name to the file names. It will be still one folder but have all files that would have been in a folder before clustered together.

[DocuWil]

I use image sub-folders a long time without any problem.
In my case it has advantages.
E.g. I have a project where I describe about 30 different processes which are targeted to a reference guide.
So, here the sub-folders have the name of the processes.
Later on, using External Resources I access these images when I write test protocols.
But also if some colleagues want to use these images they are easy to find.

Moreover, when using External Resources and having access to more than 1 project, the map structure would show Images for every project and then you don't have a clue where to look.
In my case the sub-folder is in the map structure.

[Msquared]

I too use subfolders. I have far too many images to want them all in a flat structure. They should work as expected. But because of my naming conventions, I don't think I have any images where the same name appears in the top level images folder and also in a subfolder. And, I don't use Capture for images, which may be another thing that is muddying the water for you.

If Flare is really pulling in images with the right name but from the wrong place, then it's a bug and I'd encourage you to report it as such. There is no ambiguity in XML when referencing other files. If your topic really does reference an image in a subfolder, then that's the image Flare should include.

However, there are a couple of things that you may want to check before reporting a bug.

Firstly, check that the reference in the topic really is to the subfolder. You may have already done this, but if not, you can test this by deleting the subfolder image, then trying a build, and then restoring the subfolder image, deleting the main folder image and trying the build. Then you will be able to see which one Flare thinks it is using, depending on which build (if any) reports an error. If it is as you say, neither build will report an error as one image will be there in each case. But if one of the builds reports a missing file, then the one that you deleted is the one that is really being used, and only that one. However, if the XML editor reports a missing file when the other image is missing, again, I'd say you have a case for reporting a bug, as you've confirmed that the XML editor and the build are using different images.

The other thing I'd check is that this isn't a side-effect of something you've done and Flare trying to be too helpful. Do you happen to have duplicate file names because you originally had the images stored at the top level, and have now moved them to a subfolder? Are the top-level images redundant now? I have seen Flare get confused when it tries too hard to keep up with moves and renames, especially if you do them in Windows Explorer while the project was open in Flare, as it tries to second-guess what you've done and adjust your project accordingly. In this case, it can get confused as it caches some of this information in temporary files and doesn't always update that too. So, if you haven't already done so, I'd close Flare, delete /Analyzer, /Output, /Filesync (if it exists) and /SourceControl if it exists, and also /Project/Users, then reopen Flare and try to build your PDF output again. If the problem is still there, go right ahead and report a bug.

[dorcutt]

My issue was caused due to the idiosyncracies of Capture and my desire to leave the images as their default names for now.

Capture would populate the "File location" window in the Screen Capture dialog with the last file location used. So, I had folders where I was storing different type of images (each from a different Capture profile), and I had some images in the main folder that were previously created with the same naming convention. I was just leaving it like this for now due to a deadline.

Button/Toolbar inline images were being captured in a _B folder and named B1, B2, etc.
Whole window images were being captured in a _W folder and named W1, W2, etc.

So, if Capture had already taken a W1 image and stored it in the main folder before I set up my subfolder setup, and then took a new Capture image and stored it in the _W folder, it would also name the first image W1 by default. This is how the two images came to have the same name in different places.

Clearly, in a more sane/less buggy setup, the names would be more descriptive and therefore different. I am keeping a naming prefix of B- or W- to show the type of image/print DPI, so that should help organize some. Maybe I'll try folders again later once I have better image naming habits in place.

MSquared, thanks for the testing tips. I'll submit a bug when I get a chance, but I usually try to recreate it in a test project, so your information on how to test it in my own project/try to resolve the issue is helpful.