[cairo] PDF Issue in OS X Preview

[Behdad Esfahbod]

On Wed, 2006-10-25 at 21:24 -0400, Behdad Esfahbod wrote:
> On Wed, 2006-10-25 at 18:28 -0400, Ryan Schmidt wrote:
> > On Oct 25, 2006, at 11:55, Ken Treis wrote:
> > 
> > > I'm generating PDFs using the Ruby bindings and cairo-1.2.4.  
> > > Everything works fine for me until I try to set scaling. The  
> > > resulting PDF files look fine in Acrobat Reader but not in OS X  
> > > Preview.
> > 
> > [snip]
> > 
> > Thanks for writing. I too reported a problem with cairo-generated  
> > PDFs which looked fine in Adobe Reader but not OS X Preview. I'm not  
> > sure if your case is the same as the one I was seeing. My problem was  
> > that my PDFs are generated by graphviz, and I was unsure if the  
> > problem was in cairo, graphviz, or Mac OS X's PDF renderer. Your  
> > message gives me hope that it might be a cairo problem after all.
> > 
> > Unfortunately we didn't get very far in trying to solve the problem I  
> > reported:
> > 
> > http://lists.freedesktop.org/archives/cairo/2006-July/007344.html
> > 
> > I did get far enough to see that it looks like Preview *is* rendering  
> > the missing curves, just not at the desired offset:
> > 
> > http://lists.freedesktop.org/archives/cairo/2006-July/007463.html
> > 
> > Note that the glyph difficulties reported in the latter mail have  
> > already been resolved in the current version of cairo; only the curve  
> > offset problem remains for me.
> > http://cairographics.org/cgi-bin/mailman/listinfo/cairo
> 
> This is a bug in cairo.  The generated PDF output from cairo:
> 
> 10 M 100 100 m 100 200 l q 2 0 0 2 0 0 cm
> S Q
> 
> is undefined according to the PDF spec version 1.6.  According to Figure
> 4.1 Graphics Objects on page 167, all gstate manipulations should occure
> before path construction that should be followed by path-painting
> operations.  It further clarifies on the following page:
> 
> "Note: A content stream whose operations violate these rules for
> describing graphics objects can produce unpredictable behavior, even
> though it may display and print correctly."
> 
> and:
> 
> "A graphics object also implicitly includes all graphics state
> parameters that affect its behavior. For instance, a path object depends
> on the value of the current color parameter at the moment the path
> object is defined. The effect is as if this parameter were specified as
> part of the definition of the path object."
> 
> 
> Simply moving the cm operator before path construction should fix it:
> 
> 10 M q 2 0 0 2 0 0 cm 100 100 m 100 200 l
> S Q
> 
> 
> Any takers?

Should be fixed now, in this commit:

  e1ded5b1e042c8cefa7f136228d5a63a7bdf84b5

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
        -- Dan Bern, "New American Language"