Generic Text RFC
From X-Plane Wiki
This page contains a Request For Comment (RFC). RFCs are posted to facilitate discussion of possible features; an RFC does not mean that the feature will be implemented, or that the feature will be implemented exactly as specified in the RFC! Do not assume an RFC will be implemented; do not create and post content that uses extensions proposed in the RFC. Wait for the final specification before creating airplanes and models!
This RFC proposes extensions to text handling for generic instruments.
Mutli-format font support
- The generic-text instrument would be able to take a font bitmap with more than one line.
- Each line could be used for a different font, different size, or different color text.
- Control codes (ASCII 1-31) in a string DataRef (char-array type DataRef) would be interpreted as style changes. A line in the text would be selected by running the control code through the instrument's key frame table.
OPEN ISSUE: where would line size and line formatting information be stored?
- These could be in the instrument.
- They could also be in a text file co-named with the PNG. This is a bit atypical of the generic instrument system, but since the PNG is a shared resource, it makes development simpler to have the metrics be shared too.
Text-font-based Numeric
- A new gen_numeric instrument would use the same font formatting rules as the gen_text, for shared fonts, but use numeric datarefs.
- The key frame table would do numeric conversion.
- Numeric formatting would be by property (similar to the LED and rolling instruments).
- Color selection would be done via range bounds, similar to the pie instrument (e.g. different stripes could be selected based on five zones of dataref values).
OPEN ISSUE: should it simply be legal to allow the gen_text instrument use numeric datarefs? Pro: reduces number of instruments Con: key frame table acts differently, properties needed are very different too!