MadCap Capture issues - caches old image!

[sdcinvan]

I am using image synchronization, that is, I have a common folder for images which all my projects (Flare and other tools) access.

This means that when I need an image in a Flare project, I retrieve it from the common folder, and then Flare opens a "Copy to Project" window where I need to select "Keep file(s) synchronized (create mapping)".

This works okay except when I need to add overlays via MadCap Capture. The moment you introduce MadCap Capture, conflicts and permanent merging conflicts occur! This is truly messed up!

Steps to reproduce:
1. Insert an image from a common folder.
2. Flare opens a Copy to Project window where I select Keep file(s) synchronized (create mapping).
3. Right-click on inserted image and select Edit with Madcap Capture.
4. Save to update in Flare.
5. Modify source image, a normal/expected operation.
6. Perform a Flare Synchronize Files operation.
Flare will display a file conflict!
7. Select Resolve...
It won't resolve!
Resolution Options: Undo my local changes
Discard external changes
8. Pick one, I selected the closest to what I needed, "Undo my local changes". But it doesn't matter because they both fail to work for different reasons.
9. After "synchronizing" you will see the source updated image.
10. Click Edit with Madcap Capture, and when Capture opens, you will notice that the older, previously sync'd image is still present in Capture!
In the attached illustration, I ask where this old image is... but that was before I realized that it is embedded in the .prop!

There is apparently no way to update this image without destroying the .prop file! What?? How on earth are images later updated?


Is this another situation that I am simply not doing right?

Please set me straight.

Probably overkill but I graphically illustrated the problem:

Capture_not_syncing_refreshing_images.jpg

[atomdocs]

Hi Shawn

Well, I have been able to work through your process and get sync to work as expected: after editing the external file, I hit Synchronize Files and the image in my topic updates to show the external edit. (However - it is only visible in Web Layout. If I switch to Print Layout, the edit is not visible. Switch back again - all ok.)

But the whole process still fails on your main issue concerning Capture: when an externally edited image is edited in capture, external edits are lost in the project version.

I think this is the catch-22 of Capture: the props file is what powers the Capture<>Flare integration, but it can't be updated by external editors.

My answer to your question about how images are updated later is, (I don't think you'll like it), only update an image using Capture.

