Document reporting the challenging way

[Oliver F.]

For some years now I am riding the document generation challenge through several companies and versions of EA and I can proudly say that I have mastered various cliffs to gather lots of expertise in that field. Still I have to admit the EA still surprises me with good old bugs I have encountered before and new issues I haven´t seen before.
Lots of things have changed in the last years to the positive, the editor has new features improving the template creation experience, we now have fragments (great thing) and stylesheets (also great thing).

On the other hand we still do not have  a reliable way of creating documents which look the way they should. First of all  I can still fool the editor (or the editor fools me depending on the point of view) by moving around items up and down the sections list which suddenly leads the editor to extend the SSBookmark style to sections it does not belong to thus marking these as protected text. The other way round I can remove line breaks under certain conditions in the template which also confuses the editors handling of the SSBookmark style. OK, I can get around that, this one is an old one. I got used to.
Another old topic is the section numbering between MS Word and EA which often enough messes up and requires careful fine tuning between the styles on both sides, especially (at least it seems so) when non-English installations are involved.

But a very new friend of mine appeared just today: I am able to create the (virtual) document using the same style, templates and stylesheet as RTF, Word and PDF and they look completely different.
First of all the .docx has lost all styles in the process. No styles (Heading 1,...) can be seen in the style bar if I am using our custom stylesheet. No, the sheet is ok. It has all those styles in it and I can see it in EA in the preview. The styles in turn are correct when rendering the same document as RTF. In RTF on the other hand there are no longer tabs and spaces in the style after the numbering which in turn the docx has. Fun fact: The chapter numbering in both documents starts with 1, but not in their ToC where Heading 1 starts with 3 which in turn is nowhere set in any list level and list override.
The docx in turn has no level numbering below level 1.
And the pdf document in general starts numbering with 3 while looking almost perfect in any other aspect (if we ignore the fact that the image caption now uses level 1 numbering which is also never set in any style in any template).

Don´t get me wrong, EA is still a superior product and the document generation is rather helpful. On the other hand it is highly disappointing to see the old problems still being alive and that I still have to find out which issue is caused by me and which one is EA specific by time-consuming investigations. I wished I could solely focus on improving templates and not chase issues between myself, EA and MS Word 2010.


Oliver

[Geert Bellekens]

I feel your pain.

There's currently a bug in the latest v13 version (1310) where the diagram.Figure field doesn't work anymore when opened in MS Word. It just shows the fixed test "diagram sequence".
It works in Libre Office (yeay ), or when printing to RTF or PDF, but when when printing to .docx and opening with MS Word (which is with 99% of the customers is using).
Sparx promised me to fix it in the next release, but unfortunately that next release is now a 3.5 beta, which I can't install at my clients either.

Result is that most of my clients are still on v12.1 

Geert

[Oliver F.]

There's currently a bug in the latest v13 version (1310) where the diagram.Figure field doesn't work anymore when opened in MS Word. It just shows the fixed test "diagram sequence".

Ah, yes, I noticed that one yesterday, too.
As well as the fact that the ToC sometimes uses a different numbering scheme than the heading styles- In the document I can see 1.1, 1.1.1,1.1.2, 1.2, 1.3, 1.3.1,2, etc.
The ToC renders it like 1.1, 1.1.1,1.1.2, 1.2, 1.3.1, 1.3, 1.3.1,2.1.1, 2, etc. It spontaneously seems to increase some levels and then return back to the sequence even if I am updating the ToC in Word over and over again.

Section numbering is the biggest PITA in the whole document flow as it produces inconsistent effects across the documentation toolchain most of the time and it´s been like this for a very long time now.

If you are free enough to choose the way how the documentation should look like you can start from ground with new templates and fragments.
If you want to produce documents according to a certain existing documentation standard/structure because you have to stick with safety rules et al. things are becoming quite inconsistent.

Oliver

[Geert Bellekens]

The numbering issue can be solved if you use the same numbering list override for all your numbered lists.

At least we don't have any issues with the numbering anymore since we discovered the magic touch. (and we do a lot of document generation )

Geert

[Oliver F.]

Well, in fact it does not. We use the standard styles and lists (overrides) for all templates and then apply the corporate stylesheet to them at generation time.
It now works when basing the corporate sheet on the EA default ones and then adjusting the fonts. Importing the numbering scheme from a different style rtf breaks the list overrides and produces the results mentioned above though there is no indication when editing the list levels and styles why this is the case. Looks like some internal tables are being messed up.
At least numbering is ok now though some issues still apply like frames in the header being resized at certain pages only and only in the PDF and .doc files or styles in the .doc being lost.

As a matter of fact importing styles from external documents can really mess things up and this is not the first time I come across this.

Oliver