Ketil Albertsen wrote: > > I am using XMLmind Personal Edition 3.6.0. My documents are all XHML 1.0 > Strict files. They load into XMLmind without any error or warning messages. > > In one of my files, all <pre> elements were NOT treated as whitespace > conserving. After considerable debugging, I found that the cause was a > paragraph that was not delimited by <p>...</p> tag (the text had been > imported from a non-XHML file; that's the explanation why it had been > overlooked and was not enclosed in a <p> element), so this text contents > was placed directly under the <body> element. It occured long before the > first <pre> element, with several intervening <h..> and <p> elements. > > In all subsequent <pre> elements of the document, whitespace was > collapsed and line breaks deleted when the document was stored. When I > restored the missing line breaks and indentation by manual editing, > everything looked fine; it was not until the document was reloaded after > a store that the problem was revealed. I did, however, inspect the file > with a plain text editor after storing: The problem is is the storing, > not the reading, function. > > Files are stored in UTF8 with "PC style" crlf as line separators. Using > TextPad, I have tried storing the file using the *ix convention of lf > only as a line separator; it has no effect on this problem. > > When <p>...</p> was added around the "orphan" text earlier in the > document, whitespace and line breaks were retained. > > I did not experiment to see whether all or only subsequent <pre> > elements were affected - in my case, the offending paragraph happened to > occur before (but not immediately before) the first <pre> section. >
When XXE loads a structurally invalid document (red icon), in some cases such as the one you described, it indeed becomes completely dumb. The problem you faced has already been reported. See the User's Wish List: http://www.xmlmind.com/xmleditor/wish_list.html (first item of the "Annoying behaviors" list). Please note that being better at fixing structurally invalid documents and/or giving better diagnostics in such case have very low priority in our TODO list.
