Not waiting for cairo, I hacked my own cairo_clone() function that faithfully copies the clip, and used it in [CairoGState -copyWithZone:]. While it continued to display to the screen OK, the printing got worse, not better. It appears that the bounding box is not correctly computed from the paper size and margins. Furthermore, one of the clipping rectangles is misplaced vertically. The problem is especially severe when trying to print a small view on a larger piece of paper; the clipping rectangles do not intersect, so nothing prints at all. You can demonstrate this with TestApp by playing with the window size and paper size.

When I use cairo_reset_clip() after cairo_clone(), the printing behavior is the same as the original. There are still some errors in clipping and placement, but not so severe. For most cases, the worst problem is wrong margins.

My cairo hack is probably not suitable for general use. It may be handy to see what is wrong while waiting for the official cairo_copy_clip() to appear.

(file #14421, file #14422)

Nuts! My changes break NSScrollView. I'll have to give up on that idea for now.

Sorry, but my test code shows that there is a problem in cairo and this needs to be resolved.

As for the idea of replacing copy with save/restore I had that before and even tried it in code. There are various issues with this approach. First, the cairo implementation is a stack only, but in GNUstep we need to access stored gstates (for windows and views). This is just not possible in cairo.
Second, cairo does not store the path on the stack, we would need to keep this on a separate stack.
Third, I have no idea if save would copy the clip region correctly for PS.

Your last note I did not understand :-(

I wrote a small test program and this shows that the problem with the clip copying is completely within cairo. Here is the code:

#include <stddef.h>
#include <cairo.h>
#include <cairo-ps.h>

int
main (int argc, const char *argv[])
{
  cairo_status_t status;
  cairo_t *ct;
  cairo_surface_t *surface;
  cairo_rectangle_list_t *clip_rects;
 
  surface = cairo_ps_surface_create("test.ps", 100, 100);
  status = cairo_surface_status(surface);
  if (status != CAIRO_STATUS_SUCCESS)
    {
      printf("Cairo status '%s' for surface\n", cairo_status_to_string(status));
      return 0;
    }

  ct = cairo_create(surface);
  status = cairo_status(ct);
  if (status != CAIRO_STATUS_SUCCESS)
    {
      printf("Cairo status '%s' for context\n", cairo_status_to_string(status));
      return 0;
    }

  cairo_reset_clip(ct);
  cairo_rectangle(ct, 10, 10, 80, 80);
  cairo_clip(ct);
  clip_rects = cairo_copy_clip_rectangle_list(ct);
  status = clip_rects->status;
  if (status != CAIRO_STATUS_SUCCESS)
    {
      printf("Cairo status '%s' in copy clip\n", cairo_status_to_string(status));
    }

  cairo_destroy(ct);
  cairo_surface_destroy(surface);
}


Compile with the usual command (eg. gcc -I/usr/local/include/cairo cairo.c -L/usr/local/lib -L/usr/X11R6/lib -lcairo -lm -lfreetype -lz -lfontconfig -lexpat -lpng12 -lXrender -lX11 -lpthread -o cairo_test)

THis leaves only the positioning of the draw area to be resolved in GNUstep.

Update on clipping: Cairo has 3 different representations for the clip. Only one can be accessed by the public API: a list of rectangles. If there is a non-rectangular clip, it is represented differently, and the public API returns an error message. I can't find where it is happening, but somewhere, something sets a clip path that has a superfluous moveto() that ultimately errors out. CairoGState.m -copyWithZone: tries to copy the clip path, fails, logs the error, and continues on with no clip in the copy.

I had a look at the cairo PS file. It surely isn't a bitmap format. If you have a closer look you will see a the lineto and moveto commands you would expect. The whole file is incorrectly scaled and the font looks ugly. As far as I can see from the PS file cairo has to create the glyphs of the font by defining an image per glyph. This is a very bad sign. It could mean that cairo has no idea, which replacement PS font to use for your screen font.
If I remember correctly you had some problems to get a proper screen font from the cairo backend. Which font did you choose in the end? Was it a bitmap font? This could explain the whole behaviour.
There is a big difference between art, which uses nfont where you may define the font to PS mapping yourself and the cairo backend, which relies on cairo to replace the font.

Could you look into the scaling problem yourself? Printing isnt currently on my priority list and I remember you doing some great stuff there before.

Tried again with SVN 25519. I tested two apps with Print...Save. There is a problem with clipping; the error message is "Cairo status clip region not representable in desired format in copy clip." The PS file while readable is improperly clipped. The text and vector art are rendered as a bitmap at screen resolution. The sample file "cairo-0013.ps" is typical. I also included "art-0013.ps" for reference.

(file #14098, file #14099)

Please try once more with the current implementation of PS generation in the cairo backend. The result should be somewhat better. Still no EPS though, but they are discussing the addition of a EPS format on the cairo mailing list.

Use the TestApp submitted with bug report #19350. Be sure to set the compositing operation to Copy. Do "Save View As..." with EPS as the export format. View the resulting eps file with gv or evince. No errors with the art backend, but "unrecoverable errors" using the cairo backend.

No idea what this is all about. Fonts? This error also prevents postscript printing.

System: Suse Linux 10.1; Parallels Virtual Machine over Mac OSX; GNUstep svn 24903