_nc added to gif file name

[LRowan]

Hi,

Here's another of RH's peculiar code-changing or file-changing quirks. I've been using several gif graphics in my help systems for over a year, and all of a sudden, RoboHelp has begun changing the file names of some of them by adding _nc just before the extension. Therefore, a graphic called new.gif is now called new_nc.gif in the WebHelp folder. Obviously, this breaks the link wherever I use the graphic. I've tried adding the graphic to the baggage files, and this still doesn't prevent it from happening. Has anyone had this happen? It only happens in one of my help projects so far (I have three of them that use many of the same graphics). Anyone have ideas?

I sure hope Adobe fixes stupid stuff like this. Basically, the only workaround I can see is to change the name back to what it should be after generating WH.

Thanks,
Lisa

[MergeThis]

Ah, the old "RH all-of-a-sudden" trick again, eh?

Lisa, it's quite likely that this arose after something you or your IT folks have done (changes in networking, permissions, etc.). Are you re-importing Word docs reviewed and marked up by others?

Come back with more details of your environment, so that we can help.


Good luck,
Leon

[LRowan]

Hi Leon,

Thanks so much for responding!

Everything here's pretty simple, I think. I use RH X5.0.2. No Pro version. Everything runs off of my C drive, and I back the help projects to the corporate servers after working on them. I don't reimport topics after reviews. Instead, I either print them (if only a few) or generate a Word document, and then make changes manually. (I'm a lone writer, so no editor to write wording changes. My reviewers tend to make comments and leave it to me for wording.)

Funny thing is, a short time ago, I generated the two conditional builds of one of the projects for our Test environment, and the _nc problem happened on only one of the generated help systems. The other one had the gif by the correct name! The last time I generated (two weeks ago), the _nc problem happened in both versions. It seems to follow no logic... just happens when it wants to.

As for permissions, networking, etc., I'm seeing this problem on my C drive. It's not just out in our environments. I generate my two conditional builds, and then go into the WebHelp folders on my C drive and see the problem there. So it seems to happen in the generating process, not during migration.

Please let me know if you need any other info....

Thanks again!
Lisa

[MergeThis]

Try a simple fix first, to see what happens: generate and publish to entirely new folders. If the problem doesn't occur, generate and publish to your original output folders after you've completely stripped all the files from them.


Good luck,
Leon

[LRowan]

Hi Leon,

Actually, I tried something similar to your suggestion before my original posting: I completely deleted the output folders from the SSL! folder and let RoboHelp recreate them. This didn't fix the problem at the time (_nc problem was still in both outputs), but when I generated again later for Test, I had one come out okay (no _nc problem).

Now, I followed your directions, and both systems have the _nc problem again.

A similar thing I've noticed now and in the past (but it didn't seem to hurt anything) is that RH would make a copy of other files and add weird letters to the end of the file name when generating. It does this with css files I created (adding _ns to the name), the main help htm file (two copies with _csh and _rhc), and some htm topics (adding _text0). So, for example, in the output fplders, there's topic.htm and topic_text0.htm, styles.css and styles_ns, and mainhelp.htm, mainhelp_csh.htm, and mainhelp_rhc.htm. I wasn't sure if any of these were "normal" for RH to create (except the _text0 one didn't seem right). Because these were copies, they didn't break any links, so I tried not to worry about them. The only reason it's a problem now is that it's not making a copy of this one gif file. It's actually changing the file name.

I hope this additional information helps...

Thanks again,
Lisa

[Captiv8r]

Hi Lisa

I'm obviously not Leon, so I hope he'll pardon my intrusion into his thread.

The files you see with style sheets where RoboHelp creates _ns are there to hopefully better accommodate NetScape browsers. One of the first things WebHelp scripting does is to try and determine which browser is in use. If it's NetScape, the _ns style sheet is used.

The topic_text0 (and topic_text1 and so on) files are usually where text only popups occur. Each is created as a different HTML file and is used.

The _csh and _rhc variants, I'm at somewhat of a loss to explain exactly how these come into play. I believe the _csh deals with Context Sensitive Help (hence the CSH) but I'm totally unsure about the _rhc.

Without seeing some code (both before and after) for the _nc renaming, I'm at a loss as to what may be happening. Is there a way you could post the simple code of the image in the topic before renaming occurs and what it looks like after? Maybe this would provide some clues?

Cheers and happy Friday, all! Rick

[LRowan]

Hi Rick and Peter!

Thanks for jumping in... This is actually a graphic used in the TOC to signify a new topic. It has a little red star and is based on a "cool trick" article Rick (I believe) had about marking new topics as "new." The graphic is referenced in a whthost.js file that I copy into the WebHelp folder and overwrite the existing one every time I generate. I have the gif in the baggage files. Normally, I have no references to it anywhere else in the help system. However, I did a test a short time ago to see what would happen if I put a reference to the graphic in a topic and then generate it. Would it recognize the gif belongs as is and copy it over, unscathed, or would it break the link. It turns out, it did something else. Here's the code for the ref in the original topic (pre-generation):

<img
src="Availity_Blue_Page_New.gif"
x-maintain-ratio=TRUE
style="border: none;
width: 18px;
height: 16px;
float: none;
border-style: none;"
width=18
height=16
border=0>

In the generated version of the topic, the code looks like this:
<img src="Availity_Blue_Page_New_nc.gif" x-maintain-ratio="TRUE" width="18px" height="16px" border="0" class="img_whs4">

The graphic displays correctly in the generated topic and, as you see, it references the _nc version of the gif. RobotHelp actually changed the reference in the topic to point to the renamed gif. However, the whthost.js file (the one I created a year ago) has the file name without the _nc extension, so the graphic doesn't display correctly in the TOC.

I suppose I could just change the file name in the whthost file, but because this problem occurs only sometimes, I still might have a broken link to the file.

One more thing: Peter, you wrote: "If you give the startpage of a webhelp project the same name as a topic in the root folder, usually the default topic, then RH does create a file with a "name variant"."

Funny you say this, because the funky naming with the _text0 occurs most frequently on a topic that USED to be my start page. It's no longer my start page, though, and the start page I use now doesn't have funky naming variants.

I'll try generating to a folder outside !SSL and also the new project idea on Monday, per Peter's suggestions. I'm going home for the weekend soon.. brain-fried. I appreciate your help, Leon, Rick, and Peter! More on Monday.... Have a great weekend!

Thanks,
Lisa

[Captiv8r]

Hi again Lisa

Allll-righty then! Seems my theory was correct in the sense that _NC is being used as "New Copy". So please now allow me to adjust a bit.

I'm now theorizing that because the image is being used inside a topic, this is where the _NC comes into play. You now have an image in a topic with the same file name as an image used in the WebHelp system. As two images cannot exist differently and use the same name, WebHelp kindly renames the image to _NC and off you go. Okay, I'll now test differently.

Cheers... Rick

[Captiv8r]

Hi again all

Okay, just tested by copying one of the elements and using as an image inside a topic. I used the book image and it was named wht_toc1.gif. Created a TOC with books and pages. Genned WebHelp. All came out fine, but the image was indeed copied and renamed to wht_toc_nc.gif.

Now that we know how and why this is happening, I guess the only question left to answer is why things are breaking for you. I do know that one easy way to prevent it is to simply save a copy of the image and give it a unique file name.

Just a thought... Rick

[LRowan]

Ack! Yes, I'm still here!

One thing Rick said about duplicate files makes me wonder... I did some quick research, and discovered that all of these gifs with _nc at the end are referenced in two places in my project: in the skins folder and in the top-level folder of the help project. I have some of the graphics in my top-level folder because I imported them into a help topic about how to use the help system. I give a picture, for example, of the TOC button and explain how the TOC works. I recall that a year ago, I wasn't sure if I could import graphics in the Skins folder, so I have a copy of them in the top-level folder, too. I'm guessing when it generates WebHelp, RoboHelp moves those graphics out of the skins folder, encounters a file of the duplicate name in the top-level WebHelp and adds _nc to one of the copies. Sure enough, when I open the generated "using help" topic, the graphics it points to are the _nc versions. Incidentally, for some reason, the generated skins folder has only 1 of the 23 graphic files; the one remaining does not have an _nc clone in the WebHelp folder.

So, my guess is that I need to have only one copy of these graphics in my help project. Does this sound like the cause of the problem? If I remove all of these skins-related graphics from the top-level folder, is it okay to import the graphics from the skins folder, even though RoboHelp seems to like moving these graphics out of the skins folder when it generates WebHelp? If I can't refer to them in the skins folder, I could rename the ones I refer to in the top-level folder, so RoboHelp doesn't detect duplicates.

Okay, NOW I'm going home! 🙂 Thanks SO much!
Lisa

[LRowan · Accepted solution]

Leon, Rick, and Peter, thank you all for responding and helping me. You helped me figure out what the problem was, and I really appreciate it.

Here's an update on the resolution, just for the record. For gif files used in the skins folder and found in the top-level folder of my project, I removed the gifs from the top-level folder and reimported any in topics from the skins folder. The gif that was the original culprit (...the BluePageNew one) was not used by the skin, but was in the skin folder, so I deleted it from there and kept it in the top-level. When I generated WebHelp, RoboHelp copied all of the skins graphics and put them in the top-level folder, and automatically pointed the imported references in the topics to those copies. All seems to be well now. No _nc file names and no broken links.

Thanks again!
Lisa

[Peter Grainge]

If you give the startpage of a webhelp project the same name as a topic in the root folder, usually the default topic, then RH does create a file with a "name variant". The _ns is a copy of the style sheet that RH creates for Mozilla (Netscape) browsers. That is another scenario where RH correctly creates a file with a name variant.

Leon suggested creating a new folder. Can I suggest you make that outside of the project and generate to that instead of to something within the !SSL! folder within the project.

Also create a new project and import a topic that has a graphic that is suffering from this problem. Does the problem go away.

Finally, do you have access to something like FAR, a multi file find and replace tool? If not use RH's own tool. Search in all topics for the filename_nc.gif. just to make sure there isn't somehow a reference to such a file. Yes I know it is not logical.

[Captiv8r]

Hi all

I've been pondering this a bit further and I think I have a theory.

Lisa, is it possible that you have enabled "Use Lowercase File Names (Recommended for UNIX) when you publish? If so, here is my theory.

I'm theorizing that if you perhaps saved an image using the name SomeImage.gif and have referenced it in multiple areas using variants such as someimage.gif, that RoboHelp may see this and make a copy. I'm theorizing that just maybe the _NC means (New Copy). This option converts all references to lower case, because SomeFile.gif, Somefile.gif, somefile.GIF and somefile.gif are ALL different file names to UNIX. Sooo, I'm wondering (haven't yet tested this) if during the process of conversion, one reference was found and adjusted, then another reference spelled differently (case only) would cause the _NC to be produced.

Just thinking out loud here... Rick