Pages: 1
Print
Author Topic: Issues with cross-file reference check and spelling in 7.0  (Read 3143 times)
jlm05
Member

Posts: 79


« on: August 09, 2012, 01:07:49 PM »

A couple of our writers have run across some strange behavior when using the cross-file functions.

For both the cross-file spell check and reference check, if there are issues, XMetaL returns incomprehensible error messages.

Also, the cross-file spell checker adds a bizarre DTD file  - xxx.$$$.dtd  - to the src directory for each file in which there was a spelling error.

Any idea why this is happening?

Thanks,

Janice
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #1 on: August 09, 2012, 05:52:14 PM »

Can't reproduce this here yet.

The $$$.dtd issue is standard behavior for another feature (XMetaL needs this when you edit a file as well-formed), so maybe it has been triggered somehow while your files are being loaded into the process that performs the spell checking / find. However, at this point I can't understand how that might occur.

Can you give us some examples of the error messages you are seeing? That might give us a clue as to how to reproduce your issues.

In addition, where are your files stored? Perhaps there is an issue with paths / file names / folder permissions / network access rights / CMS conflicts / etc. If you could give us the full path for any files that have issues that might point us in the right direction.

If specific steps are required please let me know. This might include certain files (file names, file content, specific DTD, etc), files stored at certain locations, a CMS integration or other 3rd party software must be installed, or maybe a specific way of starting the spell checking or find in files features is necessary, or you need to perform specific actions just prior to doing it, etc.
Logged
jlm05
Member

Posts: 79


« Reply #2 on: August 10, 2012, 11:58:04 AM »

So the information I've been able to get so far - the DTD file issue and the bizarre error issue seem to be separated and experienced by different people.

For the error issue, the errors being displayed are null-pointer type errors. The writer will try reinstalling to see if that helps.

Our general structure is to have the main bookmap and online map at the top level of a directory, with map, src, images subdirectories.

bookmap.ditamap
online.ditamap
/images
/maps
/src

The writers seeing the extra DTD files generated from the spell check are seeing it whether they run the spell check across a bookmap or a collection or unit map.

The procedure is pretty straightforward:

1. In the map pane, open book-level map.

2. Choose Tools > Spell Check in Files

3. The Apply to field defaults to the booklevel map.  Leave selected.  Leave Include subfolders selected.

4. Click Spell Check button

As spell check runs on each file, the <filename>.$$$.dtd file is generated in the src directory for each file that has spelling errors.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #3 on: August 10, 2012, 05:36:09 PM »

Are these files stored in a network share or on the local drive?

One thing you can try (to avoid the $$$.DTD file creation) is to disable a feature that allows searching for "default" attribute values (fixed and default values set in a DTD but that are not present in the XML source). For XMetaL to find such values it must load the DTD, however, if the DTD cannot be found for some reason (path issues, catalog issues or perhaps something else) it will open the file as well-formed and this is when these extra files are created.

To turn off this feature:

1. Alt+S.
2. In the "About XMetaL Services" dialog select "Multiple-File Operation Services".
3. Click the "Extended Info" button.
4. In the dialog that appears uncheck the "Include defaulted attributes from the DTD" checkbox.
5. Click "OK" and then "Done" to save this setting.

I would be interested to see what the DOCTYPE declaration in one of the files that triggers this issue looks like. Since it is DITA it should probably have a standard PUBLIC ID (and corresponding SYSTEM ID value) and XMetaL should normally be able to locate the DTD in this case. If the file can be opened and edited without errors then that should be the case, but perhaps there is some special case where the parser we use for these "cross file" operations cannot read it correctly.
« Last Edit: August 10, 2012, 05:42:48 PM by Derek Read » Logged
Pages: 1
Print
Jump to:  

email us