Build failing with invalid character error

[ksoltys]

I have been trying to build WebHelp from projects created by importing Frame 8 files and every build fails with the following error:

Build_internal_error.jpg

This doesn't occur in every topic - it seems to be happening in 10 to 20 percent of our topics, and I haven't been able to find a pattern. If we delete the topic from the TOC and try again the build works. This is what the build log looks like:

Build_progress_log_error.jpg

I've created a support case for this issue but after more than two weeks I haven't had a reply, so I'm posting here.

Regards
Keith

[LTinker68]

In the second screenshot, it looks like it's hitting the error in the Managing_Orders\Viewing_transferred_user_orders.htm file. Try opening that file in the Internal Text Editor and see if you find that character somewhere in the code. If it's there, then delete it. It doesn't indicate where it occurs in the file, so you'll have to look through the whole thing. You might try doing a find in the source code for 0x11 and see if it finds it.

[ksoltys]

In the second screenshot, it looks like it's hitting the error in the Managing_Orders\Viewing_transferred_user_orders.htm file. Try opening that file in the Internal Text Editor and see if you find that character somewhere in the code. If it's there, then delete it. It doesn't indicate where it occurs in the file, so you'll have to look through the whole thing. You might try doing a find in the source code for 0x11 and see if it finds it.

Tried that. The character doesn't show up in the editor.

What we have found, is that when we import files, for some topics, the import generates an error message referring to an invalid character 0x11 at Line 1 Position 43. If you look at the content files, you'll see the first line is an XML declaration and it's 42 characters long. So the character isn't being displayed by the editor and the import appears to be putting it in the first line in some topics.

Strange.

Regards
Ketih

[LTinker68]

Well, make sure you send your source FrameMaker files to MadCap, if you can, so they can try to recreate the error on import.

In the meantime, if you delete the entire first line of the code, save the file, then reopen it, I think Flare will automatically add the code back in, but hopefully without that errant code. See if that fixes the page so you can rebuild. Although it sounds like you might have to do that on a few files, but the try it on that first file listed and if it works, then it'll fail further along in the build and will indicate the next file to fix.

[ksoltys]

Madcap's support got back to me this afternoon and provided a fix. Apparently the problem lies with one of the built-in cross-reference styles, and the fix is to remove the character from the project's style sheet. After doing this, the build works.

Keith

[ksoltys]

In a further messages, they suggested removing the \ from cross-reference formats in Frame. The \ is used to indicate a non-breaking space in the cross-reference format, for example, between the word "page" and the page number.

I tried it and it seemed to resolve the problem, although for the life of me, I can't figure out why more people haven't had this problem, as the \ is part of many of Frame's default cross-reference formats.

[LeslieT]

Has anyone found a way to include a non-breaking space in the cross-ref? I cannot seem to get Flare to do one in the stylesheet editor. Perhaps something I can do in the CSS file if I take it into Notepad or something? I really hate it when "page" is at the end of the line and the number is by itself on the next.

Keith is so right that this is very standard to have in a FrameMaker cross-ref.

[kkelleher]

Just as a data point, I'm running into this as well (so yes this is a standard Frame practice). I'll try the suggested fix and then log a tech support ticket when I know more. Interestingly, I can generate a webhelp target but not a PDF one. Does that suggest anything to anyone?

Thanks,

Kristen