Created attachment 112599 [details] [review] allow for a floating one pixel rounded difference For one small font (here type 3) the glyph data is discarded by cairo (ie eveince printing or pdftocairo) : here 'i' and 'l'. That is if the difference between the origin and the end is bigger than .5 round up regardless of the coordinates. Round the difference of the floats instead of rounding the floats then diff them.
Created attachment 112600 [details] source file testcase made with master-pdf-editor from the guenine pdf (to import the type3 font) which I cannot ship per it contains sensitive data.
Created attachment 112601 [details] preview of the source and results left is the source both before fix: - top right : pdftocairo -ps output : not ok. - bottom right : pdftops output : ok.
before patch values for the "i" in _cairo_pattern_get_extents: - before _cairo_lround: x1 0.598800 y1 -5.401200 x2 1.201200 y2 0.001200 - after rounding: ix1 = 1 ix2 = 1 iy1 = -5 iy2 = 0 thus : extents values as x 1 y -5 height 5 width 0
Thanks; fix pushed: To ssh://git.cairographics.org/git/cairo b4a922f..e7acf4b master -> master
(In reply to Bryce Harrington from comment #4) > Thanks; fix pushed: > > To ssh://git.cairographics.org/git/cairo > b4a922f..e7acf4b master -> master It seems that this commit introduced nearly 40 failures in make -C test test TARGETS=image and gimp shows artifacts (vertical lines) in the GUI (right edge of progress bars) and in the image rendered on canvas.
- ix1 = _cairo_lround (x1); + ix1 = x1; if (x2 > CAIRO_RECT_INT_MAX) ix2 = CAIRO_RECT_INT_MAX; else - ix2 = _cairo_lround (x2); - extents->x = ix1; extents->width = ix2 - ix1; + ix2 = x2; + extents->x = ix1; extents->width = _cairo_lround(ix2 - ix1); I think that at least extents->x (and y) should still be rounded
I confirm the 40 new failures on image tests (but to see those one have to grep the test-suite.log , that is the report tells 1 failure with or without the patch. The fix you suggested (to round extends x and y) brings back those 40 new failures to 1 new failure (in filter-nearest-transformed) here. I am still on the old code base from march though. This also fixes the white line on gimp right edge of the progress bars, but I was unable to see what was the artifact for "images rendered on canvas". The bug this report was about is still fixed with this change. I am now looking at this last test case difference , that is filter-nearest-transformed.
Could you revert the original patch ? The rationale was good and it fixes a real bug . Only I now realized the patch needs more works including a test case. I will attempt to do it this summer. Sorry for the inconvenience . Also feel free to fix the issue before I do.
Created attachment 116664 [details] "image rendered on canvas" screenshot The image is a two layers with slightly different size (1 white and the other transparent) in a layer group and should be rendered solid white apart from the borders. Because GIMP renders it in tiles it shows vertical gaps here and there and restoring the previous computation of ->x and ->y (rounding them rather than truncating) the artifacts disappear.
This breaks icon drawing in GTK+. The right hand side of icons/images is cut off sometimes.
As per comment #8, the patch is reverted. To ssh://git.cairographics.org/git/cairo edd321c..6951fb4 master -> master
I managed to track the origin of this issue that is commit 45934f69cd158b7bb5632f5e4334a156795147f4 "image: Corrected extents calculations". This bug disappear if I revert this commit on top of 1.14.8 . I guess it was first in a release at 1.14.0 . The above commit deals with advanced optimisation of the filter code. I cannot evaluate where the regression is.
I generated output anew with cairo 1.15.10-1 from Debian sid and the glyphs are rendered fine. Closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.