https://bugs.documentfoundation.org/show_bug.cgi?id=82262
--- Comment #20 from Dave Gilbert <[email protected]> --- Making it not-ignore empty clip paths, and also closing incoming clip paths makes the 'More minimal pdf' from 22nd render OK, but it's not the whole story. Looking at the whole doc, or in particular the 'minimal file b' I just uploaded; it's missing bits of the shading. I think this is a winding rule screwup of the type tdf#86211 suggests. Summarizing what we have in that minimal file b; we have a lozenge shape (which gives us a clip path to start with), and then we have square diamonds, each with it's own clip path, and inside those are a series of (11?) stroke lines. Some of the diamonds end up losing all their stroke lines. Here's some of my debug corresponding to the clip setup going into one of the (missing) square diamonds: 1439 PDFIProcessor::intersectClip: new:[1:<5:(-2.1378,-4.35001)--(18.8622,-4.35001)--(18.8622,16.65)--(-2.1378,16.65)--(-2.1378,-4.35001)>] One of the clipping paths for a square as we read it 1440 PDFIProcessor::intersectClip: new(post close):[1:<5:(-2.1378,-4.35001)--(18.8622,-4.35001)--(18.8622,16.65)--(-2.1378,16.65)--(-2.1378,-4.35001)>] 1441 PDFIProcessor::intersectClip: new(post NZC):[1:<5:(-2.1378,-4.35001)--(18.8622,-4.35001)--(18.8622,16.65)--(-2.1378,16.65)--(-2.1378,-4.35001)>] 1442 PDFIProcessor::intersectClip: new: xfrm: [1:<5:(38732.2,25528)--(40893.9,26878.9)--(39543.1,29040.6)--(37381.4,27689.8)--(38732.2,25528)>] after going through a xfrm 1443 PDFIProcessor::intersectClip: cur: [1:<6:(8486,28745.3)--(8486,27652.8)--(8490.6,27652.8)--(42524.4,27671)--(42838.9,28217.3)--(42524.4,28763.5)>] 'cur' is the clipping path before this call; this corresponds to the main lozenge 1444 PDFIProcessor::intersectClip: res: [1:<5:(39717.2,28762)--(39096.7,28761.7)--(37381.4,27689.8)--(37394.8,27668.3)--(40399.7,27669.9)>] OK, great - a valid clip path 1445 PDFIProcessor::intersectClip: new:[1:<4:(-2.1378,-4.35)--(18.862,-4.35)--(18.862,16.65)--(-2.1378,16.65)>] We get called again, by an almost identical clip path - looks like poppler rounded it somewhere 1446 PDFIProcessor::intersectClip: new(post close):[1:<4:(-2.1378,-4.35)--(18.862,-4.35)--(18.862,16.65)--(-2.1378,16.65)>] Note this wasn't closed, and so a call to basegfx::utils::closeWithGeometryChange closes it (Hmm is it?) 1447 PDFIProcessor::intersectClip: new(post NZC):[1:<4:(-2.1378,-4.35)--(18.862,-4.35)--(18.862,16.65)--(-2.1378,16.65)>] 1448 PDFIProcessor::intersectClip: new: xfrm: [1:<4:(38732.2,25528)--(40893.9,26878.9)--(39543.1,29040.6)--(37381.4,27689.8)>] 1449 PDFIProcessor::intersectClip: cur: [1:<5:(39717.2,28762)--(39096.7,28761.7)--(37381.4,27689.8)--(37394.8,27668.3)--(40399.7,27669.9)>] This is the clip we generated on 1444 above 1450 PDFIProcessor::intersectClip: res: [1:<5:(39717.2,28762)--(39096.7,28761.7)--(37381.4,27689.8)--(37394.8,27668.3)--(40399.6,27669.9)>] OK, valid clip comes out 1451 PDFIProcessor::intersectClip: new:[1:<4:(-2.1378,-4.35)--(-2.1378,16.65)--(18.862,16.65)--(18.862,-4.35)>] Another call from poppler - this is the interesting one; the only difference from 1445 above is the point order - this is the opposite 1452 PDFIProcessor::intersectClip: new(post close):[1:<4:(-2.1378,-4.35)--(-2.1378,16.65)--(18.862,16.65)--(18.862,-4.35)>] 1453 PDFIProcessor::intersectClip: new(post NZC):[1:<4:(-2.1378,-4.35)--(-2.1378,16.65)--(18.862,16.65)--(18.862,-4.35)>] 1454 PDFIProcessor::intersectClip: new: xfrm: [1:<4:(38732.2,25528)--(37381.4,27689.8)--(39543.1,29040.6)--(40893.9,26878.9)>] 1455 PDFIProcessor::intersectClip: cur: [1:<5:(39717.2,28762)--(39096.7,28761.7)--(37381.4,27689.8)--(37394.8,27668.3)--(40399.6,27669.9)>] 1456 PDFIProcessor::intersectClip: res: [0:] Empty clip! But note this is clipping the same thing but to only the opposite direction; so if we agreed what that meant I think this should survive. -- You are receiving this mail because: You are the assignee for the bug.
