There are numerous examples of the need for text displays ranging from notice boards to juke boxes, HUDs and more. There are a number of ingenious solutions but they usually waste a lot of prims, use a lot of textures and, most significantly, are painfully slow to update. Perhaps the following is simple enough to be something we might see in the forseeable future, compared to some of the more ambitious proposals:

• Define a new texture constant: TEXTURE_TEXT
• Modify the client to render text set with llSetText on the side of the prim, instead of hovering above it, for prims with one or more sides set to TEXTURE_TEXT.

For example: llSetTexture(TEXTURE_TEXT, 1); llSetText("The text to render", <1, 0, 0>, 1.0); Would render "The text to render" in red on side #1 of the prim. To keep it simple, the font height could simply be scaled to the prim hight and the width kept proportional, meaning that wide rectangular prims would be most suitable. A further simplification to the implementation would be to require an alpha of zero in llSetText to prevent the hovering text, and simply ignore the alpha when rendering the side of the prim. This requires no extra prim properties, no modification to the server and no extensions (other than the new constant) to LSL. If it is not prohibitive, control of alignment through constants like TEXTURE_TEXT_LEFT and TEXTURE_TEXT_CENTER would certainly be valuable. Alternatively a choice of fonts like TEXTURE_TEXT_PROPORTIONAL and TEXTURE_TEXT_FIXEDWIDTH would allow padding with spaces to achieve alignment. Obviously this is not a comprehensive solution. Text on the side of a textured prim would not be possible. Prims would have to be sized to obtain the desired text size. Bold, underline and other styles would not be available. That said, it would be a whole lot more than we have today and is certain to get a lot of use, probably even after a more sophisticated solution like HTML on a prim becomes available.