User data can be attached to a UFO process instance and to a UFO editor instance. This can be set and accessed within any user functions using ufoProcessSetUserData, ufoProcessGetUserData, ufoEditorSetUserData, and ufoEditorGetUserData, respectively.
If a UFO process instance is copied, then the associated process user data can be copied with a user-defined method by supplying the user function ufoProcessCopyUserData. Similarly, if a UFO process instance is destroyed (that is, put away) it can be tidied up with a user-defined method by supplying the ufoProcessDeleteUserData user function.
There are user functions to facilitate reading and writing of UFO user data from and to a process file on disk, along with the standard parameter and input and output settings of UFO process. The data may be saved and loaded in ASCII format by supplying the ufoProcessWriteAsciiData and ufoProcessReadAsciiData user functions, respectively. Alternatively, the data may be saved and loaded in binary format by supplying the user functions ufoProcessWriteBinaryData and ufoProcessReadBinaryData, respectively.
Currently, there is only one UFO editor instance in existence at any one time, therefore there are no corresponding ufoEditorCopyUserData and ufoEditorDeleteUserData user functions. If a UFO editor were to be destroyed, the editor user data can be tidied up with a user-defined method by supplying the ufoProcessDeleteUserData user function.
UFO writers should refrain from using global data in their UFO code for storing structures and values commonly used during rendering, and adopt a method which distinguishes between the different instances of a UFO using UFO user data. Essentially, this is to safeguard against multiple instances of the same UFO process being used simultaneously and accessing the same data. In particular, writing to global data during rendering is likely to cause errors if multiprocessing.
