Paint type on black plane only

Question

This question comes up fairly frequently :
1. Start a blank document, in the blank document insert a box for type (Insert > Text Box), set the type size for the default copy in the box to 18pt or 24pt, and open the Apple Colour Picker (View > Show Colours).
2. Type deviceK, select Return to start a new line, and type ICCBased.
3. Select the word deviceK in the first taking care not to select the word ICCBased in the second line, set the Apple Colour Picker to CMYK Sliders, click the Colour Model / Colour Space icon to the left of the CMYK Sliders, scroll down to select Device CMYK, and set the CMYK Sliders to C0 M0 Y0 K100.
4. Don't select the word ICCBased, taking care to leave the default colour model and colour space set by the software and the system.
5. Export as PDF/X-3 with OutputIntent.
6. Open in an auditing application such as Acrobat Professional and select separations preview. Disable the cyan plane/plate, the magenta plane/plate, the yellow plane/plate and note that the word deviceK only paints on the black plane/plate. Select a PDF/X-3 audit and note that there is no CIE reference for the word deviceK (neither a PostScript calibrated colour space nor an ICCBased profile) whereas the word ICCBased references Apple's Generic RGB Profile with the alternate colour space being Apple's Generic Gray Profile. In separations preview the word ICCBased is painted on four planes/plates.
As far as I am aware, this configuration is technically correct. However, if drop shadows are applied to the words or if the words are sandwiched in a transparency/opacity blend space it becomes much more complex. What is or is not correct in that context is uncertain, or perhaps better that I'm uncertain of what would and what would not be correct.
/hh

Answer 1

Do you see major problems if all the OS's and apps including eventually Apple standardize on OpenType for internationalization rendering and AAT/GX fades away?
In answering a question, the first step is to determine what criteria are applicable to considering that an answer has been given. I'm not sure what you would consider an answer, since we have discussed this for a year and a half, and you began by rejecting the simplest level which was improved invertibility for character-glyph-character transforms and improved input methods for interactive identification of character information.
Briefly, the purpose of TrueType Specification 1.0 of 1990 is to establish a drawing model for composition wherein which by definition character processing is separable from glyph processing, and the purpose of separating character processing from glyph processing is to avoid that desired glyph designs be drawn by depiction onto incorrect public characters or alternatively by depiction onto private characters.
TrueType Specification 1.0 supports this model by being indefinitely extensible, and by being indefinitely localisable for extensions. Apple supports this which means that were one to want a feature selector / rendering intent uniquely defined in user space then that is possible and localising that is possible in ISO 10646/Unicode strings (see Specification 1.0 for details). In this sense, the application is the client of the layout in the intelligent font which is what David Lemon and Thomas Phinney of Adobe have posted time and time again that Adobe does not want.
David Lemon posted in 1997 the business model for OpenType which is application-dependent drawing. David Opstad posted the objection, and published the objection in a paper on Apple's drawing implementation versus Microsoft's drawing implementation. By definition, if the application does not have to support the feature selectors / rendering intents in the font file, which will preserve the source character string and the glyph run in the backing store, the workaround is for type makers to make type that draws desired glyph designs by depiction onto incorrect public characters or onto incorrect private characters.
It is not possible in system software to stop user access to the Private Use Area because the Private Use Area is legitimate for innovative ideographs in Japanese (itaiji) and Chinese. The marketing manager for Fontlab has advised in public posts that it is admissable to make CMAP Character Maps with Private Use Area drawing as a way to work around the application-dependent drawing model of OpenType. John Hudson has posted since 2000 when he prepared a discussion of the Windows glyph model for Microsoft that drawing desired glyph designs by incorrect private characters in Adobe OpenType is the replacement for drawing desired glyph designs by incorrect public characters in Adobe Type 1.
1989-1997, Apple failed to provide a platform that would produce parity between the small developer and the big developer by providing the small developer with free internationalisation models and free graphics libraries including a free digital document model. 1997-2007, Adobe and Microsoft provided a platform for the static software suites wherein which the software suite owns the internationalisation models, the graphics libraries and the digital document model which, as John Jenkins notes in a paper, is the model for OpenType.
Adobe (and Linotype/Heidelberg) has in the process of undermining first Apple's implementation and then Microsoft's implementation made and marketed type that destroys the source character string on a scale that is almost incomprehensible. Because Adobe depends on recovering source character strings from glyph names and does not preserve the source character string and the glyph run, public perception of the performance of Adobe PDF is not necessarily affected by the fact that Adobe PDF is in fact a poor model even for professional typography in the simple and linear Latin script.
The model is the same: Separate character processing from glyph processing for the sake of portability and repurposing. The implementation is different: Make the font file a client of the application or make the application a client of the font file. Which implementation one wants depends on which software ecosystem one wants: Decentralised internationalisation including localisation in the hands of independent developers who are in a position to provide what their markets desire or centralised internationalisation including localisation in the hands of Anglo-American corporations.
You will not get a high ratio of academic anthropologists to agree to the centralised model.
/hh