Closed spyysalo closed 11 years ago
I'll verify where it as breaking and then assign it to me or @amadanmath.
Okay, as @spyysalo pointed out, the annotations themselves are semantically non-sense. Thus the server won't pick it up and will send it over to the client (unless verification is turned on, which can catch it). The client then goes down in flames with:
console.error('FIXME Error during rendering: ', x); // FIXME
But this does not halt the client and what the server is then getting from the client as an SVG is:
INFO:root:dispatcher will call storeSVG('<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="0" height="0"/>')
Giving the infamous SVG error. Handing this one to @amadanmath, it will be just fine if the server halts and warns if it can't render and we'll leave it at that point for now.
A fix for this one is possibly related to #131.
@amadanmath: Given that the rendering logic has changed over the last two years, is this still an issue?
No crash, sensible error messages, closing.
(Not sure if this is server- or clientside, but guessing server)
I encountered a case of broken annotation (not sure how I managed to create this) that causes the system to fail ungracefully. There is no message explaining the cause of the crash, and the client writes out "Cannot save SVG: corrupt" and goes into a state where nothing can be visualized without reload.
To replicate, create the following .txt
And the following .ann
(Here, E13 is semantically incoherent.)
This and similar cases should be handled gracefully -- there's no need to try to display broken annotation, but the system should report the problem and the interface should not go into a lock state.