> But I'm not sure right now if you have a "end_poly" command
> at the end. There might be a glitch.
The problem was at the end indeed. The last coordinate I was getting was
always (0.0, 0.0) with the flipped paths. The problem didn't always show,
only with "specific" paths. I could send you an SVG file in private mail
which shows the problem.
> If the last sequence is not the result of flipping the first sequence, then
> that would be the source of my problem. Are you sure that it is the case?
Yes, you can check it with triangles:
move_to line_to line_to.
If you flip it directly you will have
line_to line_to move_to. You can't draw it because it must begin with move_to.
So, I simply shift the commands one step forward and replace the first command
with the former last one.
It should work fine if you preserve the integrity (only one move_to command in
the beginning). But I'm not sure right now if you have a "end_poly" command at
the end. There might be a glitch.
> I could send you an SVG file in which flipping the orientations was a
> > problem. The problem was always with polygons that presented the "hole"
> > within another polygon. I could also provide you the code which I use to
> > transform the agg::path_storage into what I use.
>
> That's not surprising. Yes, the common rule is that a hole should have
> different direction, but the problem is that the subpath doesn't know if
> it's a
> hole or an outermost contour. The arrange_orientation is straightforward, it
> makes all the polygons oriented CW or CCW, not distinguishing between outer
> and
> inner ones. Then, if you use non-zero fill rule, the holes will disappear.
>
> In general, there's no such thing as "absolute direction" of the polygon
> (it's
> not applicable to self-intersecting polygons). There can be only relative
> direction of the edges.
I think you misunderstood. What I did is call
path_storage::arrange_orientations_all_paths(path_flags_ccw); on the one path
storage that contained all paths from the SVG file. (My code is actually
based on your SVG example, and this was still a left over.) My guess is, that
for the fill defining (outer) paths, this call had no effect, because they
were already ccw oriented. But for the hole defining (inner) paths, this call
actually had an effect. And it seems it messed up the mapping of commands to
coordinates, which in turn messed up my conversion algorithm. This has
nothing to do with rendering, I'm just talking about the conversion, where I
received very strange results, and they can be explained, if the source of
error was the orientation switch. When I don't use the
arrange_orientations_all_paths() function, I get just the results I would
expect.
> Yes, it might be. Suppose you have just a single cubic curve (4 points).
> Internally it looks as follows:
> move_to x1 y1
> curve4 x2 y2
> curve4 x3 y3
> curve4 x4 y4
> If we invert it directly we will have
> curve4 x4 y4
> curve4 x3 y3
> curve4 x2 y2
> move_to x1 y1
> That's wrong and I have to "shift-and-rotate" one command:
> move_to x4 y4
> curve4 x3 y3
> curve4 x2 y2
> curve4 x1 y1
If the last sequence is not the result of flipping the first sequence, then
that would be the source of my problem. Are you sure that it is the case?
> I could send you an SVG file in which flipping the orientations was a
> problem. The problem was always with polygons that presented the "hole"
> within another polygon. I could also provide you the code which I use to
> transform the agg::path_storage into what I use.
That's not surprising. Yes, the common rule is that a hole should have
different direction, but the problem is that the subpath doesn't know if it's a
hole or an outermost contour. The arrange_orientation is straightforward, it
makes all the polygons oriented CW or CCW, not distinguishing between outer and
inner ones. Then, if you use non-zero fill rule, the holes will disappear.
In general, there's no such thing as "absolute direction" of the polygon (it's
not applicable to self-intersecting polygons). There can be only relative
direction of the edges.
