Sanity checking files on open (was Re: [Inkscape-devel] zooming bug)
On 10/15/05, jiho <jo.irisson@...400...> wrote:
I am assuming that you meant to post to the list.
On 15 oct. 05, at 18:34, Ben Fowler wrote:
On 10/15/05, bulia byak <buliabyak@...400...> wrote:
On 10/15/05, Ben Fowler <ben.the.mole@...400...> wrote:
Assuming that in general we cannot expect Inkscape to determine whether or not a bounding box is insane, I was thinking that we might exclude some items from the bbox estimation to make the behaviour less surprising.
I think some could be determined at least. For example, if only one object is insane this could be found: if all transform look like 1,0,1,0,0,1 and one is 10e15,0, 10e15... it is very probably wrong. This could be detected and corrected at openning time and if the user wants to see the unmodified file anyway he could just cancel the correction. This would allow users with specific needs to edit their files anyway.
Could I make sure that we are distinguishing at leaast two cases here? The first is when a file is in error, and the fix is forced. If possible, we should always do this. (I suspect that where this is not possible, we open in the XML editor, if even this is not possible, we show a helpful diagnostic - but this is not the current topic). The second is when the file is not in error, but contains some suspicious values, and we want to warn.
This happens in Freehand when a bitmap cannot be found or a requested font is missing.
Now I think that it is often a mistake for an application to put up a modal dialog and demand that the user pay attention. In some cases. the time to warn is just before saving, or to require that the file is saved under a new name, to ensure that the user does not lose data.
If the application feels that a file has 'warnings' (non fatal errors or failure of sanity checking) there should be an annunciator in a margin that one can click on to see details. Additionally or alternatively there should be a menu item: Verify File that would check the file with great rigour. Think of it as Norton's Disk Doctor for SVG. (We have a menu item: Vacuum Defs that is cognate to 'Speed Disk').
The problem with performing rigorous sanity checking at every start-up (file read), particularly by default is that we cannot as developers really know how long this will take, but we can be pretty sure that 9999 times out of 10 000 it is not necessary: It is a little user hostile.
O.K. We can do some statistical analysis of a) The diagonals, b) The x position and c) the y position of every bounding box, and by looking at twice the standard deviation determine if the out-liers were lying out too far.
The trouble with this approach is that it is the 'fool proof' approach, just making as a system proof against a fool only works until a better one comes along, this appraoch will be defeated in the field by the great variety of insane files.
Whether we like it or not, people are going to have to be opening SVG files with text editor (or the built-in XML editor) to fix problems with insane files for some time to come. It is madness to pretend otherwise.
Having said that, perhaps Inkscape compiled in debug mode should have some of these artifical limits, (just as we have assertion statements). It will help identify to developers just where the shoe pinches, but users do not need to handle this.
Ben
On 15 oct. 05, at 20:23, Ben Fowler wrote:
On 10/15/05, jiho <jo.irisson@...400...> wrote:
On 15 oct. 05, at 18:34, Ben Fowler wrote:
On 10/15/05, bulia byak <buliabyak@...400...> wrote:
On 10/15/05, Ben Fowler <ben.the.mole@...400...> wrote:
Assuming that in general we cannot expect Inkscape to determine whether or not a bounding box is insane, I was thinking that we might exclude some items from the bbox estimation to make the behaviour less surprising.
I think some could be determined at least. For example, if only one object is insane this could be found: if all transform look like 1,0,1,0,0,1 and one is 10e15,0, 10e15... it is very probably wrong. This could be detected and corrected at openning time and if the user wants to see the unmodified file anyway he could just cancel the correction. This would allow users with specific needs to edit their files anyway.
Could I make sure that we are distinguishing at leaast two cases here? The first is when a file is in error, and the fix is forced. If possible, we should always do this. (I suspect that where this is not possible, we open in the XML editor, if even this is not possible, we show a helpful diagnostic - but this is not the current topic). The second is when the file is not in error, but contains some suspicious values, and we want to warn.
This happens in Freehand when a bitmap cannot be found or a requested font is missing.
OK with this: . if the file cannot be read if not corrected (=definition of error for me) the fix should be automatic. . if the file can be read (as it was for mine: the syntax was OK) but contains some unusual values, the correction should not be made automatically. but, in addition of issuing a warning, I think it would be great if a fix was proposed. then the user can choose to accept it (in most cases, yes) or to reject it (in this case user probably know what he is doing and will reject it if necessary). In addition to that...
Now I think that it is often a mistake for an application to put up a modal dialog and demand that the user pay attention. In some cases. the time to warn is just before saving, or to require that the file is saved under a new name, to ensure that the user does not lose data.
... the corrected file could be saved under a new name and everybody is happy with this! Then the issue on when to warn is raised. See further down please.
If the application feels that a file has 'warnings' (non fatal errors or failure of sanity checking) there should be an annunciator in a margin that one can click on to see details.
Actually, I tried to reproduce the bug and when I make a bitmap copy of a text, I _have_ a warning in the status bar: "Image with bad reference. test.svg-text13..." BUT: - I cannot reproduce the zooming bug afterwards. nevertheless I haven't reproduce the exact sequence of operations which involved editing the file on a linux box to which I won't have access before a week. - the warning is probably useless as it is if I did hit Alt+B by mistake. I would only notice it if I pay particular attention to the status bar because I "know" that something wrong is likely to happen.
Additionally or alternatively there should be a menu item: Verify File that would check the file with great rigour. Think of it as Norton's Disk Doctor for SVG. (We have a menu item: Vacuum Defs that is cognate to 'Speed Disk').
Independently of everything, this would be great. In addition it could be a common solution to many problems. Should inkscape correct? when? how? By issuing some warnings and adding this tool all these question could be answered.
The problem with performing rigorous sanity checking at every start-up (file read), particularly by default is that we cannot as developers really know how long this will take, but we can be pretty sure that 9999 times out of 10 000 it is not necessary: It is a little user hostile.
I agree with that. I kind of suggested it without knowing what kind of resources this would take. If it implies slowing down file opening enough to be annoying this should be avoided.
O.K. We can do some statistical analysis of a) The diagonals, b) The x position and c) the y position of every bounding box, and by looking at twice the standard deviation determine if the out-liers were lying out too far.
The trouble with this approach is that it is the 'fool proof' approach, just making as a system proof against a fool only works until a better one comes along, this appraoch will be defeated in the field by the great variety of insane files.
This is probably very right but not being able to fix everything might not be a reason to fix nothing (I guess it is easier to say when I am not the one involved in the fixing but, hey, this is about suggesting new/better things for inkscape right?). I really like your idea of the "Verify file" feature. From a user point of view, if something goes wrong the reflex of trying a "Verify file" seems natural to me and if it solves the problem or even...
Whether we like it or not, people are going to have to be opening SVG files with text editor (or the built-in XML editor) to fix problems with insane files for some time to come. It is madness to pretend otherwise.
... just suggests a way to solve it by editing the XML, it would be great. It will solve the "when to check" issue too: when the user has a problem, receives a warning etc. he will manually check the file, save it under another name if he wishes to and so on. This supposes two things: - that warnings are issued in a more prominent manner. if the problem is really with the bitmap copy and some bbox/reference problem, inkscape could already detect and display a warning but in the status bar that I didn't check as I was not intending to hit Alt+B. I am more and more convinced this is the case because my text is in bold and Alt+B is so close to Ctrl+B. In addition I often get lost between mac and x11/linux key binding and guess what: Alt is juste between Ctrl and it's mac equivalent: the apple key! - that some criteria are chosen in the sanity check and some fixes are proposed when these criteria are met. As I mentioned before, I am thinking about scaling objects that have insane bbox or that are really big/small in comparison with the rest of the drawing. Or even scaling the whole drawing if it is huge (as it was the case previously with somebody who couldn't zoom out far enough to see the whole drawing if I remember well) or tiny (as it is the case with the other file I have). And having the possibility to accept or reject any change individually make this feature not too intrusive. Once again I don't know if all this even means something. Just correct me if this is stupid.
So to sum up: this bug was not about zooming after all and I think that it would be better to fix it (with a sanity check) that to try to hide it by changing the zoom behavior (which doesn't prevent you, Ben, to change the zoom behavior for other usability reasons!). Indeed this bbox issue was not only causing zooming problems but also printing issues: the eps I produced was not readable by everything, its conversion to PDF made a big pink rectangle across the whole page, as the physical printing did.
To help this I can provide plenty of buggy files to play with ;-) Scilab and other math plotting software apparently produce eps files that pstoedit/inkscape do not like at all.
Having said that, perhaps Inkscape compiled in debug mode should have some of these artifical limits, (just as we have assertion statements). It will help identify to developers just where the shoe pinches, but users do not need to handle this.
If they could, why not? Once you pointed me to the problem the fix was really easy. Having that build into inkscape would have avoided you all my long emails ;-)
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
On 10/16/05, jiho <jo.irisson@...400...> wrote:
On 15 oct. 05, at 20:23, Ben Fowler wrote:
On 10/15/05, jiho <jo.irisson@...400...> wrote:
On 15 oct. 05, at 18:34, Ben Fowler wrote:
On 10/15/05, bulia byak <buliabyak@...400...> wrote:
On 10/15/05, Ben Fowler <ben.the.mole@...400...> wrote:
Whether we like it or not, people are going to have to be opening SVG files with text editor (or the built-in XML editor) to fix problems with insane files for some time to come. It is madness to pretend otherwise.
... just suggest a way to solve it by editing the XML, it would be great. It will solve the "when to check" issue too: when the user has a problem, receives a warning et cetera he will manually check the file, save it under another name if he wishes to and so on. This pre-supposes two things:
- that warnings are issued in a more prominent manner. if the problem
is really with the bitmap copy and some bbox/reference problem, inkscape could already detect and display a warning but in the status bar that I didn't check as I was not intending to hit Alt+B. I am more and more convinced this is the case because my text is in bold and Alt+B is so close to Ctrl+B. In addition I often get lost between mac and x11/linux key binding and guess what: Alt is just between Ctrl and its Mac equivalent: the apple key!
It sounds as though we need more input on key bindings. In BBedit, Cmd-B is 'Balance', In Camino and Iterm it is 'Manage Bookmarks'. Personally, think that we shouldn't be encouraging people to use an operation like 'make bold' but the more semantic 'strong' or 'emphasis' for simple things, and font-weight or font-family for where the typographic presentation is known to you. (What key combinations would you suggest for selecting Bookman Demi or Bookman Light)? I realise that we have to have a bold key combination somewhere, but can't it be put it into some typographic purgatory as Cmd-Shift-B?
[Italic] Cmd-I = Get Info [Bold] Cmd-B = Bookmarks 'Send to back' [Underline] Cmd-U = View Source [Double-Underline] Cmd-D = Duplicate [Small Caps] Cmd-S = Save [All Caps] Cmd-A = Select All [Align Right] Cmd-R (Revert Render Run Redo) [Align Left] Cmd-L (Load Lock) [Justify] Cmd-J (Join 'View Options' 'Fit Selection' or 'Scroll to Selection')
With very few exceptions, using the first-class key-strokes - Cmd-A, for some letter A - to apply detailed typographic changes cuts a swathe through the available ones.
(Personally, I don't like unadorned alt-key combination for performing actions, I would expect alt-b to type a Greek Beta or possibly an Austrian sharfes S).
Ben
participants (2)
-
Ben Fowler -
jiho