Replace Element by Element

[Pinpin Philippe]

Hello,

When opening XML in FM, sometimes, FM can't apply correctly the EDD to my document.

Example on a book of 1.500 pages there can be around 20 superscript text that are display as normal normal text.

The only way i found is to forced FM to apply the EDD correctly by forcing him with Searching&replacing the <sup> element.

Or faster, replace the HighestLevelElement on each chapter (element call <CHAPTER>)

Would like to do it with a script (so i can add it to my open book script ... there are around 10 script at the opening of a book

I can select all the doc, get the HighestLevelElement name, can delete it or warp an element around it but can't replace the element by it self?

var vCurrentDoc= app.ActiveDoc;
var vFlow = vCurrentDoc.MainFlowInDoc;
var vPgf = vFlow.LastTextFrameInFlow;
var vFirstPgf = vFlow.FirstTextFrameInFlow;
var textRange = new TextRange();
        textRange.beg.obj = vFirstPgf;
        textRange.beg.offset = 0;
        textRange.end.obj = vPgf;
        textRange.end.offset = Constants.FTI_PgfEnd;
        vCurrentDoc.TextSelection = textRange;
var vElement = vFlow.HighestLevelElement;
var vElemDef = vElement.ElementDef;
var vReplaceElem = vCurrentDoc.GetNamedElementDef(vElemDef.Name);
// vReplaceElem.Delete() or WarpElement();

So how to eaplce an existing element by itself?

[4everJang]

Philippe,

I have never found a case where FM did not correctly apply the EDD. I did find cases where the result of the EDD was not always as I expected it to be. Scripting is not the solution here. Checking the rules in the EDD that apply the formatting is. They can be complex and you have to take all corner cases into account.

In a document where the <sup> is not showing up as exptected, check the character format that is being applied to that piece of content. If the character format for <sup> is not applied, there must be a case that your EDD rules did not cover.

One more possibility is that you do not have the correct doctype declaration in the XML documents. These tell FM which structured application to use, which in turn determines which template is being opened, and that template has the EDD applied to it. Check everything else before trying to script a solution for a problem that is caused by some detail in your setup.

If you cannot make it work, you can contact me off-list and I will see what I can do. Depending on the amount of time it takes to make it all work, there might be a justified fee for that work. But if it removes the need to do a lot of scripting and checking each time when you open a book, it might be worth the investment. You can contact me via jang at jang dot nl.

4everJang

[Ian Proudfoot]

I was just about to post a similar message to Jang's. One thing I would also advise is to make use of the Show Element Context pod. If you are seeing different contexts for some of your <sup> elements it could be that you have no formatting for some of those contexts.

[frameexpert]

Did you try File > Import > Element Definitions, then check Remove Format Overrides and click Import?

[Pinpin Philippe]

Hello all,

4everJang,

We already check the EDD, templates, maker.ini config, doctype, ...

We don't use style in the template, we configure all our paragraph style and character style with the EDD ... who's 250 pages heavy (the same EDD work for 5 differentes templates).

When changing element by themself, the character format / Paragraph format is apply correctly to the element (and the element inside them).

If it was a rules in the EDD that was not check, it will never apply the correct format when replacing the element ?

Ian Proudfoot,

Yes already check the Element Context Pod, and it show the right rules.

framexpert,

When we Import again the EDD (used to open the XML) into the doc with Remove Format Overrides check, he apply the right format at the element (same as if we replace the element by himself), even if Remove Format Overrides is not check.

Maybe because we use heavily FM Structured (book with 4 document or more than 70 document, each document with 3 elements to 465.000 elements (around 1200 pages for one chapter)... with 3 level minimum to 12-15 level maximum in each document) sometimes take 8 hours to open the XML and apply pagination, numbering, apply master pages, deleting white pages, ...)

So I'm looking to make a script that make all our open procedure automatically so we don't need to stay in front of FM just for some intervention. And there is the element replacement problem

PS: sorry for my english, it's not my mother tongue (french)

[4everJang]

Hi Philippe,

Sounds like you have a bunch of processes that need optimisation at some point in the future, as this does not seem to be a viable situation for much longer.

It could be that some of the processes in place make changes that are not registered by the right processes in FrameMaker as being changes, and therefore do not lead to re-application of the rules from the EDD.

But as you indicate (in your reply to FrameExpert) that re-importing the EDD manually fixes the problem, there may be an easy method to fire this action after the document was opened. In scripting, you can create an event handler for the XML document opened event, which then re-imports the EDD from the document. You can first try to re-import the element definitions from the same document (not an external EDD) and see if that corrects the formatting. If not, you need to open the master EDD and import the defs from there.

If you need help creating an event handler for this, let me know.

Ciao

[frameexpert · Accepted solution]

You can certainly script the importing of the element definitions:

doc.SimpleImportElementDefs (template, Constants.FF_IED_REMOVE_OVERRIDES);

You don't even need to open the EDD or template. You can just do this:

doc.SimpleImportElementDefs (doc, Constants.FF_IED_REMOVE_OVERRIDES);

-Rick

[Ian Proudfoot]

One trick that may help for very large documents is to use two EDDs. The first EDD contains no formatting rules and is imported into your structured template. The second EDD contains all formatting rules and is imported into the document once it has opened.

I did this for a very large structured document and it reduced the total opening time from six hours to just over five hours. However this was back on FM+SGML 6.0 on Win 2000...

[4everJang]

I have always kept formatting strictly in paragraph and character tags, which are called out by the EDD. This also allows having multiple templates with different formatting but all using the same EDD. Makes life a LOT easier, as doing direct formatting in the EDD is a pain in the butt and asking for trouble. Plus, I got to do the EDD as a consultant and the customer did not need to call me in for every tiny formatting change they wanted to get. 

[frameexpert]

I also follow this approach. The only exceptions I make are for page breaks controlled by attributes and "specialty formatting" like extra space after the last list item. Sometimes I will specify formatting for these things in the EDD instead of creating a special paragraph format.

[Pinpin Philippe]

4everjang

No, it's not a viable situation ... juste like that for over 10 years, but before i haven't the time to look at the process (i wasn't not the guy that made the EDD/template/... at the beginning).

frameexpert,

I'll try that next week.