General XMetaL Discussion
jlm05 August 9, 2012 at 7:07 pm
Issues with cross-file reference check and spelling in 7.0August 9, 2012 at 7:07 pmParticipants 2Replies 3Last Activity 10 years, 5 months ago
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?
JaniceDerek Read August 9, 2012 at 11:52 pm
Reply to: Issues with cross-file reference check and spelling in 7.0August 9, 2012 at 11:52 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.jlm05 August 10, 2012 at 5:58 pm
Reply to: Issues with cross-file reference check and spelling in 7.0August 10, 2012 at 5:58 pm
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.
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
.$$$.dtd file is generated in the src directory for each file that has spelling errors.Derek Read August 10, 2012 at 11:36 pm
Reply to: Issues with cross-file reference check and spelling in 7.0August 10, 2012 at 11:36 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:
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.
- You must be logged in to reply to this topic.