bugGNUstep - Bugs: bug #19352, Cairo: bad EPS from...


bug #19352: Cairo: bad EPS from NSView_dataWithEPSInsideRect:

Submitter:  Mark Tracy <tracy454>
Submitted:  Tue 20 Mar 2007 07:06:29 AM UTC
Category:  Backend Severity:  3 - Normal
Item Group:  Bug Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Mon 07 Jan 2008 02:10:59 PM UTC, comment #17: 

I had a look at your patch and it is too low level to keep it in GNUstep. We would depend upon the internals of cairo. What you could do is lobby for the inclusion of a similar extension into cairo. Using that code would be fine for GNUstep.

Fred Kiefer <FredKiefer>
Group Member
Sun 18 Nov 2007 05:36:05 AM UTC, comment #16: 

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)

Mark Tracy <tracy454>
Fri 26 Oct 2007 09:51:22 PM UTC, comment #15: 

On the cairo mailing list I got the following reply:

   This is already in TODO:
      • cairo_copy_clip() and cairo_copy_clip_flat()

Lets hope they implement it soon.

Fred Kiefer <FredKiefer>
Group Member
Thu 25 Oct 2007 05:49:38 AM UTC, comment #14: 

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

Mark Tracy <tracy454>
Wed 24 Oct 2007 06:57:08 AM UTC, comment #13: 

First, I should apologize for my confused previous post. I should not try to write intelligently after dental surgery.

The list of clipping rectangles is a feature of the pixman library that cairo uses for operations in device-space of pixelated surfaces, in particular the Xlib and image surfaces. Since PS and PDF are vector surfaces, they don't use pixman, and hence can't produce the list of clipping rectangles. Therefore I had to do something drastic. (Why the authors of cairo made the list of rectangles part of the public API is very mysterious, since it only works for some surfaces. The docs don't make this clear; I had to read code to figure this out.)

The attached patch does four things:
1) It implements a different copyWithZone: that relies on cairo_save() to copy the cairo context info.
2) It overrides DPSgrestore to add a cairo_restore()
3) It suppresses the _adjustpath operation.
4) It fixes an unrelated compiler warning.

So far, it has tested well for me, but it needs more scrutiny. The first benefit is that printing no longer chokes my shared printer. The second is that my chromatograms are much prettier because they now display and print at high resolution. Look at the new version of cairo-0013.ps. The third benefit is much shorter code.

I still have the problems with print scaling and margins, so it didn't fix that. The positioning is definitely related to print margins, but at this point it is not clear whether that is GNUstep or me that has the problem.

(file #14188, file #14189)

Mark Tracy <tracy454>
Wed 17 Oct 2007 04:44:18 PM UTC, comment #12: 

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 :-(

Fred Kiefer <FredKiefer>
Group Member
Wed 17 Oct 2007 05:50:41 AM UTC, comment #11: 

Indeed! Trying to write a PDF surface has the same fault, but there is no problem with an image surface. I think this goes back to the lack of a real cairo_copy(context). From looking at the cairo code, I must conclude that the authors don't want us to make copies of contexts, rather, they want us to use the cairo_save/cairo_restore mechanism. I think there is a way to do this. If you override DPSgsave and DPSgrestore in CairoContext.m then you should be able to use the cairo functions instead of writing your own copy method. This probably has side-effects I haven't yet discovered. Do you think this would work? (Save this for back-014)

On a related note, when I tried to beautify my chromatograms by suppressing _adjustPath, I got hundreds of copy clip errors just by moving the mouse pointer. It did make prettier chromatograms.

Mark Tracy <tracy454>
Tue 16 Oct 2007 04:44:02 PM UTC, comment #10: 

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>

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_rectangle(ct, 10, 10, 80, 80);
  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));


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.

Fred Kiefer <FredKiefer>
Group Member
Mon 15 Oct 2007 04:08:08 PM UTC, comment #9: 

Thank you for this additional information. Especially the hint to the moveto could be helpful. What I am wondering about is that you only get the clip problems when generating Postscript, doing exactly the same operations in a window works. This could mean that we do something wrong while printing or that cairo itself has a problem here.

Fred Kiefer <FredKiefer>
Group Member
Mon 15 Oct 2007 01:11:27 AM UTC, comment #8: 

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.

Mark Tracy <tracy454>
Tue 09 Oct 2007 05:49:16 AM UTC, comment #7: 

You were right. I was using "Adobe Helvetica" which much to my surprise was in fact a screen font without a matching vector font. Using real vector fonts works as promised.

I'll see what I can find on the scaling and clipping issues.

Mark Tracy <tracy454>
Sun 07 Oct 2007 10:54:05 AM UTC, comment #6: 

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.

Fred Kiefer <FredKiefer>
Group Member
Sat 06 Oct 2007 05:17:53 PM UTC, comment #5: 

I forgot to say that the PS files (from Cairo) are readable with Evince, but that they don't print. Apple's postscript filter for CUPS chokes.

Mark Tracy <tracy454>
Sat 06 Oct 2007 07:06:26 AM UTC, comment #4: 

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)

Mark Tracy <tracy454>
Wed 03 Oct 2007 04:07:41 AM UTC, comment #3: 

I'm still struggling with #21203. As soon as I get a handle on that, I'll try PS again.

Mark Tracy <tracy454>
Tue 02 Oct 2007 10:48:40 PM UTC, comment #2: 

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.

Fred Kiefer <FredKiefer>
Group Member
Tue 20 Mar 2007 11:32:39 PM UTC, comment #1: 

Yes, this about fonts. In the art backend it seems like fonts are stored with the Postscript font names. There are also a few extensions there for the output of glyphs.
As all of this is implemented based in Freetype it should not be too hard to extract this code into a shared Freetype font class to be used by different backends.

Fred Kiefer <FredKiefer>
Group Member
Tue 20 Mar 2007 07:06:29 AM UTC, original submission:  

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

Mark Tracy <tracy454>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #14421:  cairo_clone.patch added by tracy454 (4KiB - text/x-patch)
file #14422:  TestApp.tar.bz2 added by tracy454 (72KiB - application/x-bzip)
file #14188:  MT_23-Oct-07.patch added by tracy454 (7KiB - text/x-patch)
file #14189:  cairo-0013.ps added by tracy454 (227KiB - application/postscript)
file #14099:  art-0013.ps added by tracy454 (166KiB - application/postscript - Example postscript files.)
file #14098:  cairo-0013.ps added by tracy454 (139KiB - application/postscript - Example postscript files.)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by tracy454 (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-11-18 tracy454 Attached File- Added cairo_clone.patch, #14421
        Attached File- Added TestApp.tar.bz2, #14422
    2007-10-24 tracy454 Attached File- Added MT_23-Oct-07.patch, #14188
        Attached File- Added cairo-0013.ps, #14189
    2007-10-06 tracy454 Attached File- Added cairo-0013.ps, #14098
        Attached File- Added art-0013.ps, #14099
    2007-03-20 FredKiefer StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-6ae7.
    Corresponding source code