Framemaker Crashing When Creating Element List from EDD

[ashrae-editor]

I'm a bit deep in the weeds here, and not entirely sure I'm going about this the right way.

Overall Goal: Be able to use XML/Structured Framemaker to generate Word versions of current publications directly from Framemaker, rather than Framemaker -> PDF -> Word.

Problem: I'm trying to import elements from an EDD generated from the NISO STS v1.0 tag library. The EDD, which i generated from the corresponding DTD, is 200+ pages long, and Framemaker (2015 and 2019) both crash every time I try to import elements from the EDD into a fresh document. I assume this is a memory issue, but I have no idea how to proceed. Maybe there's an easier way to accomplish the overall goal (stated above)?

Setup:

Running Windows 7 Pro, SP1 (64-bit)

Intel(R) Core(TM) i5-4570 CPU @3.20 GHz

8MB RAM

Framemaker 2015 (13.0.5.547)

(also tried it in a trial of FM2019)

I've posted the framelog from my my recent crash (using Framemaker 2015) below.

=== Header Begin ===

Internal Error: 13054, 5134708, 5135002, 8277901

FrameMaker 13.0.5 for Intel

Build: 13.0.5.547

Window System: MSWindows

Operating System: Windows NT 6.1 (major.minor.build: 6.1.7601 Service Pack 1)

Generated on: Wednesday, December 12, 2018 12:44:20 PM

To file: C:\Users\[xxxxxxxx]\AppData\Roaming\Adobe\FrameMaker\13\FrameLog_18.12.12_12.44.20.txt

Locale: English

Current Mode: Structured FrameMaker

Current View: WYSIWYG View

=== Header End ===

[Edited by moderator. No need to post all of the stack dump here. Please send the console log file to fmerror@adobe.com ]

[Amitoj]

@jmw_ashrae

Would it  be possible to mail me a sample EDD so i can try it out at my end. Also, if you could share the .dmp file with me so have someone from engg look into this

Quick question, are you using 64-bit FM or 32-bit FM (FM2019 release) ?

Thanks

Amitoj Singh

Email: amitosin@adobe.com

[Russ Ward]

Hi jmw_ashrae,

The production of Word files seems an unusual reason for this effort. Could you expand on what the goal is?

Russ

[ashrae-editor]

Russ,

Thanks for the reply. Great question.

Ideally, we'd love to be able to round-trip between Word and Framemaker, but a number of factors prevent us from doing this. We publish well over 100 documents, all of which are authored and revised by rotating committees of volunteers. The base documents are created in MS Word by our authors, then sent to our Publications staff for layout/editing in Framemaker, after which PDFs are produced from FM.

We're a membership organization. Our authors are our members, and they typically have considerable latitude in how they manage their publication files. In the past, they've resisted working from templates or using Web interfaces—basically anything that would allow us to harmonize input around a standard set of markup. To further complicate matters, the rules and procedures under which authoring committees operate are managed by a department separate from Publishing, so we, as editors and designers, are only able to impose bare-minimum mandates:

(1) Docs must come to us in MS Word format.

(2) Docs must adhere to a standard organizational format (i.e., section, figure, table, equation numbering).

Even with round-tripping off the table, there are a couple of very good reasons to try and implement Structured Authoring in Framemaker. First, we partner with a contractor to implement an interactive, Web-based version of one of our most high-profile and ubiquitous publications. Right now, with each revision of this document, our contractor has to engineer an XML/HTML framework from scratch using the most recent PDFs and Unstructured FM files, which is time consuming, expensive, and subject to error. Second, it's imperative that we're able to provide authoring committees with "clean" (i.e., most recent) versions of published versions of their documents to use as bases for future revisions. Right now we have to cobble together Word files converted from PDF or copy/pasted from Framemaker, and the amount of formatting information lost during conversion is unacceptable to us and to our authors (and the resulting docs sometimes barely usable).

