Created attachment 107371 [details] Horizontal dotted line, gets misrendered by poppler Fat Dotted lines are not always rendered correctly. See for example the attached pdf file "test.pdf", which was created using the following python snippet: ----------------------- import numpy as np import matplotlib.pylab as plt fig, ax = plt.subplots() fig.patch.set_visible(False) ax.axis('off') myx = np.linspace(0,1) plt.plot(myx, np.zeros_like(myx), "b:",linewidth=10) plt.savefig("test.pdf") ------------------------ When I open the resulting file in okular, I get annoying fat dots along the horizontal line as shown in the attached file "test_dump.png". If I save instead of .pdf in .png (or .eps) format, okular gives me what is shown in "test_dump_correct.png", which is also resembling what comes on the screen. This misrenedering happens with okular, but also with xpdf, which brought me to the conclusion that this might be a problem in poppler, which I understand is the underlying library.
Created attachment 107372 [details] fat dots appear in the horizontal line, which should not be there
Created attachment 107373 [details] expected rendering of horizontal line
Created attachment 107374 [details] fat dots appear in the horizontal line, which should not be there
Created attachment 107375 [details] Horizontal dotted line, gets misrendered by poppler
I'm regtesting a patch, let's see if it doesn't break any file
meh, the patch regresses other files, need to study more the code.
Created attachment 122346 [details] [review] Avoid line joins on dashed lines This patch could be a possible solution. @Albert: I'm not sure if You like it, but I don't have any better idea at the moment. And because that PDF is rather hypothetical (instead of one moveto and one lineto tons of lineto's to draw one horizontal line) I wouldn't care if You reject this patch J
Stop any investigation! I just encountered a hint in the spec: Join styles shall be significant only at points where consecutive segments of a path connect at an angle; segments that meet or intersect fortuitously shall receive no special treatment. If I take that into account, I can solve this issue without any doubt. I just regtest a new patch.
Created attachment 122372 [details] [review] Omit join styles if angle is 0 This patch solves it
I'm going to go on the almost-nit-picking side and say that the "+" signs of the attached page have rounded corners on Adobe Reader (old linux version, if you have a newer windows version around check, maybe it changed) and the unpatched poppler but with your patch they don't have them anymore (have to zoom a lot to see the difference). Do you think it's worth investigating why?
Created attachment 122427 [details] Problem on the + signs
(In reply to Albert Astals Cid from comment #10) > I'm going to go on the almost-nit-picking side and say that the "+" signs of > the attached page have rounded corners on Adobe Reader (old linux version, > if you have a newer windows version around check, maybe it changed) and the > unpatched poppler but with your patch they don't have them anymore (have to > zoom a lot to see the difference). > In the actual windows versions it has round corners, too, so it's not nit-picking, it's a really regression! > Do you think it's worth investigating why? Of course, even it can become heavy. I first will try to reduce it to the plus signs. I wonder, why it runs into the line join section in splash... I need to find out. If I just look at the output it should run in the line cap section... I come back when I find the reason.
I think, I have it: The plus signs are drawn to and from to the endpoints, so the endpoints are no really endpoints and therefore no line caps, but there are line joins. But my former patch doesn't distinguish between an angle of 0 and an angle of 360 degrees. I'll upload a new one.
Created attachment 122438 [details] [review] Omit join styles if angle is 0 This also detects angles of 360 degrees
I see some small changes in rendering in page 60 of bug-poppler77549-3.pdf (bottom right) and page 114 of title_font_compresses.pdf Not sure if you have those files $ sha256sum bug-poppler77549-3.pdf 5485834aee424661a4fa49fdeaab650e4d57834fc0cafbf989a29db501b5106e bug-poppler77549-3.pdf $ sha256sum title_font_compresses.pdf ca35993bc13a2a14fa48440740b727e6a971739fd7f4090c9ecd9486358c94ec title_font_compresses.pdf
(In reply to Albert Astals Cid from comment #15) > I see some small changes in rendering in > page 60 of bug-poppler77549-3.pdf (bottom right) > and > page 114 of title_font_compresses.pdf > > Not sure if you have those files > I have bug-poppler77549-3.pdf, but I can't find title_font_compresses.pdf. I looked at the page 60 and can confirm that the output is different with and without the patch, but to be true, I can't see the difference, neither in comparing the PNG's nor by looking at the difference picture, even if rendered with 300 dpi. So I created an histogram of the difference picture (300 dpi, colorspace grey): Histogram: 155530745: ( 0, 0, 0) #000000 gray(0,0,0) 1: ( 0, 0, 0) #000000 gray(0,0,0) 3: ( 1, 1, 1) #010101 gray(1,1,1) 18: ( 2, 2, 2) #020202 gray(2,2,2) 14: ( 3, 3, 3) #030303 gray(3,3,3) 12: ( 4, 4, 4) #040404 gray(4,4,4) 1: ( 5, 5, 5) #050505 gray(5,5,5) 1: ( 6, 6, 6) #060606 gray(6,6,6) 5: ( 18, 18, 18) #121212 gray(18,18,18) I interprete this that from round about 155 million pixels there are 55 pixels different, with a highest difference of 18, so not completely different but there are differences in anti aliasing effects. And when I look at the page itself I encounter that there are a lot "dashed" vertical or horizontal lines, and my patch omit join styles for horizontal and vertical lines, which seems to be correct according to the PDF spec. If You have another opinion please give me more information where You worry about. If You think that the differences of title_font_compresses.pdf has other reasons please send me that pdf so that I can have a look at it.
Created attachment 123631 [details] the diff of renderings of page 60 of bug-poppler77549-3.pdf Look at the bottom right-ish part, there's a vertical line that is around 9 pixels tall that changes, seems a specific enough change that may be a problem? I can be convinced it's "ok", but 9 pixels one after the other seems a reasonable "big ish" change.
Created attachment 123639 [details] rendered with 600 dpi new, 72 dpi new, 72 dpi old You are really good in detecting differences, Albert. I haven't seen the differences before. But I fear I can't do anything in this case, look at this screenshot, from left to right: - is rendered with 600 dpi with my patch. You see a nearly solid line, and the output is with 600 dpi the same or nearly the same as without my patch - is rendered with 72 dpi with my patch - is rendered with 72 dpi without my patch My conclusion is that the vertical line must be a dashed line, but so thin, that even with 600 dpi You can't see the gaps, there it just looks like a solid line, where with 72 dpi you can see some anti-aliasing effects of the dashes which are different because omitting the join styles.
Created attachment 123640 [details] the same clip with acrobat zoomed to 1200 % This is how acrobat shows it when zoomed to 1200 %. It is similar what pdftoppm produces when rendered with 600 dpi, but acrobat has some special handling for thin lines. And one last point: The differences vanishes between with and without my patch when increasing the resolution!
Ok, you've convinced me. Pushed!
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.