Inkscape

J.B.C.Engelen@... wrote:
> Hi all,
> 
> When parsing "M 0,0 1,0 1,1 0,1 0,0 z", the old nartbpath optimizes it
> and stores it like: "M 0,0 1,0 1,1 0,1 z". The 2geom path parser does
> not. So when writing the path back to svg, nartbpath and 2geom don't
> match up.
> 
> What to do?
> Should 2geom optimize the path as well? Or should the svg writer
> optimize it? Or keep it the way the input was?

Actually the parser just prevents an extra(!) subpath from being created 
if the final node is specified explicitly (see 
gnome-canvas-bpath-util.cpp), and when serializing the path data it just 
eliminates the final (redundant) node.

I'd recommend just removing the redundant node, it does no good, takes 
up space and could even lead to problems (if it is changed but the first 
node isn't, or the other way around, a new node is suddenly created).

Jasper van de Gronde wrote:
> J.B.C.Engelen@... wrote:
>> Hi all,
>>
>> When parsing "M 0,0 1,0 1,1 0,1 0,0 z", the old nartbpath optimizes it
>> and stores it like: "M 0,0 1,0 1,1 0,1 z". The 2geom path parser does
>> not. So when writing the path back to svg, nartbpath and 2geom don't
>> match up.
>>
>> What to do?
>> Should 2geom optimize the path as well? Or should the svg writer
>> optimize it? Or keep it the way the input was?
> 
> Actually the parser just prevents an extra(!) subpath from being created 
> if the final node is specified explicitly (see 
> gnome-canvas-bpath-util.cpp), and when serializing the path data it just 
> eliminates the final (redundant) node.
> 
> I'd recommend just removing the redundant node, it does no good, takes 
> up space and could even lead to problems (if it is changed but the first 
> node isn't, or the other way around, a new node is suddenly created).

I think that it is important that we preserve the data we receive. If we 
get a redundant end node from a user and we optimize it away then we 
could end up with an angry user who expected it to be there. On the 
other hand I think Inkscape has been creating these redundant end nodes 
all along and I don't think we should be. I'd prefer to keep them when 
we see them but never create them ourselves unless instructed to do that.

Aaron Spike

> -----Original Message-----
> From: lib2geom-devel-bounces@... 
> [mailto:lib2geom-devel-bounces@...] On 
> Behalf Of Aaron Spike
> Sent: zondag 29 juni 2008 16:37
> To: Jasper van de Gronde
> Cc: inkscape-devel@...; Engelen, J.B.C. 
> (Johan); lib2geom-devel@...
> Subject: Re: [Lib2geom-devel] [Inkscape-devel] path parsing 
> -nartbpath optimization?
> 
> Jasper van de Gronde wrote:
> > J.B.C.Engelen@... wrote:
> >> Hi all,
> >>
> >> When parsing "M 0,0 1,0 1,1 0,1 0,0 z", the old nartbpath 
> optimizes 
> >> it and stores it like: "M 0,0 1,0 1,1 0,1 z". The 2geom 
> path parser 
> >> does not. So when writing the path back to svg, nartbpath 
> and 2geom 
> >> don't match up.
> >>
> >> What to do?
> >> Should 2geom optimize the path as well? Or should the svg writer 
> >> optimize it? Or keep it the way the input was?
> > 
> > Actually the parser just prevents an extra(!) subpath from being 
> > created if the final node is specified explicitly (see 
> > gnome-canvas-bpath-util.cpp), and when serializing the path data it 
> > just eliminates the final (redundant) node.
> > 
> > I'd recommend just removing the redundant node, it does no 
> good, takes 
> > up space and could even lead to problems (if it is changed but the 
> > first node isn't, or the other way around, a new node is 
> suddenly created).
> 
> I think that it is important that we preserve the data we 
> receive. If we get a redundant end node from a user and we 
> optimize it away then we could end up with an angry user who 
> expected it to be there. On the other hand I think Inkscape 
> has been creating these redundant end nodes all along and I 
> don't think we should be. I'd prefer to keep them when we see 
> them but never create them ourselves unless instructed to do that.

I agree with Aaron's viewpoint. 

Inkscape 0.46: "M 0,0 1,0 1,1 0,1 0,0 z" stays like that when moving one
node up and then down again.
0.46+dev     : "M 0,0 1,0 1,1 0,1 0,0 z" becomes "M 0,0 1,0 1,1 0,1 z"
after the same operation.

Jasper wrote:
> when serializing the path data it 
> just eliminates the final (redundant) node.

This behavior was introduced in r17918 (after 0.46 release).

I am still a bit puzzled why this problem shows up now, because some
time ago the 2 paths in spcurve matched each other perfectly when the
svg strings were compared... Now on startup, for a lot of spcurves, the
paths don't match anymore.

Johan

Hi all,


Maybe having the closing segment explicitly stated is legacy, left over 
from storing all
SPShape objects as curves?


bob




J.B.C.Engelen@... wrote:
>> -----Original Message-----
>> From: lib2geom-devel-bounces@...
>> [mailto:lib2geom-devel-bounces@...] On
>> Behalf Of Aaron Spike
>> Sent: zondag 29 juni 2008 16:37
>> To: Jasper van de Gronde
>> Cc: inkscape-devel@...; Engelen, J.B.C.
>> (Johan); lib2geom-devel@...
>> Subject: Re: [Lib2geom-devel] [Inkscape-devel] path parsing
>> -nartbpath optimization?
>>
>> Jasper van de Gronde wrote:
>>      
>>> J.B.C.Engelen@... wrote:
>>>        
>>>> Hi all,
>>>>
>>>> When parsing "M 0,0 1,0 1,1 0,1 0,0 z", the old nartbpath
>>>>          
>> optimizes
>>      
>>>> it and stores it like: "M 0,0 1,0 1,1 0,1 z". The 2geom
>>>>          
>> path parser
>>      
>>>> does not. So when writing the path back to svg, nartbpath
>>>>          
>> and 2geom
>>      
>>>> don't match up.
>>>>
>>>> What to do?
>>>> Should 2geom optimize the path as well? Or should the svg writer
>>>> optimize it? Or keep it the way the input was?
>>>>          
>>> Actually the parser just prevents an extra(!) subpath from being
>>> created if the final node is specified explicitly (see
>>> gnome-canvas-bpath-util.cpp), and when serializing the path data it
>>> just eliminates the final (redundant) node.
>>>
>>> I'd recommend just removing the redundant node, it does no
>>>        
>> good, takes
>>      
>>> up space and could even lead to problems (if it is changed but the
>>> first node isn't, or the other way around, a new node is
>>>        
>> suddenly created).
>>
>> I think that it is important that we preserve the data we
>> receive. If we get a redundant end node from a user and we
>> optimize it away then we could end up with an angry user who
>> expected it to be there. On the other hand I think Inkscape
>> has been creating these redundant end nodes all along and I
>> don't think we should be. I'd prefer to keep them when we see
>> them but never create them ourselves unless instructed to do that.
>>      
>
> I agree with Aaron's viewpoint.
>
> Inkscape 0.46: "M 0,0 1,0 1,1 0,1 0,0 z" stays like that when moving one
> node up and then down again.
> 0.46+dev     : "M 0,0 1,0 1,1 0,1 0,0 z" becomes "M 0,0 1,0 1,1 0,1 z"
> after the same operation.
>
> Jasper wrote:
>    
>> when serializing the path data it
>> just eliminates the final (redundant) node.
>>      
>
> This behavior was introduced in r17918 (after 0.46 release).
>
> I am still a bit puzzled why this problem shows up now, because some
> time ago the 2 paths in spcurve matched each other perfectly when the
> svg strings were compared... Now on startup, for a lot of spcurves, the
> paths don't match anymore.
>
> Johan
>
>
>
>

> -----Original Message-----
> From: inkscape-devel-bounces@... 
> [mailto:inkscape-devel-bounces@...] On 
> Behalf Of Bob Jamison
> Sent: zondag 29 juni 2008 22:34
> To: Engelen, J.B.C. (Johan); inkscape
> Subject: Re: [Inkscape-devel] [Lib2geom-devel] pathparsing 
> -nartbpath optimization?
> 
> Hi all,
> 
> 
> Maybe having the closing segment explicitly stated is legacy, 
> left over from storing all SPShape objects as curves?

In NArtBpath, the closing segment is always stated 'double': a subpath
starts with MOVETO, instead of MOVETO_OPEN, to state that it is closed,
but it also ends with the closing line segment explicitly there. I tried
with inkscape 0.46: input without explicit closing line, becomes output
with explicit closing line (Inkscape 0.46 cannot output M0,0 1,0 1,1 0,1
z!) So actually, Inkscape used to output paths always with unnecessary
closing segment! Maybe that is something to say in the release notes...

I think the way 0.46+devel works now is good: it maintains the explicit
closing line; node editing however removes the explicit closing segment.
(perhaps other operations as well, transforming does not remove it)

This whole issue popped up because I enabled path checking again in
SPCurve (to see whether the old and new representations match up). So
for closed paths, they don't anymore... but I think I can still safely
start removing the old path code. A lot of places in Inkscape that are
most often used are already using the new 2geom path exclusively, so...
:-)

Even more off-topic: is there a 'line-counter' somewhere that shows a
graph of the lines of code Inkscape's source has? (A bit more detailed
than Ohloh's graph)

Cheers,
Johan

On Jun 29, 2008, at 5:28 PM, J.B.C.Engelen@... wrote:

>
> Even more off-topic: is there a 'line-counter' somewhere that shows a
> graph of the lines of code Inkscape's source has? (A bit more detailed
> than Ohloh's graph)

Eeeeeeeeeeeeeeeeeek!!!!

LOC is one of the more worthless metrics out there.

:-)

> -----Original Message-----
> From: njh [mailto:njh@...] 
> Sent: zondag 29 juni 2008 19:01
> To: Engelen, J.B.C. (Johan)
> Cc: inkscape-devel@...; 
> lib2geom-devel@...
> Subject: Re: [Lib2geom-devel] path parsing - nartbpath optimization?
> 
> On Sun, 29 Jun 2008 J.B.C.Engelen@... wrote:
> 
> > Hi all,
> >
> > When parsing "M 0,0 1,0 1,1 0,1 0,0 z", the old nartbpath 
> optimizes it 
> > and stores it like: "M 0,0 1,0 1,1 0,1 z". The 2geom path 
> parser does 
> > not. So when writing the path back to svg, nartbpath and 
> 2geom don't 
> > match up.
> 
> Write a path optimiser function.  If you're going to optimise 
> this, why not consider more interesting optimisations like 
> reparameterisation?

This may be a good idea for later, but for now I was interested in "the right"(TM) behavior. What Inkscape used to be doing.

:)
Johan