Comment 13 for bug 215902

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.