Memo type tagged values that contain CR/LF (several paragraphs) and TAB characters (indentation) are included in the generated document with these characters suppressed, compressing everything into a single paragraph.
We have included in our model system security information too. These information are dispersed in the model, many elements being affected. As notes and linked document of these elements are used for other purposes, we used memo type tagged values to enter texts longer than 255, containing several paragraphs. Now we would like to generate system security documentation, gathering all these information, but the mentioned issue makes it impossible. Is this an EA or an eaDocX issue?
I have found some similar topics:
– Blank Space and Tabs in Description Fields (#220 and replies)
– Text formatting lost in “Uses” column of Structure (#1509).
It seems that this is a general, known issue (“Generator seems to be ignoring CRLFs”, “It’s my old friend, the Word HTML interface”), fixed for some columns.
Is there a fix planned for other text type columns too?
I have just re-checked V3.4, and we seem to be correctly printing the Description field of elements, and meno-type tagged values. BUT Only where the data has been entered via the EA user interface.
It’s quite possible to put data into these fields which has been imported into EA, either via copy/paste, import via the API of other means. EA seems happy to save almost any character data in these fields, but eaDocX will only correctly print dat imported via the UI – otherwise, we’d have an open-ended requirement. I’ve had problems with this myself, and have decided that the data needs to be cleaned before inserting into EA.
For example, the ‘Tab’ character, which I don’t think can be put into these fields via the EA UI, so we don’t process it.
Thanks for the answer. Unfortunately my problem remains unsolved.
I made a more systematic testing and I see the following:
1. CRLFs in tagged values appear, indeed, in table formatting, but are lost when using inline formatting.
2. TABs can be entered on EA UI using CTRL+TAB (like in an Excel cell), (moreover LeftAlt+ can also be used to enter special characters – method accepted in MSWord too)
3. TABs are lost everywhere at document generation
(See screenshot with all relevant windows in first attachment)
4. EA RTF generator replaces TABs with spaces in Description, but keeps them unchanged in tagged values (I don’t understand this difference in handling texts)
(See same content in the EA RTF document image – second attachment)
I agree “data needs to be cleaned before inserting into EA”, but is it really a must when extracting and putting them in a document? Shouldn’t it be possible – and easier – to leave responsibility of data content fall on user’s shoulder?
Thanks for the excellent explanation.
You re quite correct: TAB characters were lost on these memo tagged value attributes. This was because EA seems to save the data in a different way from regular Notes attributes.
This will be fixed in the next maintenance release. It will be 3.4.2, so look at the website for when this will be available.
Thanks for the fix, now we can use memo tagged values for what we wanted to, though it would be nicer if TAB would remain TAB instead of being replaced by 5 spaces.
Maybe it’s my fault that I wasn’t explicit enough writing “TABs are lost everywhere at document generation”. In the attachment can be seen that TABs are missing in Notes (Description) fields too, and this hasn’t changed in the new eaDocX version.
That was the best we could do, since the tab character isn’t supported by HTML, and that’s what we pass to MS Word.
TAB characters now print correctly in memo Tagged Vales, and also in normal element Notes fields: where do you think they aren’t displayed correctly still?
Download eaTeamWorks today for several free for life features, plus no obligation, 30-day trials of all the products: eaDocX, ea Revision Manager, eaSheets, Model Expert and PortfolioManager. Discover for yourself why we sell the world’s best-selling Enterprise Architect extension.