And, I think there is a gotcha: if you want to keep your external file and your project file permanently 2-way linked and synced, you need to add the props file as a manual mapping for synchronization (it doesn't seem to be added automatically). I'm not sure if that was obvious, or if I was doing it wrong previously, but it just occurred to me.

Obviously, the list of things that Capture can't do compared to e.g. Photoshop is an infinite one, but Capture can still do quite a bit. Also, if you need to update an image because of UI changes, there is the Recapture option...

Not much help, I'm sorry, but if we understand the limitations, we can start campaigning for features.

[sdcinvan]

My answer to your question about how images are updated later is, (I don't think you'll like it), only update an image using Capture.

Hello Tom,
Thanks for your reply.

That won't work because many of my screen captures are automatically generated by a script. Then I do some cropping, add them to my common image repo, link/sync them inside Flare, then do final edits/annotations inside Capture.

This workflow completely breaks down when I need to sync the images. It seems like the MadCap developers did not put a lot of effort into accommodating writers that are both syncing images from an external [to Flare project] folder PLUS using Capture to edit those images.

I am now using Capture's replace image option. It isn't ideal but still better than other alternatives.

IMHO, this image updating process needs a major overhaul because it isn't very efficient when one has a lot of images that are frequently updated. I am surprised that this seems relatively unimportant to others... am I the only writer in this situation?

[sdcinvan]

To update, these are the steps I must take (with my opinion on how approximately it should work):

Steps:
1. Insert an image from a common folder.
2. Flare opens a Copy to Project window where I select Keep file(s) synchronized (create mapping).
3. Right-click on inserted image and select Edit with Madcap Capture.
4. Save to update in Flare.
5. Modified source image placed in common folder, a normal/expected operation.
6. Perform a Flare Synchronize Files operation.
Flare will display a file conflict!
7. Select Resolve... Undo my local changes. [Flare should understand that image was modified in Capture and do a complete Capture image update as well!]
8. After "synchronizing" you will see the source updated image. [Go into Capture and make any necessary adjustments to annotations, etc. ALL DONE!]
10. Click Edit with Madcap Capture, and when Capture opens, you will notice that the older, previously sync'd image is still present in Capture!
11. Select Edit > Replace option.
12. Capture opens to default folder (CAN THIS BE CHANGED?) - change to common images folder OR sync'd image inside project? Not sure if it makes any difference.
13. Select replacement image.
14. Make adjustments to annotations, if necessary (but usually not likely).
15. Save in Capture, return to Flare.

In other words, the Flare update should understand changes also made in Capture and update everything for all the images with just a few clicks! That is how it should work!

[doc_guy]

I don't think many people are using external folder synchronizing, honestly. Every time I introduce it in a class or to a client, it is something that they've never seen before. Even at the MadWorld conference, where I talked briefly about this feature, I got a lot of feedback that people who had been using Flare for several years didn't know how this worked.

So I think that a relatively low percentage of people use external folders at all, and probably dramatically fewer use external folders for all images in their project, so I think your experience is probably relatively rare, which is why you don't see a lot of traffic on this topic.

Flare and Capture were designed to work using a standard worflow of capturing the image in Capture, and then generating help topics with Capture images in Flare. You are having trouble because you are trying to modify that underlying workflow, which is the source of the trouble. Because Flare and Capture were never designed to work in the way you are requesting, it isn't surprising that you are having issues trying to bend Flare to your will. Capture simply works best when you use Capture to take the screen shot. Any other workflow is going to be more tedious because it isn't the way Capture is designed to work.

You'd have the same thing if you tried to work in Snagit, which has a similar feature now where you can save the file separate from the annotations. You still have to generate a standard file version, but you can open up the Snagit version and make updates to annotations. Again, the screen capture tool is designed to work best when it uses its own screen capturing capability, rather than trying to import in updates from a different screen capturing tool/process.

[sdcinvan]

You'd have the same thing if you tried to work in Snagit, which has a similar feature now where you can save the file separate from the annotations. You still have to generate a standard file version, but you can open up the Snagit version and make updates to annotations. Again, the screen capture tool is designed to work best when it uses its own screen capturing capability, rather than trying to import in updates from a different screen capturing tool/process.

I think Snagit is a bad example.

In the past, I all annotations were done within FrameMaker, image updates were simply a manner of overwriting the source images and selecting update all images within FM. Very simple and done in a matter of seconds. Actually, this is exactly how Adobe InDesign works, as well.

Even if I used Capture to capture all my images, as far as I can tell, you still can't do a one button click/update all your images. Oh wait... that is moot, I think the assumption here is that a tech writer is always manually captures their required images. :]

[doc_guy]

So you are requesting a new Flare feature, not a new Capture feature. You compare it to Frame and Indesign, which are both authoring tools. Capture is not an authoring tool, which is why the comparison to Snagit is a valid one. Flare doesn't provide an annotation feature like both Frame and Indesign have. Capture is a screen capturing tool, like Snagit. Capture stores metadata about a picture, including callouts and arrows and such, like Snagit can. When you save an image using the .snag file extension, Snagit does exactly what Capture does: it creates a file that stores both the binary image information as well as XML about the callouts and text that have been added to the image. You can edit a MadCap .props file in a text editor, just like you can edit a .snag file in a text editor. In both cases, you can edit the XML, but don't touch the binary portions. Also, like Capture, the Snagit file itself can't be used in any other tool. Where Capture is better than Snagit is that Capture actually creates the resulting .png file and keeps it in the same folder as the binary/properties file.

Snagit is a really good example, because Snagit and Capture are the same kind of tool, that do almost the exact same function when you save in their proprietary file types.

If you want the functionality of InDesign and Frame, what you really want is an enhancement to Flare that allows you to annotate on top of linked images, without editing the linked image. Then if the linked image changes, your annotations remain because the annotations are actually in Flare, not in the image editing tool.

[sdcinvan]

If you want the functionality of InDesign and Frame, what you really want is an enhancement to Flare that allows you to annotate on top of linked images, without editing the linked image. Then if the linked image changes, your annotations remain because the annotations are actually in Flare, not in the image editing tool.

I think all that is necessary is for Flare to be aware that when a File Sync is initiated, Capture also made changes to that newly inserted/replaced image and then initiate a merge of the new image with the Capture annotations. Like you said, this is a Flare feature request... but also a Capture feature request.

I will do this when I have some time to fully articulate the desired workflow.

[doc_guy]

I see what you are saying. In that workflow you would need to modify both Flare and Capture. Flare would need to pay attention to the image that is being imported and check to see if a .props file exists for that image. If it does, it would need to hand off the image to Capture, which would need to replace the background image and save the new .props file and the new .png (or whatever) file.

Unfortunately, I think this is pretty significant change in how Capture works, and even in how Flare works. AFAIK when you do external file syncs, Flare doesn't have any logic built in that treats the incoming files in special ways, depending on the file type. It just does a two-way sync.

Sounds cool, but I wonder how frequently it would be used. I mean, clearly you would use it a lot. I wonder if there is wider interest in it that would justify the change.

[atomdocs]

Hi Shawn and Paul - this is a good discussion.

Shawn, I do understand your pain when you compare your Flare/Capture update situation to e.g. FrameMaker. I am also an ex-Framer.

The deal-breaker is that you can't merge your new (script-generated) screenshots with existing, already annotated images - i.e. I am assuming that you want to replace the screenshot, but keep the annotations. But Capture won't allow that.

I started thinking about why Frame can do that and Capture/Flare can't. I think the answer is that a new capture (in Capture) or even a File > Open, sets the image automatically as part of the background. However, what we need is for that capture or opened image to be set as an object layer on a default transparent background.

If your main image is a layer instead of the background, well then you can very easily replace that image and retain all existing callouts: use the Insert Image function in Capture to add the new image (updated screenshot), then align it with the old image, then delete the old image (you are just deleting the layer, so the old image disappears, but all callouts remain). The new image also needs to be "sent to back", but now Capture is starting to behave a little bit more like an image editor.

(But not quite - you can't specify a custom canvas in Capture, which is why you need to add the new image before deleting the old one. If you do it the other way around, the canvas auto-shrinks and moves callouts around - naughty. But I love Capture's auto-sizing canvas.)

This is a bit long-winded, sorry, but to complete the loop: I need a way of starting Capture with a default transparent background instead of a capture. I can do that with a small template file - e.g. a transparent PNG 50x50 px. The dimensions don't matter as long as they are smaller than my intended image. Then I can just add my capture as a layer, either by inserting an image (non-Capture) or by inserting a capture using Capture itself.

It seems like a lot of fuss, but I don't think it is, and once set up, the image is good to go for the lifetime of screenshot updates or callout edits, as per the normal Flare<>Capture process. And, it would also work with external file sync if that is required (remember to sync the props file also).

So, that's my idea. I think it would work for you Shawn, if going back to Frame is not an option.

[sdcinvan]

Hello Tom,

Thank you for that detailed description. I will definitely experiment with your suggestion over the weekend.

Appreciate your assistance.

[atomdocs]

Well, the great thing about participating on this forum is that it causes us to learn new things - and I just have!

Please ignore my previous post. I have just learned about the Replace function in Capture.

Replace actually does precisley what I was trying to do with layers, but it is of course much easier and means you don't have to mess about with updated screenshots as layers.

The Replace function simply lets you replace the background image. It maintains all the existing Capture callouts or objects and updates the props file properly. So whenever you get a new screenshot, just hit Replace to drop it in.

I should never have doubted Capture. I should simply read the documentation

[doc_guy]

I think the problem with Replace, in the context of this discussion, is that it is still a manual process. I believe Shawn is hoping for an automated solution so he could just update the image file with the updated screen shot, and the annotations and such would automatically update. He's got a tool that takes the screen shots automatically and dumps the images into a folder. But it is a laborious process to go into each image in capture and replace the background image

[atomdocs]

Paul, I agree, if Shawn's process is fully automated, triggered by the script image dump, then Capture isn't going to get near that. I was hoping to get a little closer and clear some of the frustration that Shawn has. From what I see in this discussion, Shawn might be doing some manual editing anyway after screenshot updates.