On 09/03/2016 09:21 PM, dmg wrote: > I think that the n+1 vs n widths can be easily handled by patching > xournal to accept a n+1 width (and ignore it). So when it reads a file > with more than > n, it works, rather than failing as it is currently. I'll write the > patch today.
Yes, of course -- but it does break backwards compatibility of the file format (in the sense that existing versions without this easy patch won't be able to read the new files anymore, for a reason that feels slightly stupid). In general, if we want to treat trapezoid vs lines as purely a rendering option then we need to agree on how many width parameters need to be stored regardless, and do so in a manner that can still read existing xournal files without getting too confused. Hah. It's a bit of a hack, but here's a proposal that fully preserves file format compatibility: * We add one more width as Immi would like us to (presumably this is the width at the start of the stroke -- I looked at my code and it only measures the pressure/width at the end of each segment -- we only call get_pressure_in continue_stroke(), so the extra width that Immi needs to store presumably comes before the others) -- but we also add one more xy point: we record twice the starting point of the stroke. * Then the existing versions of xournal and the sequence-of-line-segments renderer should be able to treat this just fine if they read this kind of stroke data -- it would just start by drawing a length zero segment. Meanwhile, the trapezoid renderer would either ignore the initial length zero segment if there is one [for data coming from the new xournal], or if the initial segment does not have length zero, draw a line or a triangle [note: the initial nonzero length segment indicates that we're missing one piece of width data because the file came from an older xournal, so one needs to improvise], and then draw trapezoids for the subsequent line segments as required. (Sorry if this is a bit confusing. Old format = we store n+1 distinct points and n widths for the end of each segment i.e. no width data at the starting point; new format = we store the first point twice, ending up with n+2 points in total, and n+1 widths at all the distinct points (= the ends of the segments if you include the duplicated first point in the list). Then there's enough data for the trapezoid renderer if the first point is duplicated [otherwise, in existing xoj files there isn't quite enough width data for the trapezoid renderer and the first line segment needs to be treated creatively], and the duplicated xy-point allows old versions of xournal to think that this is just a sequence of widths for the segments, the first width being for a bogus length 0 segment.) Does this make sense? [as in: do you agree it would work?] Does it make sense? [as in: do we think it's worth introducing such a hack to preserve compatibility?] Best, Denis -- Denis Auroux UC Berkeley, Department of Mathematics 817 Evans Hall, Berkeley CA 94720-3840, USA aur...@math.berkeley.edu ------------------------------------------------------------------------------ _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
