I have done a bugzilla search and cannot find a similar report.  I hope that this report is helpful.

cairo_set_dash() and subsequent stroking only seems to work properly when the target surface fallback resolution matches the actual device resolution.  For example, with PDF & postscript surfaces, cairo_surface_set_fallback_resolution(s, 72, 72) works, while the default 300x300 does not.  For win32 printers, the fallback resolution must be set to the actual printer resolution.  Again, the default 300x300 does not work.

The effect of this behaviour is that the output differs completely when outputting to PDF (eg. Linux) versus output to a win32 printer.  It also means that for some high res printers a spool file size of >100Meg (under win32) is not uncommon.  The unnecessarily large resolution of the spool file slows things down considerably both in generation as well as production.

To demonstrate the problem, apply the following 2-liner patch to test/fallback_resolution.c.  The overshoot in stroking the dashed lines is very evident.

--- old/fallback-resolution.c	2008-08-20 14:06:39.000000000 +0200
+++ new/fallback-resolution.c	2008-08-20 14:06:33.000000000 +0200
@@ -50,9 +50,10 @@
     cairo_text_extents_t extents;
 
     cairo_save (cr);
-
+    double dash[] = {1.0,2.0,3.0};
+    cairo_set_dash(cr, dash, 3, 0);   
     cairo_new_path (cr);
-
+    
     cairo_set_line_width (cr, .05 * SIZE / 2.0);
     cairo_arc (cr, SIZE / 2.0, SIZE / 2.0,
 	       0.75 * SIZE / 2.0,