Problem saving to SGML from FM 8.0.1 and beyond

Report · Dec 24, 2008

Hello.

I'm using FrameMaker 8.0.4 (8.0p277).
When I try to save as SGML, SGML structure that my company developed and has used successfully for internal documentation for over 11 years now, I get an error message that reads "The document was saved to a temporary file, but FrameMaker can't rename it to have the correct name. The newer version has an old suffix". This message is immediately followed by a 'Save as SGML log' document whose multitude of lines are similar to: "C:\Program Files\Adobe\FrameMaker8\structure\sgml\isoents\isolat2.rw;line 3 Value (259) in IS FM CHAR rule must be between 1 and 255". There are 5 log pages of similar statements, each pointing to a different line. The number of messages exceeds the maximum so the log stops printing but there are many more such errors.

I am having great difficulty understanding this error but here's what I know so far:
1. The line numbers referenced in the log messages, line up with the lines in structure\\sgml\\isoents\\iso*.rw file that contain entity definitions whose character values exceed 255. I think this is getting into the unicode range. The line referred to in the above message reads: ""entity "abreve" is fm char 0x0103;"" These are new entity definitions, introduced with FM 8.0.1.
2. The problem actually started with the FM 8.0.1 (8p266) patch. This patch installed new iso*.rw files in the structure\\sgml\\isoents subdirectory. Save to SGML worked perfectly with 8.0p236 as installed from the CD. A comparison of the iso*.rw files for 8p266 to those of 8.0p236 reveals the difference to be these new entity definitions with character values exceeding 255.
3. A FrameMaker binary created in DocuBook structure and saved to SGML had no problem, no Save to SGML log files. I'm assuming that it uses the same iso*.rw files as my SGML application because its rule file has a "#include isoall.rw" line.

I would like to understand the behavior difference between saving the DocBook file to SGML and saving our custom structure file to SGML, if that's possible. Why does FrameMaker complain about the entity values when my SGML is saved, and doesn't complain about them when the DocBook SGML is saved? How do the iso*.rw files get dragged into the Save to SGML process in the first place?

I have a temporary workaround. That would be to create a renamed copy of the 8.0p236 iso*.rw files that were installed with the FrameMaker 8.0.0 CD and #include those files in my r/w rules. It seems like a safe decision for now but, I'm not sure what the implications would be in the long run. Any thoughts?

Regards
Chuck Vorndran
Xerox Corporation

Report · Dec 26, 2008

Chuck, <ol> <li>I have confirmed that I can round-trip a DocBook document containing the entity reference &abreve; using FM8.0p277. <li>Whether DocBook and your application interpret<blockquote><tt>#include "isoall.rw"</tt></blockquote> the same way depends on the rules search paths specified in both applications. The unmodified structapps.fm that comes with FM8 does not specify a search path. It therefore uses the default, which searches <installdir>\structure\sgml\docbook. If you haven't changed DocBook and your application does not specify a directory containing copies of the various ISO rules files, then indeed, the two applications use the same rules. <li>You mention that you are not having problems with DocBook, but you do with your application. Does your DocBook test use all the same characters as your actual documents? <li>I don't know what the significant difference is between your application and DocBook. Do the two applications use the same SGML declaration? <li>A major difference between the pre- and post-Unicode ISO r/w rules, is that the earlier version does not provide rules for characters that did not occur in the three main FrameMaker character sets (standard, symbol, and Dingbats). In particular, there is no r/w rule for &abreve. Thus, using those rules, a reference to that entity imports as a variable named abreve defined to be "<FmSdata>[abreve]". If your template does not define character format FmSdata, FrameMaker uses the character format definition in <installdir>\structure\entfmts, which is green and underlined. If a character whose Unicode representation is x103 (which is 259 decimal) occurs in such documents, it exports as a question mark. When you save your document using the earlier version of the rules, do you get unexpected question marks? If not, there should be no problem using the old rules. <li>Have you identified the characters in your FM document that cause the error messages? Does the font family make a difference? </ol> Good luck and let us know when you solve the problem. --Lynne

Report · Dec 31, 2008

Thanks for the response, Lynne. I looked at your suggestions, made some more interesting observations, but still haven't figured out why my files produce the error and the docbook created files don't.

1. ----
2. It appears that both apps use the same default path, hence the same rules. I proved that before by replacing the new iso*.rw files with the old ones with positive results.
3. As far as I can tell, by examining the text content, both documents use the same range of characters. I cant see any extended characters that might indicate Unicode in either document.
4. There are differences in the declarations. These are in the CAPACITY and SHUNCHAR sections. So, I used the docbook version for a test and ruled out any impact of these differences.
5. Im guessing my template doesnt define FmSdata. And I dont see anything in the docbook template that does so, either. Also, entfmts is actually a FM7 binary, even though it was shipped with FM 8. I opened and saved it as an FM8. This DID NOT fix the Save As SGML problem. I'm thinking that entfmts is not being invoked in either circumstance.
When I save my document with earlier version of *.rw, I don't see any unexpected question marks to indicate unresolved entities. So, this may be a safe option, after all.
6. I created a new document in both applications, with almost no content, except for a few simple English words and no extended characters that Im aware of. Save As SGML still produced the error in my applications document. I changed the font in my new document to Minion Pro, the same font used by the docbook template. It had no effect on the save to SGML.

Based on the result of getting no unexpected question marks in the SGML output when I save my application's files to SGML, my temporary workaround appears to be worthwhile. But, it still bothers me that I can't find any significant differences between the two applications in this regard. I'm figuring that the other shoe will drop sometime in the future but, its a risk Ill have to take.

Report · Dec 31, 2008

Charles,

I would debug a problem like this by simplifying both your application and the DocBook one, in small steps, moving toward making all test files--document, SGML declaration, DTD, r/w rules--the same until I found the distinguishing feature.

Have you tried running your small test document with your application but the DocBook SGML declaration? If the problem isn't with SHUNCHAR, I'd try removing all elements from the DTD and EDD that are not used in your test "with almost no content".

As far as entfmts, it's only used while importing XML. Since you are testing export of XML, you probably are not using it.

--Lynne