I fixed the two-equal-points-crashes-xournal bug (in my repository,
branch line-widths-optimized). I did not yet do anything about the
"-nan" issue.
Immi
Am 06.10.2016 um 20:51 schrieb Denis Auroux:
> Interesting. Neither of the issues causes the stable/upstream xournal to
> crash, though :)
>
> The stroke with just two points at the same location is the problem I
> was looking for and Immi confirmed -- the solution is simple: in the
> loading code, when Immi tests whether the first two points of the stroke
> are equal (and then chops off one and interprets it as new-style
> variable-width), he should also be testing whether the stroke has at
> least 3 points (and otherwise not chop off anything).
> (Or we could discard such segments altogether, but the backwards
> compatible behavior would be to keep a dot).
>
> I didn't look any further -- but the nan's are very interesting too. I
> believe that over the years I've added various protections against input
> events that come at nan or infinite coordinates -- so I'm under the
> impression that xournal-upstream should load them without
> complaining/crashing (I forgot what we do with them though) but also
> should never create such strokes (because the "nan" or infinity should
> be caught before we insert such coordinates into the journal's data
> structures). [However, perhaps rescaling a selection by an infinite
> factor could create such data? If someone managed to create a size zero
> selection rectangle that encloses a single-point stroke?? Seems
> unlikely. Or did the file somehow originate from an older version of
> xournal that wasn't careful about infinities/nan's in input coordinates ?]
>
> Anyway, I have no idea where the nan's came from. They shouldn't be
> there. I don't know if they are there because of some edge case I didn't
> think of already in upstream, or because of a feature in next. But we
> should accept them without crashing...
>
> Best,
> Denis
>
>
>
> On 10/06/2016 02:11 PM, dmg wrote:
>> There seem to be multiple issues with the document. This mini-xournal
>> file crashes xournal:
>>
>> <?xml version="1.0" standalone="no"?>
>> <xournal version="0.4.8">
>> <title>Xournal document - see
>> http://math.mit.edu/~auroux/software/xournal/</title>
>> <page width="595.29" height="841.89">
>> <layer>
>> <stroke tool="pen" color="red" width="1.41">
>> 118.30 240.72 118.30 240.72
>> </stroke>
>> </layer>
>> </page>
>> </xournal>
>>
>> the issue seems to be that the stroke starts and ends in the same
>> location.
>>
>> On Thu, Oct 6, 2016 at 11:01 AM, dmg <d...@turingmachine.org
>> <mailto:d...@turingmachine.org>> wrote:
>>
>> This is the stroke that is crashing xournal:
>>
>> <stroke tool="pen" color="red" width="1.41">
>> -nan -nan -nan -nan -nan -nan -nan -nan
>> </stroke>
>>
>>
>>
>> On Thu, Oct 6, 2016 at 10:42 AM, D M German <d...@turingmachine.org
>> <mailto:d...@turingmachine.org>> wrote:
>>
>> Romano Gtti twisted the bytes to say:
>>
>> Romano> I used the ruler a bit in the document, and yes,
>> sometime I use it with the mouse (to underline text etc. and
>> make big
>> Romano> boxes, which are difficult to achieve with the mouse
>> and the shpe recognizer). So maybe this was the culprit.
>>
>> Romano> BTW, I removed that stroke from the file but I am still
>> unable to read it. Probably there is something more around. I
>> Romano> think that not saving such a 0-length segment is ok,
>> but a bit of defensive programming in reading it (like emit a
>> Romano> warning and ignoring it) could be nice to have...
>>
>> I presume that the best method to determine the culprit is to:
>>
>> - decompress the file: rename to file.xoj.gz and run gunzip on it
>> - do binary splicing of the file:
>> - remove half, does it load? If so, it the error is in the
>> other half.
>> - do recursively until error found
>>
>> --dmg
>>
>>
>>
>> Romano> Romano
>>
>> Romano> Thanks for the effort
>>
>>
>>
>> Romano> --
>> Romano> --
>> Romano> Romano at http://www.rgtti.com/
>>
>>
>> --
>> Daniel M. German "Un libro es un amigo a
>> voluntad...
>> puede convertirse en alacena
>> de recuerdos,en cántaro de
>> deseos,o
>> Germán Dehesa -> en ánfora de ensueños."
>> http://turingmachine.org/
>> http://silvernegative.com/
>> dmg (at) uvic (dot) ca
>> replace (at) with @ and (dot) with .
>>
>>
>>
>>
>>
>> --
>> --dmg
>>
>> ---
>> Daniel M. German
>> http://turingmachine.org
>>
>>
>>
>>
>> --
>> --dmg
>>
>> ---
>> Daniel M. German
>> http://turingmachine.org
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Xournal-devel mailing list
Xournal-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xournal-devel
