Created attachment 134098 [details] Test files with two dashed lines The attached patch fixes a few bugs in how Arthur handles line dash patterns. I'll also attach a test document.
Created attachment 134099 [details] [review] Patch fixing dash pattern bugs
Very interesting pdf, we don't show it totally correctly in the cairo/splash backends either since the beginning/end of the polyline are missing.
It's a nice change! But I think i found a minor regression, have a look at the "input is legal" dashed line in the attached page, it goes from having ~12 segments on the top to having ~8. Splash, Cairo and Adobe both render 12 segments on top so i think that's a regression
Created attachment 134109 [details] the said file
Are you sure? On my machine, the Arthur backend renders 12 dashes just like the others. Can you post a screenshot of how my own test file is supposed to look? I don't have easy access to Acroread.
As I understand it, the missing beginning/end of the polyline are not bugs in the renderers. Rather, the polyline is an annotation, and I guess there is something missing in the annotation support. Getting that fixed would be very nice, but it is way beyond my skill level. I'll attach the LaTeX source, in case that helps.
Created attachment 134118 [details] LaTeX source of the test file
(In reply to oliver.sander from comment #5) > Are you sure? On my machine, the Arthur backend renders 12 dashes just like > the others. Unpatched Arthur renders 12 dashes, patched one renders less (8 dashes) New: http://i.imgur.com/vwgShdl.png Old: http://i.imgur.com/fnoYuZg.png
This is strange, but I cannot reproduce this. In fact, without the patch I get 16(!) dashes, not 12 like you do. With the patch I get 12. Can I ask you to commit the patch despite the regression? Here's why: - The patch fixes definite bugs. - The state of line dashing is so broken without the patch that it is difficult to speak of regressions. - I cannot fix your problem anyway, because I cannot reproduce it. Thanks.
This does have a regression, I prefer not to commit known regressions unless there's a good reason to. What are you using to render? I'm using build-new/qt5/tests/test-render-to-file-qt5 -arthur
I use Okular with https://git.reviewboard.kde.org/r/130235/
I guess it wasn't obvious, i'm asking you to use the same tools i am using to see if you can reproduce the problem.
Makes sense :-) I didn't know about that test thingy. Anyway: Now I can reproduce the problem, and I'll have a look.
I had a look today, and it smells a bit like a Qt bug. The dashed line has width 0.7, and Qt line dashes do not behave as advertised when the line width is below 1. The fact that it works without my patch seems to be a coincidence. I am not sure yet why the line dash looks okay in Okular. To demonstrate the problem I have written a short test program (attached). It uses Qt only, and has no dependency on poppler. According to the documentation of the QPen class, http://doc.qt.io/qt-5/qpen.html#setDashPattern it should produce four parallel lines of thickness 4, 2, 1, and 0.5, all with the same pattern. However, while the line thicknesses come out right, only the first three lines have the correct pattern. Suggestions?
Created attachment 134559 [details] Minimal test program triggering line dash weirdness
Created attachment 134560 [details] Output file of the test program
You seem to have found a bug in QPainter, you may want to report it even though i doubt they'll be very happy to fix it. Anyhow whatever i'll commit this patch.
Upstream bug report at https://bugreports.qt.io/browse/QTBUG-63530
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.