Best practice of copying and serializing Quartz references
Asked Answered
C

1

2

I have objects containing Quartz-2D references (describing colors, fill patterns, gradients and shadows) in Cocoa. I would like to implement the NSCoding protocol in my objects and thus need to serialize those opaque Quartz-2D structures.

Possible solutions might be:

  • Define a set of properties in my objects that allow to setup the data structures from scratch whenever they are needed. Those can then be serialized easily. Example: Store four floats for red, green, blue, and alpha, then use CGColorCreate. Disadvantage: Duplication of information, thus potential consistency and (so far minor) space consumption issues. I would need to write property setters manually that recreate the Quartz structure whenever a component changes. That would bloat my code substantially.

  • Read out the properties using Quartz functions. Example: Use CGColorGetComponents for colors. Disadvantage: It seems to work for colors. But there are no equivalent functions for other structures, so I don't see how this could work for things like gradients, shadings, shadows etc.

  • Read out the properties directly from the raw, opaque structures. Disadvantage: As the documentation says, the structures are supposed to be opaque. So in case something changes under the hood, my code will break. (Apple certainly would not have provided a function like CGColorGetComponents if that was supposed to be done.) Furthermore, things like the CGFunctionRef inside a CGShadingRef would really be asking for trouble.

What is the best practice for serializing Quartz structures?

Cohdwell answered 16/10, 2010 at 17:33 Comment(0)
D
6

The answer pretty much varies from one class to the next:

  • CGImage: Use CGImageDestination to make a TIFF file of it. (Equivalent to NSImage's TIFFRepresentation method.)
  • CGPath: Write an applier function you can use to describe the path's elements as, say, PostScript code. Write a simple interpreter to go the other direction.
  • CGColorSpace: You can export the ICC representation.
  • CGColor: As you described, but don't forget to include the color space.
  • CGLayer: Convoluted: Make a bitmap context, draw the layer into it, and dump an image of the context, then serialize that.
  • CGFont: The name should be enough for most applications. If you're being really fancy (i.e., using the variations feature), you'll want to include the font's variations dictionary. You'll have to maintain your knowledge of the font size separately, since CGFont doesn't have one and CGContext doesn't let you get the one you set in it.
  • CGPDFDocument: From a quick look, it looks like CGPDFObjects are all immutable, so you'd just archive the original PDF data or the URL you got it from.
  • CGGradient, CGPattern, CGShading, and most other classes: Yup, you're screwed. You'll just need to maintain all of the information you created the object with separately.
Demulsify answered 16/10, 2010 at 22:13 Comment(1)
Thanks, that is indeed very detailed and useful. Unfortunately, it seems that there is no way to avoid having to double code the information for the objects I am interested in. And I would have forgotten about the color space of CGColor if you hadn't reminded me, particularly thank you for this one!Cohdwell

© 2022 - 2024 — McMap. All rights reserved.