🚀 go-pugleaf

Hi Alex,

* For the NAMELEN problem, you can fix it by setting up a structured application for importing your SGML and specifying your own SGML declaration which sets NAMELEN to some larger value. In the DocBook SGML Structured Application that comes with FrameMaker, NAMELEN is set to 239, which is the maximum, so you could reference that declaration in your structured applications definition or make your own SGML declaration and use that. FrameMaker uses a default SGML declaration if you don't specify one; I believe that the default value is 8, as specified in the reference concrete syntax (from memory, could be wrong), so if you have any NAMEs longer than 8 characters, FrameMaker will complain.

* For the DTD path, you could edit the SGML file to point to the location of the DTD on your system, and you can also specify the location of the DTD in your application definition.

* As for the errors when opening the DTD, it's hard to say based on your description.

* For your question on how the SGML was correct in Epic but causes errors in FrameMaker, the thing with SGML is that it's a amazingly configurable standard: you can change loads of things, and so the defaults are only helpful in circumstances where the supplier of the document didn't do anything too "whacky". So it may well be that the document is correct when viewed in Epic.


Jon

John,

In Relation To #3, sorry for being vague. It seems that #1 answers a lot of #3. Most of the errors appear to be name length exceeded limits. There are a few invalid characters which were ignored. It was expecting an MDC delimiter a few times. A few incorrect markup, markup terminated. There were also a few Entity nesting level out of sync errors. But probably 95% of the errors in the DTD file were NAMELEN longer than the default.

Per #4, what would help ameliorate this problem? Should I attempt to get the structure/environment in addition to the SGML files or would it be easy enough to (re)create the proper structure.

Sorry if I sound like I don't know what I'm talking about, Frame maker/SGML isn't what I normally do, it's just I was the only one with a programming/CS background.

Hi Alex,

It's hard to say what your best bet would be to get these files into FrameMaker. It depends among other things on:

  * Do the files have to be saved back out to SGML after you're done with
  them, or is this a one-way trip? If you have to round trip them back to
  SGML, you probably have less scope in what you can do to the files.
  * Is this a one-off, or is it a regular job? If it's a one off, you may
  be able to get away with hacking the files; if it's a regular thing, you
  may want to automate it somehow, by processing the SGML files using a script
  or via the import process.
  * How many files are there to be processed? If there are only a few, then
  editing them by hand to suit your purposes might be the way to go. If there
  are many, then an automated solution (again, scripting or via the import
  process) may be better.

As you can see, there are overlaps in the points above. I'm sorry that I can't be more specific � if you consider the questions above and come back with more queries, then someone here may be able to point you in the right direction.

Jon