Problem saving to SGML from FM 8.0.2

Thread View: adobe.framemaker

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Charles_Vorndran Wed, 24 Dec 2008 13:29

#1263

Author: Charles_Vorndran
Date: Wed, 24 Dec 2008 13:29

17 lines
3212 bytes

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

Re: Problem saving to SGML from FM 8.0.1 and beyond

#1273

Author: Lynne_A._Price
Date: Fri, 26 Dec 2008 23:34

16 lines
2638 bytes

Chuck,

* I have confirmed that I can round-trip a DocBook document containing the entity reference &abreve; 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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads