Articifical Limits (was Re: Sanity checking files on open)
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:
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 ;-)
Not really, the root cause of this e-mail conversation (maybe lengthy, but not unnecessary) is the fact that Inkscape did not gracefully handle a specific error condition. This wasn't deliberate. It was just that the precise combination of circumstances that brings it about had not occurred to any of the developers who had worked on that part of the code.
Bringing this up up was very necessary. This kind of bug report is one of the most important raw materials needed for the production of good software.
Now, release versions should not have 'articifical limits' or training wheels.
Th assumption is that if the Application is in an unexpected state with a developer, it is because he or she got something wrong, and we want the earliest indication of when this is happening. If the application is in an unexpected state with a user, then the user is probably 'in the right' and merely doing something that hadn't been tested or anticipated.
In the present case, if a scale factor exceeds 1 million, we are going to guess that on a developer's machine there is something wrong the code, but on a user's machine that he or she is simply working with large objects.
Ben
Quoting Ben Fowler <ben.the.mole@...400...>:
In the present case, if a scale factor exceeds 1 million, we are going to guess that on a developer's machine there is something wrong the code, but on a user's machine that he or she is simply working with large objects.
An interesting question is: how much does it matter to make such distinctions correctly? After all, many of us switch between the "user" and "developer" role frequently, on the same builds...
-mental
On 17 oct. 05, at 21:13, mental@...3... wrote:
Quoting Ben Fowler <ben.the.mole@...400...>:
In the present case, if a scale factor exceeds 1 million, we are going to guess that on a developer's machine there is something wrong the code, but on a user's machine that he or she is simply working with large objects.
An interesting question is: how much does it matter to make such distinctions correctly? After all, many of us switch between the "user" and "developer" role frequently, on the same builds...
I really think that intelligent choice of these artificial/human defined (which are synonyms for me in this case) limits would be useful. I have obviously no data to support it but I think that setting this artificial limits will help more people that it harms, especially if they are not definitive (ie: you can always refuse to correct). The statistical approach Ben took (two times the standard deviation of the diagonal of the bbox) might not always work but might help in most cases. In addition they would reconcile the two categories listed above: users will mostly use the software without seeing the limits, developers (or advances users) will know about them and know how to react when people report warning they do not understand. If someone has the two caps (as mental suggested) he will be doubly happy ;-)
As Ben suggested, I commented some RFE of bulia byak about a XML checker, I added it to the roadmap (for 0.44 maybe it is too early even for basic feature. I just did not know) and I started a wiki page about it: http://wiki.inkscape.org/cgi-bin/wiki.pl?XML_Repair I provided links to the already well known files and tried to summarize the discussion here. If I forgot something please add it. When time comes I will further investigate the field of scientific plotting softwares which produce in general strange eps files from what I have seen, and provide some other examples. As ben also suggested this might be more suited for the testers list now. I someone could forward this email for the moment, I will subscribe afterwards.
Thank you all for suggestions and listening... and for making such a great software (if only it could be native and quick on OS X. but all this Xara thing sounds terribly exiting and promising ;-) )
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/17/05, jiho <jo.irisson@...400...> wrote:
http://wiki.inkscape.org/cgi-bin/wiki.pl?XML_Repair I provided links to the already well known files and tried to summarize the discussion here.
Does anyone know about any software that can parse invalid XML and convert it to valid? I'd be interested to have a look. This is probably a complex task so we better not try to solve it all by ourselves, and chances are someone has already tried to solve it.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Tuesday 18 October 2005 00:47, bulia byak wrote:
On 10/17/05, jiho <jo.irisson@...400...> wrote:
http://wiki.inkscape.org/cgi-bin/wiki.pl?XML_Repair I provided links to the already well known files and tried to summarize the discussion here.
Does anyone know about any software that can parse invalid XML and convert it to valid? I'd be interested to have a look. This is probably a complex task so we better not try to solve it all by ourselves, and chances are someone has already tried to solve it.
Sounds interesting.. please let me know if you find something and I dont obviously take notice here. We are soon to start to implement our new file loader code.
thanks Craig
Quoting bulia byak <buliabyak@...400...>:
On 10/17/05, jiho <jo.irisson@...400...> wrote:
http://wiki.inkscape.org/cgi-bin/wiki.pl?XML_Repair I provided links to the already well known files and tried to summarize the discussion here.
Does anyone know about any software that can parse invalid XML and convert it to valid? I'd be interested to have a look. This is probably a complex task so we better not try to solve it all by ourselves, and chances are someone has already tried to solve it.
About 90% of my (paid) programming work has involved writing code to process partially malformed or corrupted data, so I guess this is kind of my field...
A rather key question question is: invalid in what way?
It is very unlikely that there is a suitable pre-packaged solution out there for us.
In general you must find an appropriate set of heuristics that do best at inferring intent for _your particular application domain_, and the most common ways in which documents may end up malformed for that domain.
This is because there is a tradeoff: whatever sorts of corruptions you chose your heuristics to correct, it will be at the expense of the ability to repair others.
As far as for us specifically...
Basically we will need to write a heuristic XML parser which can be used on invalid documents for which libxml's parser fails. It doesn't need to be perfect, but just do well enough to get a reasonable tree in memory. Then we can perform further repairs at the SVG (rather than XML) level.
Before that, though, an important first step is to build a corpus of representative malformed documents.
-mental
participants (5)
-
unknown＠example.com -
Ben Fowler -
bulia byak -
Craig Bradney -
jiho