As far as I understand, the file format compatibility issue is simply
the number of width parameters.
Namely, a stroke composed of n line segments connecting (n+1) vertices
has n widths with my version of the code (one width for each segment),
and (n+1) widths with Immi's version (one width for each vertex).
So my code stores n+1 widths into the "width" attribute: the nominal
brush width [useful for changing the thickness of variable-width strokes
to a different nominal thickness eg from 'medium' to 'thick'], and the n
brush widths used for the segments. I assume that Immi would want to
store n+2 (the nominal width + the n+1 actual widths at the vertices).
Alas, the file loading code tests, when a stroke has multiple widths in
the "width" attribute [hence is variable width], whether the number of
width parameters is as expected, i.e. n+1.
This is the line
if (n<4 || n&1 ||
(tmpItem->brush.variable_width && (n!=2*ui.cur_path.num_points)))
{ *error = xoj_invalid(); return; } // wrong number of points
somewhere in xo-file.c -- check if the number of data points inside a
stroke's element contents (the coordinates) is even, at least 4, and
twice the number of widths if we had found variable-width data in the
"width" attribute. [Unfortunately the number of xy coordinates is called
n in this line of code whereas with the above convention it would be
2n+2, i.e. ui.cur_path.num_points has been set to n+1 when reading the
widths data with multiple entries.]
I still think there should be some reasonable way to avoid diverging the
file formats given how little difference there is. (Of course now I can
curse myself for having insisted on a careful verification that the
number of points in widths and in the xy data match -- but better
paranoid at load time than risk a segfault when trying to render the
stroke and one of the data arrays is too short).
Best,
Denis
> But the real problem is that we _need_ to make sure your patch generates
> files that are backwards compatible with xournal. We need to find a way
> to do this.
>
> 1. "Trapezoidize" the lines after they have been read. The xournal file can
> store this as an option, and do this dynamically.
>
> 2. Have an option that saves trapezoidizes the lines. user should be
> able to enable disable this feature. I can help you do this.
>
>
>
>
>
>
>
>
> --
> Daniel M. German "We need [news] editorial more than ever"
> Steve Jobs
> http://turingmachine.org/
> http://silvernegative.com/
> dmg (at) uvic (dot) ca
> replace (at) with @ and (dot) with .
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Xournal-devel mailing list
> Xournal-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xournal-devel
>
--
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
