{"push_id":1815347795,"size":1,"distinct_size":1,"ref":"refs/heads/svg-clipping","head":"fc6448d18ce6000ef6711f5485bd982bddc0eb54","before":"623680d3eff7cb71503315652af5feb3d9cc2022","commits":[{"sha":"fc6448d18ce6000ef6711f5485bd982bddc0eb54","author":{"name":"Rob Wu","email":"250ddf768181782bd7ec5f89baf25f1862c7216e@robwu.nl"},"message":"Move svg:clipPath generation from clip to endPath\n\nIn the PDF from issue 8527, the clip operator (W) shows up before a path\nis defined. The current SVG backend however expects a path to exist\nbefore generating a `<svg:clipPath>` element.\nIn the example, the path was defined after the clip, followed by a\nendPath operator (n).\nSo this commit fixes the bug by moving the path generation logic from\nclip to endPath.\n\nOur canvas backend appears to use similar logic:\n`CanvasGraphics_endPath` calls `consumePath`, which in turn draws the\nclip and resets the `pendingClip` state. The canvas backend calls\n`consumePath` from multiple other places, so we probably need to check\nwhether doing so is also necessary for the SVG backend.\n\nI scanned our corpus of PDF files in test/pdfs, and found that in every\ninstance (except for one), the \"W\" PDF operator (clip) is immediately\nfollowed by \"n\" (endPath). The new test from this commit (clippath.pdf)\nstarts with \"W\", followed by a path definition and then \"n\".\n\n    # Commands used to find some of the clipping commands:\n    grep -ra '^W$' -C7 | less -S\n    grep -ra '^W ' -C7 | less -S\n    grep -ra ' W$' -C7 | less -S\n\ntest/pdfs/issue6413.pdf is the only file where \"W\" (a tline 55) is not\nfollowed by \"n\". In fact, the \"W\" is the last operation of a series of\nXObject painting operations, and removing it does not have any effect\non the rendered PDF (confirmed by looking at the output of PDF.js's\ncanvas backend, and ImageMagick's convert command).","distinct":true,"url":"https://api.github.com/repos/Rob--W/pdf.js/commits/fc6448d18ce6000ef6711f5485bd982bddc0eb54"}]}
{"actor":{"display_login":"Rob--W"}}