TOC error

[jwatson]

Hi

I have a strange TOC error. The TOC won't open and it tells me there is an error on line 1 in position 1. The only thing I've done in the file since it last worked was open it in the Internal Editor and edit one toc entry (the text of an entry, not the tags).

I tested this by using a TOC that opens fine, copied it, then opened the copy in the Internal Editor, edited it, and now the copy won't open.
I've compared the original working TOC with the copy that won't open, and there is no different in the xml (apart from the toc entry text).

Anyone else had this problem? Any way to fix it?

Jenny.

[KevinDAmery]

Could you post the code for one of the ones that doesn't work?

[jwatson]

Here's the beginning of the file:

Code: Select all

<?xml version="1.0" encoding="utf-16"?>
<CatapultToc
  Version="1">
  <TocEntry
    Title="Edit in Editor"
    Link="/Content/1Topics/Welcome.htm"
    conditions="ProAndStandard.ACDSeePro"></TocEntry>
  <TocEntry
    Title="Welcome to ACDSee 2010"
    Link="/Content/1Topics/Welcome.htm"
    conditions="ProAndStandard.ACDSeePro" />
  <TocEntry
    Title="What's new in ACDSee Pro 3"
    Link="/Content/1Topics/IDDH_WHATS_NEW.htm"
    conditions="ProAndStandard.ACDSeePro"></TocEntry>
  <TocEntry
    Title="What's new in ACDSee 2010"
    conditions="ProAndStandard.ACDSeeStd"
    Link="/Content/1Topics/IDDH_WHATS_NEW.htm" />
  <TocEntry
    Title="Where is it now?"
    Link="/Content/1Topics/IDDH_Where_is_it_now.htm" />
  <TocEntry
    Title="Getting started">
    <TocEntry
      Title="Starting ACDSee Pro 3"
      Link="/Content/1Topics/Print_only/Starting_ACDSee.htm"
      conditions="ProAndStandard.ACDSeePro,ProAndStandard.Print only"
      VolumeNumberReset="same"></TocEntry>
    <TocEntry
      Title="Starting ACDSee 2010"
      Link="/Content/1Topics/Print_only/Starting_ACDSee.htm"
      conditions="ProAndStandard.ACDSeeStd,ProAndStandard.Print only"
      VolumeNumberReset="same" />
    <TocEntry
      Title="About the ACDSee user interface"
      Link="/Content/1Topics/1_Getting_started/About_the_ACDSee_user_interface.htm" />

Thanks, Jenny.

[Andrew]

Does your file end with </CatapultToc> ? If not, it needs to be there.

[KevinDAmery]

Looks pretty similar to what I have, so I don't think it's a code problem.

