🚀 go-pugleaf

Thanks for the response, Lynn. 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 can�t 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. I�m guessing my template doesn�t define FmSdata. And I don�t 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 I�m aware of. Save As SGML still produced the error in my application�s 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, it�s a risk I�ll have to take.