Text Selection

1. The ColorScheme, ScaledColorScheme, CharacterView, and RuleView classes are designed to handle selection moderately well. Antialiased characters are generated by interpolating between foreground and background colors; for selected text, the foreground is the usual text foreground and the background is changed.

2. A CharacterView which is told to draw using the selected text colors will draw all pixels touched by the image of the character, but will not touch background pixels. Some mechanism is needed for painting part of the background with the selection color, and repainting it with the background color once the selection goes away.

   The logical place for this is in the ContainerView class. It will be hard to do right, since we don't usually paint the background at all.

   Possibly, every run of sub-views which share a common baseline (y-coordinate) in the original Block structure should be hilighted within a single bounding rectangle. This will produce the desired effect of looking like a word processor selecting text, instead of hilighting the bounding box of each character separately.

3. Images won't hilight.

   It would be fairly easy to make black and white postscript images hilight. This could be done using some part of the PBMPlus package, mapping white to the selection color and black to black. The result would be a second set of GIF images.

   This would complicate the ImageBlock and ImageView classes slightly.

4. Doing anything with the selected text is very very difficult.

   Font files presumably have a byte somewhere which says which font encoding they use. If not, then we are in trouble.

   Using the encoding, individual selected characters can be mapped back to text. Symbols can be mapped back to the TeX commands which generate them, as well. There will be some trouble with large delimiters. There is probably a way to identify LaTeX pictures and ignore them.

   Math can probably be differentiated from normal text by detecting the use of a math italic font. Some care will be needed to deal with the output of constructs such as a = b \quad \hbox{mod} 2, where mod appears in the normal text font.

   TeX will store characters in the dvi file in an order that makes sense. So { a \over b } will appear in a dvi file as a character a, followed by a rule, followed by a character b. Thus it should be possible to extract a fairly good representation of the text as TeX source. Getting mathematical intent is, of course, much harder.