This content has been marked as final. Show 8 replies
"Can anyone think why Robohelp X5 would 'bomb out' ..."
You've answered your question by referring to moving images around outside RH. RH maintains a database of where the images are and now you've got the elves inside that database totally confused as to where the images are. You say you refreshed the image properties. How did you do that?
Ahhh...RH uses elf technology too lol.
I used the term 'refresh' instead of 'rename'. i thought i could be clever (and quite obviously wasn't lol) and perhaps rename the broken image links to what the new image file name is...
we have restored our project to a version prior to my image changes so hopefully it will all work again.
question though...if we currently use bmp files for our images and want to change to png files is there a specific elven way of doing that without having to edit each topic to bring in the 'new' image file? we did try a bulk update of the htm files to change references from bmp to png but robohelp didn't seem to want to display the images - even though they were in the correct directory.
If you are talking about lots of images, you could try this after creating a backup somewhere safe.
Generate a chm output regardless of what your normal output is.
Trash the CPD and XPJ files.
Use PaintShopPro or similar to change the file type of your images.
Use a multi file Find and Replace tool, not the built in one, to change all references from .bmp to .png
Open the project using the HHP file.
Hopefully all will be well.
If not, you have that backup.
Thanks for the suggestion Peter
Once we've done this are we committed to opening the project using the HHP file for all eternity?
For starters, the answer to your question to Peter is no. You will not be forever tying yourself to the .HHP. This simply gives you an avenue to sort of "start over" with your project files if you suspect they are corrupt.
As for the .PNG issue, you should be aware that not all .PNGs are created equal. I've seen other reports where other users have caused RoboHelp to bomb upon inserting a .PNG created by one application, while a different application produces a .PNG file that RoboHelp actually likes. One would think that a .PNG is a .PNG is a .PNG. But this seems to indicate otherwise.
Thanks for responding. It's a bummer about the PNG thing - we got caught out the hard way after converting all of our bitmap images to pngs (a LOT smaller and better for web-based help delivery which is what we're moving to) and then using a third party find and replace tool (as Peter I think suggested). Robohelp liked some pngs but not others and I learnt a very harsh lesson in a very harsh way. Anyhoo - we reverted to a prior back up and I don't think we'll be converting over to pngs any time soon LOL - especially after reading the posts (as you suggested).
we currently push out a chm file but because of the MS security patches that get pushed out frequently we find it an inconvenience to our clients to continually run a program that we supply to change their registry settings to allow them to view chm files over their networks. We are looking to move to flashhelp (i'm trying to keep on topic here...) - don't suppose you have any image format suggestions to keep those images small for delivering web-delivered help?
ooh really dragging through the memory banks now lol.
off memory i think we had some jpegs that were larger than the bitmaps but I really can't be sure. Will compare some of our images in gif, jpg, and bmp versions and take it from there i think.
Big Thanks to both you and Peter for helping me out and helping me to understand more about robohelp and it's intricacies! Off I go into the RH wilderness ;o)