
 lc, rc, lf, and rf contain PostScript code that can be used to build the top
 and bottom bracket pieces used by eqn. The files are only used if the character
 code field in the S font file for lc, rc, lf, and rf is set to 1. A code larger
 than 32 means a character from Adobe's Symbol font will be used. Think the real
 solution is to change eqn so large brackets and braces are built differently.

 There were some serious collisions with eqn's bracket building algorithm and
 Adobe's Symbol font. eqn extends all the pieces with the \(bv character, while
 the bracket and brace pieces available in Adobe's Symbol are all quite different
 and are designed to work with their own extenders. The reference points are
 different, but worse still the thickness of brackets and braces don't match.
 Anyway using a single extender (the way eqn does) can't ever work with the
 bracket and brace characters available in Adobe's Symbol font.

 The lc, rc, lf, and rf files are a very complicated attempt to get around the
 problem. Each builds the troff character by using the \(bv character from the
 Symbol font and then draws a small horizontal line at either the top or bottom
 of the \(bv. Using \(bv for the vertical part guarantees things will stack
 properly, but getting to the precise top or bottom of the \(bv (down to the
 pixel level on all devices and in all sizes) proved to be very difficult. In
 fact you would think that determining the bounding box of \(bv would be enough
 to let you draw a good bracket piece that matched up nicely with the extender.
 Not quite, at least I didn't find that it was possible to do a good job drawing
 the pieces from the \(bv bounding box. Think roundoff errors introduced by the
 CTM caused the trouble, although I expect there's more to it.
 
 Clipping a rectangular region 2 pixels smaller in height than the bounding box
 of the \(bv character, and using the corners of that box to locate the top and
 bottom of the bv for the horizontal extender solved the problems I originally
 had with the precise placement of the horizontal rule. Anyway that's what the
 clipping and idtransform are for. The initgraphics stuff is an attempt to fit
 a tight bounding box around the \(bv character independent of the rotation of
 our coordinate system. pathbbox only returns what we want if the coordinate
 system has been rotated by a multiple of 90 degrees.
 