Is there anything different about the attributes of the files? For example, are some of them read only? Or, are there any temp files or the like? (I've seen Flare end up linking to a temp file before when editing it in an external text editor.) It could be that the error isn't really about the first character, but about the format or attributes and the error text just defaults to showing a character and line number.

[jwatson]

Yes - it has that for the last line. The only difference when I compared the two files in UltraEdit was the line I edited, which you can see in the code snippet:

Title="Edit in Editor"

When I edited the TOC file in UltraEdit, it opened in Flare with no errors. I only got the error when I edited the file using the Internal Text Editor.

And the reason I was doing this, in case you're wondering, is that I was cleaning up condition tags. Analyzer found one last tag, so rather than opening UltraEdit, I just opened it in the Internal Text Editor, and then I got the error. Very odd.

Temp files - interesting thought. UltraEdit does create backup files, and I've seen Flare get confused about those. But I deleted those backup files already, to be sure, and that's not the issue. I wonder if Flare is creating a backup file somewhere?
Read only - no, none of them are read only.

Hmmm - still thinking...

OK, looking for other attributes. When I open the Properties, it says the filesize is only half the size (about 50kb) for the broken toc. Odd.

Jenny.

[LTinker68]

Code: Select all

<?xml version="1.0" encoding="utf-16"?>
<CatapultToc
  Version="1">
  <TocEntry
    Title="Edit in Editor"
    Link="/Content/1Topics/Welcome.htm"
    conditions="ProAndStandard.ACDSeePro"></TocEntry>

You might need to get rid of the </TocEntry> at the end of the first block and insert a / after the conditions attribute, so the end of that block would be

Code: Select all

...
    Link="/Content/1Topics/Welcome.htm"
    conditions="ProAndStandard.ACDSeePro" />
<TocEntry
    Title="Welcome to ACDSee 2010"
    Link="/Content/1Topics/Welcome.htm"
    conditions="ProAndStandard.ACDSeePro" />

Based on my TOC, the </TocEntry> only seems to be inserted if the TOC entry is a book and has topics/books beneath it. Your first block doesn't appear to have any sub-levels, so based on the format, would not include the </TocEntry> tag, but would use a / after the conditions attribute.

Don't know if that's it or not -- that's the only difference I can see.

[jwatson]

Thanks Lisa. I wondered if it was that too, but the TOC that works has it the same way.

Here's a screenshot of what I see in UltraCompare (good TOC on the left, broken on the right) - attached it.


At the bottom it says there are 5 lines different. The first one you can see - the other four are changes I've made to the good TOC since we started talking about this.

I'm wondering about the filesize, since that's obviously different between the two files. How can the filesize be so different, if both files contain the same number of lines of code?

Jenny.

[LTinker68]

Did you try just creating a new text file, copying the code from the old one to the new one, saving the new one, deleting the old one (save a backup first), then renaming the new to what the old one was?

It could be that the TOC file itself is corrupted, although I wouldn't think you could open it if it was. But the different file size is odd.

The only other thing I can think of is that some programs don't like text files to have extraneous empty lines at the end of files. Are there any extra blank lines after the closing catapult tag?

[KevinDAmery]

And if all that fails, try opening a support ticket with Madcap and send both files to them. They're usually pretty good about determining what is wrong if it's something in the way the file was written. (Could be something in the file header that we can't see here.)

[Madcap Guru]

You could just copy and paste from the Old TOC file into a new TOC file and se if that works for you.

[jwatson]

OK - tried Lisa's suggestion.

I created a new file in Notepad, copied the text from the broken TOC, and named the file with a fltoc extension.
The new TOC file would not open in Flare.

Then I tried the same thing with the good TOC. Created a new file in Notepad, copied the text from the good TOC, and named the file with a fltoc extension.
And that new TOC file also wouldn't open in Flare.

Fortunately the good one still works!

So, I'm stumped. Will open a support ticket and let you know what I find out.

Thanks, Jenny.

[jwatson]

Got a reply from Support.

Change the first line of code from:

Code: Select all

<?xml version="1.0" encoding="utf-16"?>

to

Code: Select all

<?xml version="1.0" encoding="utf-8"?>

I don't know how it was changed to 16 originally - and I still have the one good TOC that uses the 16 encoding and works fine.
Oh well.

Thanks to Support - so fast and helpful!
Jenny.

[Andrew]

Mine is utf-16 as well. When I first saw your code, I was going to post something like "I don't think Flare supports UTF-16, that I can remember" but then I saw my TOC had the same thing.

Uh, MadCap? What's the deal here?

[GregStenhouse]

Have a read through this from the Ultraedit help, it may help understand what is going on:

Unicode and UTF-8 Support
UltraEdit provides support for Unicode (16-Bit wide character) files, and for UTF-8 files and allows direct editing of Unicode files and UTF-8 files as well as conversion routines between ASCII/ANSI and Unicode or UTF-8. UltraEdit attempts to detect the file type when the file is loaded. It will look for the FF FE marker for Unicode files. For UTF-8 it will look for one of the following three occurrences:
1) File marker (BOM) EF, BB, BF.
2) String occurrences "charset=utf-8"
3) It will interrogate the file and look for the occurrence of valid UTF-8 multi-byte characters
If the file is found to be Unicode, it will be treated as such and the status bar will indicate this with "U-" being displayed in front of the file type in the status bar.
If the file is found to be UTF-8, it will be treated as such and converted internally to Unicode (16-Bit) for editing. The status bar will indicate this with "U8-" being displayed in front of the file type in the status bar. When the file is saved, it will be converted back from Unicode to UTF-8 and saved in this format.

So, my guess is when you opened the TOC file in the internal editor, the file was converted and saved (behind the scenes) as UTF-8, even though the file still retained the UTF-16 reference up the top. That's why Flare couldn't open the file, because it thought it was a UTF-16 format but internally it was UTF-8.

(My TOCs created using Flare are UTF-16, but TOCs imported from FrameMaker 8 are UTF-8)

[jwatson]

Kia ora Greg

Interesting!! I think you're right. Something must be different in the metadata between the two files. Do you know if it's possible to view the metadata of an XML file?

Jenny

[GregStenhouse]

Kia ora Jenny, kei te pehea koe?

Open the file in Ultaedit and take a look at the status bar. If it says U8-DOS, it is enoced as UTF-8. If it says U-DOS, then it is UTF-16

Cheers
Greg

[jwatson]

Kia ora Greg

Kei te pai

You are onto something here. I just took my utf-16 toc that works ok in Flare, made a copy in Flare, edited it in the Internal Text Editor - and bam - the copy no longer works.
Then I opened both files in UltraEdit, and low and behold.....

The toc that works (and says it has utf-16 encoding) is Unicode (according the status bar in UltraEdit - it says U-DOS).
The toc that doesn't work just shows DOS in the status bar, which I think means UltraEdit thinks this is really utf-16 encoded.

Soo...it seems like the Flare Internal Text Editor is converting the file when it saves it, from Unicode (even though the first line says it is utf-16 encoded) to really be utf-16 encoded.

Jenny.

[Andrew Heard]

Is this related to the issue I posted on general discussions? Internal error: Failed to load Master TOC - #2

[jwatson]

Thanks Andrew for the heads up.

It does sound like the same thing. When I changed the encoding to UTF-8 I didn't have any more problems.

Jenny.