dashed line type pdf problem

Sorry we've never replied here.

I just tested this with cairo 1.6.2 and it appears to be working just fine.

That is, with 1.6.2, we don't use fallbacks anymore for the gradients, so the bug is hidden.

I think the bug is likely still present with dashed lines and fallbacks, but it's going to be harder to hit, (since in 1.6 getting fallbacks in cairo-pdf is much harder).

So please upgrade to 1.6 and see if that doesn't fix your problems.

In the meantime, I'll leave this bug open so we can look into the "mis-sized dashing with PDF and fallbacks" issue.

-Carl

*** Bug 17223 has been marked as a duplicate of this bug. ***

*** Bug 13411 has been marked as a duplicate of this bug. ***

This may a duplicate of bug 17723, but it's not at all "hidden". I see Carl Worth says he tested the code in this bug report, and it "is working". My problem, on the other hand is not noticeably absent.

It's quite easy to replicate- especially with printer surfaces. Bug 17723 lists a 2-liner patch to fallback_resolution.c which demonstrates exactly how easy it is; simply set the line style to dashed lines instead of solid lines in that example, and voila- an instant mess.

In fact in my opinion it's impossible to draw dashed lines to a printer context without this problem occurring, unless you set the fallback resolution of the surface to match the physical device resolution.

That means that for some win32 printers, the fallback resolution must be set to 1200x600 [inefficient], where for PDF and postscript, the fallback resolution must be set to 72x72 [insufficient]. Besides the fact that anything at 72x72 resolution looks like rubbish, the PDF/Postscript result is inconsistent with win32 output.

Of course, since there is a single fallback resolution for the whole surface, the inconsistency does not just apply to dashed lines; If you adjust the fallback resolution to something nonsensical like 72x72 just to get the dashed lines working, the whole graphic is rendered in that resolution- not just dashed lines.

This is a major problem when producing output for printers where the graphic contains dashes.

If anyone has any work-arounds in the interim, I would be most grateful.

(In reply to comment #4)
> This may a duplicate of bug 17723, but it's not at all "hidden". I see Carl
> Worth says he tested the code in this bug report, and it "is working". My
> problem, on the other hand is not noticeably absent.

Indeed and the bug is now dutifully reported by the test suite and I've used your report as an example of how it still exists within cairo-win32-printing and affects users. So since it is now painfully obvious that cairo is broken, I hope to see a fix soon.

Is there anything I can do to help fix the problem? I did try digging into the code, but I am afraid it's rather above me. Perhaps with some pointers as to where to look, or some hand-holding, I could do some of the drudge work?

(In reply to comment #6)
> Is there anything I can do to help fix the problem? I did try digging into the
> code, but I am afraid it's rather above me. Perhaps with some pointers as to
> where to look, or some hand-holding, I could do some of the drudge work?

Well, we know the problem is stroking dashes under a fallback image so the issue is likely to be confined to _cairo_stroker_line_to_dashed() in src/cairo-path-stroke.c (and its inputs). If you are interested, I'd read through that function taking note of what matrices are used and then tracing back to see their construction. Then either you spot the problem straight-away, or you can start comparing the difference between difference fallback resolutions. If you can join us on irc, in #cairo on irc.freenode.net, we'll happily help you learn the code and assist in whatever way we can.

Thanks- I'll get out my spade and go digging. I will let you know what I find.

Fixed with

http://gitweb.freedesktop.org/?p=cairo;a=commit;h=5911c6966de832fa350a6e9a4d587b7c3b3b4825