Internal error: "System.OutOfMemoryException"

[ryan]

I received this while compiling word output and the conversion failed. This is the only message in the log.

I have a 150g hd and only using 35g.

Anyone else getting this? I'll submit a ticket if noone knows what this is or how to solve it.

Thanks

[Richard Ferrell]

Have you updated to Flare 4.1.4? If you have, I would open a support ticket

[ryan]

Ticket submitted. I will post update.

[DurtyMat]

Does your documentation have a lot of images, specifically GIF files? We were having a similar issue with a very large project that had a lot of images and the support team came back with a "bug" in Flare that was causing it to use too much memory when dealing with lots of GIF files .... they suggested changing the GIF files to JPEGs and replacing them in the project and trying that ...

(we havent yet, cause the holidays kinda slow things down)

[Cinnamon]

Hi folks
I'm experiencing problems compiling PDF output.
My target compiles the first time I compile it after opening Flare V5, however get the error message each time I try to compile after that. I need to close and reopen Flare each time I want to compile this output.
Things are fine until Flare gets to one topic that contains 10 images. Each image is large, I've resized them using Capture so that the printed version is smaller and have also set up thumbnails for the online help output.
I appreciate that I've loaded this topic and that I've probably pushed things too far.
I used to have the images in separate topics and that worked fine, but I'd prefer to work with them all together.
I have a couple of ideas, but I'm not sure which would offer the most effective solution:

• * spilt the graphics into more than one topic?
  * save the original graphics as smaller images?
  * remove the thumbnail settings?
  * something else?

I'm using the latest version of Flare and .NET.
Could you please let me know if you have any thoughts on this?
Many thanks

Suze

[Andrew]

I would think the simplest approach -- all other things being equal -- would be to reduce the resolution (DPI) on the images, if possible. Reducing the resolution should theoretically reduce the pixel pushing that has to happen, or at least reduce the size of the image handling. Other things you could do would be to change image types (GIF or BMP to PNG or JPG, etc.).

*However*, I don't see how 10 pictures could cause an out of memory exception, unless those pictures are *huge* or you have very little virtual memory on the system (or something is sucking up all the virtual memory you have). I've compiled print topics (in 4.2; I don't have 5) that contain dozens of fairly large images (in my case, usually PNG images).

[Cinnamon]

Hi
Thanks Andrew
I've had a more detailed look. The images are around 45KB, so not that big. However, the accompanying MadCap Capture PROPS files are almost 47,000 KB each.
I think maybe that's where the problem may lie. Do you think it's worth me redoing the PROPS files or is this size not uncommon?
Thanks

Suze

[Andrew]

I can't say how common that is, because I only have my own projects to go on. My .props files are typically about 3-5 times larger than my graphics (the largest .props files I have is on the order of 500 KB).

The only explanation I can think of is that your print versions (I believe the .props file contains the "original" image as part of the file) have a very high resolution.

As a way to test, you could back up your .props files, and then remove them. At least that would tell you if the size of the .props files (or, at least, something about the .props files) is causing the problem.

[KevinDAmery]

The PROPS are probably the culprit. Like Andrew, I don't have any PROPS files here that are much above 600 KB. 47 MB would suggest either that you've captured an area the size of a billboard or that there is an enormous amount of callouts and other added elements in there. Or they could have been corrupted in some way.

[SteveS]

I'd be very tempted to open the .props file with a text editior and see what it contains.

My .props files are typically a few lines of text about properties relating to image manipulation - crop size, callouts and so on.

Given the image isaved is the image after the manipulation, I wonder if you are cropping large areas out to get the final image?

HTH

Steve

[Andrew]

My .props files are typically a few lines of text about properties relating to image manipulation - crop size, callouts and so on.

Do yours also contain the original image (inside an <OriginalImage> element)? That's what blows up the size, typically -- it's a tiff file stored as character data. That data is what enables Capture to edit non-destructively.

[SteveS]

Do yours also contain the original image (inside an <OriginalImage> element)? That's what blows up the size, typically -- it's a tiff file stored as character data. That data is what enables Capture to edit non-destructively.

You're absolutiely right - the props file contains the original image.

[ryan]

Im having this problem again a year later. Is there an image size limit for Flare? I'm wondering why this application limitation is not acknowledged or disclosed, or if its a bug why its not fixed yet...

[SteveS]

Are you still using the same machine?

I noticed it is a memory size exception, so your hard drive will have little direct impact (unless we get into a discussion about virtual memory).

You can try freeing system resources by closing down uneeded applications running in the background.

HTH