Recordable optical media, such as CD-R, DVD+\-R discs, possess several properties that may prove beneficial in their use as rotary encoder codewheels:

• Commonly available and economical
• Capable of extremely high resolution compared even to top-of-the-line InkJet printing (4800DPI?)
• Well-defined physical dimensions and tolerances
• Fairly resilient in terms of physical composition and resistance to environmental exposure.

The primary difficulty in "printing" arbitrary geometry into the data side of recordable discs is the additional encoding that optical drives perform on the data after being received from API's but prior to being written to the physical media.  Identifying the processes that take place and what capabilities are afforded to the API consumer has taken a great deal of study - of which the following resources have proven most helpful to me: CD Cracking Uncovered, CD-R FAQ, 13th Monkey's SCSI/MMC spec docs, and the source code for cdrtools.

Most notably: the Eight-to-Fourteen-Modulation (EFM) process, while serving to run-length limit the data,  chooses merging bits that result in a "digital sum value" (aka "running digital sum") as close to 0 as possible, so that the self-driven clock (as set by the spindle RPM) receives the highest resolution of ticks achievable.  In other words, it encodes the data so that there are as equal number of pits as there are lands as is possible - this effectively removes any visual distinction between substantially different strings of user data.  Therefore, our only option for visual distinction is to be able to write via random-access where the visual distinction is achieved by the presence of, and complete lack of, data.  Another option, which restricts the use of the codewheel to laser pickups, is to reliably determine what the user data will be transformed into, and attempt to make it as ideal as possible - though something like grey code is certainly out of the question.