To try to organise a little these errors, I tried to class them according to the modules to which they are "logically" related - which does not mean the error is actually due to this module, but rather that it occurs when using this module or elements related to this module. For each error, I try to give some tips, either as a workaround or to correct the effects, and also the version in which the error appears and the first corrected version, at least to my knowledge.
Before starting the list: two modules quickly essential, BOMBADIL (delivered with Calamus since version SL 96, it is also possible to download it from the site of Adequate System) which allows to fix some errors of Calamus and also to repair corrupted documents in a lot of situations, and DOKTOR (delivered with Calamus since version SL 98) which allows to repair documents, especially those coming from Calamus for Windows (which is, so it seems, totally bugged concerning the creation of vector objects...). This tow modules are SHAREWARE: do not forget to register!
All these errors have already been mentioned to Invers (perhaps am I even at the origin of their correction, who knows? My, am I modest... :-), and also a lot of others I do not detail here because they have no influence on the structure of the document or the behaviour of Calamus (mainly errors in the interface). I only mention here errors which damage the document, crash Calamus or produce an unexpected result. If you are aware of other errors, thanks to send them to me, with a detailed description and, if necessary, a sample document with fonts, I will follow it to Invers (or you can also send it directly by electronic mail: see their address on their site.
A last remark: do not rely too much on the automatic backup in _CRASH_n_.CDK: perhaps I am out of luck, but first all errors (which can destroy a document) do not always crash Calamus (which means no backup in _CRASH_n_.CDK), secondly this backup always come too late and the saved document will be unusable, because already corrupted. It happens also some times that the crash is so bad that Calamus cannot even save: either it goes into an endless loop, or the attempt at saving brings a new error which request a saving which... In short, it is better to prevent than to cure and save before the dangerous operations (and I hope that the rest of this document will allow you to better identify them, although I do not pretend being exhaustive, unfortunately).
Finally, note that when I say "every version", this implies until version SL98 include; I had not yet the time to verify the presence of these error in the August 98 version.
I will only talk here, unless exception, of complete 2 and 5 versions of Eddie, the only ones I used enough to talk about reasonably. It is likely these same symptoms occur with the intermediate versions and the restricted versions (if function is applicable).
Having give up using PKS Write for long, I will only restrict to two remarks. First, it is definitely not able to edit a text containing anchors. Secondly, Invers considers PKS-Write to be extremely buggy and stopped its development, considering that Eddie does a better job and being more reliable, and that to continue working on PKS Write would be a waste of time (I must agree on this opinion). This explains also why it is no more PKS Write but a restricted version of Eddie which is delivered with the 98 version. Otherwise, the only remembrance it left me is that it renders easily unusable texts a little long by allocating more or less at random the text styles... To summarise, a rather bad remembrance.
IMPORTANT! If you have a French version of Eddie 2 and a recent version of Calamus (SL96 from October 1997 or later), never edit and insert a chapter number in Eddie. An error in the resource yield an endless loop in Calamus and reset must be activated. The resource is corrected since version 3.
When trying to open a text in Eddie, the window close at once. Variant: the end of the text is strange (several control codes like [?0] for instance).
The problem does not come from Eddie, but from the text to be edited which has been corrupted for a reason or another. Among the recorded reasons:
Warning! If you try to edit the text directly within the text or text style module, you risk a severe crash of Calamus. It would be better to use quickly the cure described below.
It is lengthy, but probably less than start the document from scratch, or (with a little luck) the text chain already done, if it was nearly completed. Good luck in advance.
This may appears long and complicated, but it can save you a lot of hard work when the corrupted text has a complex layout (and especially anchors where the original is not out of the text, which consequently should be done again).
Of course, I do not guaranty at all this method will work in any case of corruption.
According to Invers support, exporting the text in CTD format then reimporting can also resolve some problems of this kind.
When closing Eddie, an error "document structure corrupted. Error code x" appears.
It is difficult to give a general one, since this error could have various origins (which gives different values of x). I will give here two cases I remember.
If this error occurs after having made alterations in the footer notes, especially style alterations, the risk to lose data is important. Bombadil must be called immediately, and you must request to correct the text style list - then possibly correct the foot note, generally the error does not occur again.
Another case, rather vicious, I encountered, came from an error in the text formatter, which did not like the sequence [ruler][text style] in certain given configurations. In this case, the simplest is to replace these sequences by the similar sequences [text style][ruler].
Problem with the note seems to has appeared with the version 5 of Eddie and its possibility to edit a text style from the list of style it gives (without guaranty); as I haven't be able to reproduce it in a predictable manner, its correction is uncertain in a near future...
The text formatter error should be corrected in the April 98 version of Calamus.
When moving a line bloc , Eddie beings an endless loop with the display of a progress bar.
In fact, this occurs when the block moved corresponds to the last but one paragraph of Calamus, included in a single line in the Eddie window, and is moved after the last paragraph of Calamus, which is also included in a single line. Thus, such a move must be done directly in the text module.
In version 2, it is not possible to stop the loop and a reset must be done. In version 3 light, the loop can be interrupted with Ctrl-Shift-Alt as displayed in the progress bar. In version 5, the error is cured. I cannot remember at all the behaviour of version 4.
While willing to deactivate the block, it stays active in the main window (but the begin and end mark have actually disappeared in the text magnifying glass, at the top left).
This error is only visual; I cannot remember the exact way to reproduce it, but adequate systems knows about it and assured me it would soon be corrected.
Reproduced in version 5, but probably existed before. Should be corrected in the next version (6).
When moving a set of lines corresponding to Calamus paragraphs, a set of strange control codes appears, Eddie does not go to the next line for certain end of line codes, and moving the cursor in the text shows a text "loop".
Export immediately the text in the frame (an alert box suggests this in version 4); the text is correct and can be worked on normally.
Warning! Above all do not try to resize the Eddie window, it could lend to a severe crash in Calamus.
Reproduced in version 2, exist until 5 included, adequate systems managed to reproduce it, hence is working on it (to reproduce the error has been difficult because it depends strongly on the size of the Eddie window, thus on the resolution used, and on the order of the moves...)
When doing a search (with or without replace) containing user fixed width spaces (quarter em-quad, third of em-quad,...), some occurrences are not found.
When these spaces are inserted directly from the text module, one of the two parameters (unused) is not initialised correctly; Eddie, when searching, verifies also this parameter and thus does not found theses spaces to be identical to the sear mask.
The simplest is to update Eddie: version 5 does not verify the value of this parameter when searching.
Another possibility is to replace, in the search mask, the space with a joker corresponding to all these spaces type. This requires the complete version of Eddie and, of course, that the search is not intended to find spaces with different values...
On the Eddie side, since version 5 this useless parameter is not taken into account and the spaces are found correctly.
On the Calamus side, since version 98 the parameter is correctly initialised.
When doing a search with replace, Calamus hangs and refuse to give back control. The mouse cursor takes the shape of a page, like when reformatting a page. The only way to take back control is to reset the computer.
Unfortunately, I do not have an efficient cure: I was not able to understand in what circumstances this error occurred, even if I was able to create a document where it appears systematically (Adequate should be working on it currently...). It seems nevertheless that the risks are strongly lowered if the text was exported in its frame just before launching the search, and the more complex the search (especially when using several criteria) is, and produces important alterations of the text, the more likely the problem will appear. After sending back the text in its frame, take the occasion to save...
I first encountered this problem with the version 4 of Eddie, but it is possible it exists in preceding versions (however in a more discreet way). It is still present in the last version 5 I received; I must say I was only able to reproduce it a few weeks ago, even if I had mentioned it earlier...
When trying to widen a frame from the top (resp. from the left) to stick it to a magnetic horizontal help line (resp. vertical) above (resp. more on the left), the frame is moved without its size being modified.
No real cure currently. Be certain to first stick the top left corner, and then widen from the opposite corner, and not the reverse, thus not losing time because of this error.
Reproduced with the SL96 from January 1998 (German), but probably also in earlier versions; still not corrected in the August 98 version (and it is not from not mentioning it to them, though...)
When trying to stick a frame on the grid for negatives position, the result is strange.
Try, using the periodicity of the grid, to place its origin the closest possible to the top left corner of the page (coordinate (0,0)), even if is requires sometime additional computation.
Remark. In the recto/verso mode, the grid is always symmetrical to the binding. The space between two rules from the grid is not necessarily equals to the X step of the grid across the binding. This can be surprising, at the beginning, even if it is consistent with the default coordinate system of Calamus.
Reproduced in the SL 96 version, probably present previously. Cured since SL 98 (end 97 or April 98, I cannot remember).
These functions have been added in the 96 version, thus the errors mentioned in this paragraph do not exist in the previous versions... (fine truism, isn't it?)
Making a virtual copy of a text frame having a background gives an error "structure of the document altered. Error code x".
None once the error occurred, as far as I know... Beware when copying a text frame. Otherwise, Calamus should be updated to get rid of the problem.
Cured since the October 97 version - since it is the first French version officially released, in fact this error only concerns people having a previous German version; I quote it mostly as a remark... and because it was the first error I mentioned at the beginning of my work as a beta-tester... Nostalgia...
When rotating a text frame with a background, the background is rotated twice as much as the text frame.
Prefer grouped frames to text frame with a background, if the aim is to rotate them (even if it is a little less handy because the background is not set automatically to the size of the text frame).
Corrected since the August version of SL 98.
The path of the object does not appear, or is is placed at (0, 0) when exiting this sub-module.
The vector module behaves very badly when the zoom factor is too large (the exact limit, around 3000%, depends of the document).
It seems to be corrected since SL 98.
When printing, dotted objects appear with only small portions drawn (try with a zoom factor of 600% on surface frame, circle, of 0.5 cm size, white surface, black size in large dots of 0.2 mm, to see what I mean...)
The error is due to a wrong rounding in the vector routines (I think). Rule of thumb, what will be printed is what is visible when using a zoom "printed 1:1", so look attentively what happens at this zoom level to be safe.
Generally, change the size of the width of a few tenth of millimetres enhance largely the result.
To my knowledge, every version. The error will only disappear, as other similar errors (limit to 32000 * 32000 pixels) with new vector drawing routines (according to the Calamus project manager) - perhaps in the XL version of Calamus?
That's it, my knowledge on Calamus errors ends here. If you are aware of others, do not hesitate to mention them to me. I hope the reading of this page will protect you from the rare errors which give a more or less disastrous result with Calamus. A last remark: if you work with Magic Mac, avoid by all means switching between MacOS and Magic (apple-W), this seems to strongly increase the apparition of random crashes with Calamus (I don't know if things improved with the version of Magic for MacOS 8, but in doubt...; the authors of Calamus themselves admit that Calamus is strongly instable in these conditions and put the blame on Magic. I prefer not to choose a side...).