From 8e19aa73faaa2990c0bec79ed45d38ef343c0a67 Mon Sep 17 00:00:00 2001 From: kramm Date: Sun, 18 Mar 2007 18:23:05 +0000 Subject: [PATCH] moved clockwise checker to gfxfillToSVP() --- lib/devices/arts.c | 62 ----------------------------------------------- lib/devices/artsutils.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 62 insertions(+), 62 deletions(-) diff --git a/lib/devices/arts.c b/lib/devices/arts.c index 510df3e..78986ec 100644 --- a/lib/devices/arts.c +++ b/lib/devices/arts.c @@ -179,68 +179,6 @@ void arts_fillbitmap(struct _gfxdevice*dev, gfxline_t*line, gfximage_t*img, gfxm internal_t*i = (internal_t*)dev->internal; ArtSVP* svp = gfxfillToSVP(line, 1); - // We need to make sure that the SVP we now have bounds an area (i.e. the - // source line wound anticlockwise) rather than excludes an area (i.e. the - // line wound clockwise). It seems that PDF (or xpdf) is less strict about - // this for bitmaps than it is for fill areas. - // - // To check this, we'll sum the cross products of all pairs of adjacent - // lines. If the result is positive, the direction is correct; if not, we - // need to reverse the sense of the SVP generated. The easiest way to do - // this is to flip the up/down flags of all the segments. - // - // This is approximate; since the gfxline_t structure can contain any - // combination of moveTo, lineTo and splineTo in any order, not all pairs - // of lines in the shape that share a point need be described next to each - // other in the sequence. For ease, we'll consider only pairs of lines - // stored as lineTos and splineTos without intervening moveTos. - // - // TODO is this a valid algorithm? My vector maths is rusty. - // - // It may be more correct to instead reverse the line before we feed it - // into gfxfilltoSVP. However, this seems equivalent and is easier to - // implement! - double total_cross_product = 0.0; - gfxline_t* cursor = line; - if (cursor != NULL) - { - double x_last = cursor->x; - double y_last = cursor->y; - cursor = cursor->next; - - while((cursor != NULL) && (cursor->next != NULL)) - { - if (((cursor->type == gfx_lineTo) || (cursor->type == gfx_splineTo)) - && ((cursor->next->type == gfx_lineTo) || (cursor->next->type == gfx_splineTo))) - { - // Process these lines - // - // In this space (x right, y down) the cross-product is - // (x1 * y0) - (x0 * y1) - double x0 = cursor->x - x_last; - double y0 = cursor->y - y_last; - double x1 = cursor->next->x - cursor->x; - double y1 = cursor->next->y - cursor->y; - total_cross_product += (x1 * y0) - (x0 * y1); - } - - x_last = cursor->x; - y_last = cursor->y; - cursor = cursor->next; - } - } - if (total_cross_product < 0.0) - { - int i = 0; - for(; i < svp->n_segs; ++i) - { - if (svp->segs[i].dir != 0) - svp->segs[i].dir = 0; - else - svp->segs[i].dir = 1; - } - } - if(i->clip) { ArtSVP*old = svp; svp = art_svp_intersect(svp, i->clip->svp); diff --git a/lib/devices/artsutils.c b/lib/devices/artsutils.c index ce005f5..e4b36a8 100644 --- a/lib/devices/artsutils.c +++ b/lib/devices/artsutils.c @@ -162,6 +162,68 @@ static ArtSVP* gfxfillToSVP(gfxline_t*line, int perturb) } ArtSVP *svp = art_svp_from_vpath(vec); free(vec); + + // We need to make sure that the SVP we now have bounds an area (i.e. the + // source line wound anticlockwise) rather than excludes an area (i.e. the + // line wound clockwise). It seems that PDF (or xpdf) is less strict about + // this for bitmaps than it is for fill areas. + // + // To check this, we'll sum the cross products of all pairs of adjacent + // lines. If the result is positive, the direction is correct; if not, we + // need to reverse the sense of the SVP generated. The easiest way to do + // this is to flip the up/down flags of all the segments. + // + // This is approximate; since the gfxline_t structure can contain any + // combination of moveTo, lineTo and splineTo in any order, not all pairs + // of lines in the shape that share a point need be described next to each + // other in the sequence. For ease, we'll consider only pairs of lines + // stored as lineTos and splineTos without intervening moveTos. + // + // TODO is this a valid algorithm? My vector maths is rusty. + // + // It may be more correct to instead reverse the line before we feed it + // into gfxfilltoSVP. However, this seems equivalent and is easier to + // implement! + double total_cross_product = 0.0; + gfxline_t* cursor = line; + if (cursor != NULL) + { + double x_last = cursor->x; + double y_last = cursor->y; + cursor = cursor->next; + + while((cursor != NULL) && (cursor->next != NULL)) + { + if (((cursor->type == gfx_lineTo) || (cursor->type == gfx_splineTo)) + && ((cursor->next->type == gfx_lineTo) || (cursor->next->type == gfx_splineTo))) + { + // Process these lines + // + // In this space (x right, y down) the cross-product is + // (x1 * y0) - (x0 * y1) + double x0 = cursor->x - x_last; + double y0 = cursor->y - y_last; + double x1 = cursor->next->x - cursor->x; + double y1 = cursor->next->y - cursor->y; + total_cross_product += (x1 * y0) - (x0 * y1); + } + + x_last = cursor->x; + y_last = cursor->y; + cursor = cursor->next; + } + } + if (total_cross_product < 0.0) + { + int i = 0; + for(; i < svp->n_segs; ++i) + { + if (svp->segs[i].dir != 0) + svp->segs[i].dir = 0; + else + svp->segs[i].dir = 1; + } + } return svp; } static ArtSVP* boxToSVP(double x1, double y1,double x2, double y2) -- 1.7.10.4