[poppler] Bug in GfxState.cc. What's the fix?

[Adrian Johnson]

On 04/05/16 09:10, Albert Astals Cid wrote:
> If you look at line 5550 of GfxState.cc you'll see
> 
> 	  p->color[0][1].c[j] = patchesA[nPatchesA-1].color[1][0].c[j];
> 	  p->color[0][1].c[j] = patchesA[nPatchesA-1].color[0][0].c[j];
> 
> If you look carefully enough you see as we're setting a value and then 
> immediately overwriting it \o/
> 
> I've no idea of what this code does but by symmetry with line 5724 i'd say it 
> should be
> 
> 	  p->color[0][0].c[j] = patchesA[nPatchesA-1].color[1][0].c[j];
> 	  p->color[0][1].c[j] = patchesA[nPatchesA-1].color[0][0].c[j];
> 
> Opinions?

I checked this with Table 85 in PDF32000-1:2008.

Looking at the flag = 0 case (line 5445):
  p->color[0][0].c[j] in GfxState is c1 in table 85
  p->color[0][1].c[j] in GfxState is c2 in table 85
  p->color[1][1].c[j] in GfxState is c3 in table 85
  p->color[1][0].c[j] in GfxState is c4 in table 85

I expect this should be correct as flag = 0 is what cairo pdf generates
and I have done plenty of testing with the cairo mesh gradient pdf
output and poppler.

Looking at the flag = 3 case (line 5550). PDF32000 states that:
  c1 = c4 previous
  c2 = c1 previous
  c3 = first color in patch data
  c4 = second color in patch data

So I would expect the code to be:
  p->color[0][0].c[j] = patchesA[nPatchesA-1].color[1][0].c[j];
  p->color[0][1].c[j] = patchesA[nPatchesA-1].color[0][0].c[j];
  p->color[1][1].c[j] = c[0][j];
  p->color[1][0].c[j] = c[1][j];

Your proposed fix looks good to me.

> 
> Cheers,
>   Albert
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/poppler
>