I'm essentially our in-house Framemaker authority, but my experience is almost exclusively with Unstructured Framemaker. I'm reasonably tech-savvy, but my practical experience with XML/SGML is minimal, and my experience with Unstructured Framemaker is nil. We're not currently budgeted to contract this work, so I'm trying to determine exactly what we need to do to fulfill our basic needs (#1 and #2 above) with the resources at our disposal.

M

[ashrae-editor]

Russ,

I just realized the last paragraph of my reply was a bit confusing. The basic needs are not #1 and #2 as listed earlier but rather relate to the work around our interactive Web-based publication and providing clean working versions of current publications to authoring committees.

My mistake.

Best,

M

[Russ Ward]

Hi M,

Thanks for the additional information. I get it now.

The FrameMaker <-- --> Word roundtrip has always been that unachievable nirvana, at least without strict controls on each end. Especially the Word end. With markup-based content (ie, XML, structured Frame, etc.) you would be a big step closer, but still very far away. You would have to effectively put in place some kind of XML authoring architecture on the Word side, for which solutions exist but I think that your authors will completely fail to use correctly.

There are many good reasons to use structured Frame, because the markup gives you so many opportunities for advanced information management and publishing. And that sounds like what you do. Unstructured Frame is decades-old technology that is necessarily frozen in obsolete times. I like that you mentioned web-based publishing... indeed I do a lot of that and structured Frame is a keystone in the process. A lot of the work is done on the back end with XML that comes out of Frame. But also, between the world-class authoring interface and my significant customizations (FDK, ExtendScript), Frame does lots of work too. Lots of work directly related to information management, which relies heavily on the markup.

I don't have any great ideas with how to solve the dilemma of authoring outside of Frame. Without a doubt, you can be assured a cleaner output from structured Frame, whatever that output is. It's a worthy exercise no matter what... certainly a prerequisite to reaching your goal... but still leaves you a long way to go. It sounds like a great challenge, one that would take a serious analysis and certainly could not be solved with some simple advice on this forum.

I do find myself wondering why you picked that NISO definition for your first experiment. That thing looks like the most wildly complex definition that may not even help you. If it does, the burden of implementation may soar far beyond any benefits. It sounds like your case demands simplicity, especially with all the moving parts you already have. Have you considered just learning how to write an EDD, which is actually very simple? You could make it exactly the way you want, which means it will precisely serve your needs in the end.

I'll leave it there for now, to see if you have any thoughts with all that.

Russ

[ashrae-editor]

Russ,

Yea, the NISO STS includes everything and the kitchen sink. I chose it because I know our contractors have experience working with it and because it's specifically designed for the kinds of publications we produce (standards). I thought if I could create an EDD from the DTD provided and then generate an element list from the EDD, I'd be able to save myself a lot of time and effort trying to create an EDD from scratch. I imagine I could put together a list of tags, but setting up the dependencies and formatting rules from scratch is beyond my ken.

I just tried stripping out all of the elements I was certain I wouldn't need, which reduced the EDD by about 80 pages. Unfortunately, the MathML-specific tags make up almost 100 pages on their own. I can get the modified EDD to validate, but FM still crashes when I try to import the element list into a doc. Looks like I'm back to square one: troubleshooting FM.

Hopefully Amitoj​ can help me out.

M

[Russ Ward]

Well, you might be able to save some time. But maybe not. You should be aware that the DTD > EDD conversion only does the easy part... the basic structure definition. What is missing after that is all the formatting rules... that is, all the things that make the content render in a way that you can author it. And, not to mention the template to go with it. Generally, it is much easier to start from the beginning and assemble it piece by piece, IMHO.

After that, if you want to export and/or roundtrip XML, the most difficult part begins. It takes several logical components in place to complete the translation properly, whose complexity grows with the size of your structural definition. Collectively, this toolset is called a "structure app."

The crash is unusual. I doubt it has to do with size or memory. I suspect there is some complex tangle of structural logic that the application just can't handle. It shouldn't crash, obviously, but I guess with the limitless variations that can be created, sometimes it can't be 100% prepared.

Russ

[ashrae-editor]

Thanks, Russ. Looks like I may be better off putting in the work to build the EDD myself.

[Russ Ward]

So, I don't want to pretend like it is a quick thing. You will need to invest some time. But, if you want to keep FrameMaker in the workflow, I think it is well worth it. And it is not really that complex... just takes some time to learn what is going on. Additionally, you'll gain knowledge that is marketable beyond the world of FrameMaker.

I would encourage you to research further before just listening to what I say. I would hate to be responsible for the collapse of your organization, putting all those volunteers out of work.

Russ

[ashrae-editor]

I'm elbow-deep in the Structure Application Dev Reference as we type. Going to start from the ground up and go until I hit a wall. I'll be doing the bulk of my education outside of work, so the org will persevere.

Thanks for the tips!

M

[Amitoj]

Sure that works as well. Once you have uploaded please share the link with me at amitosin@adobe.com

Thanks

Amitoj Singh

[ashrae-editor]

Amitoj,

I'd be happy to send you all of these. The EDD files (one for FM2019, one for FM2015, both 64-bit) are together rather large. Would it be OK if I put them on our ftp site and e-mail you a link to download?

Question: I don't see any files in the AppData folder with a .dmp extension. Are you referring to the FrameLog files? I have several of these for crashes of FM2015 but can't find the location for the FM2019 (trial version, accessed through CC). I might need directions to locate those.

Thanks,

JMW