🚀 go-pugleaf

Chuck,

* I have confirmed that I can round-trip a DocBook document containing the entity reference ă using FM8.0p277.
* Whether DocBook and your application interpret

      #include "isoall.rw"

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.
* 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?
* I don't know what the significant difference is between your application and DocBook. Do the two applications use the same SGML declaration?
* 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.
* Have you identified the characters in your FM document that cause the error messages? Does the font family make a difference?

Good luck and let us know when you solve the problem.

--Lynne