Return to BRACKETS_NOTE CVS log

Up to [Research Unix] / researchv10no / cmd / post.src / devopost / charlib

Annotation of researchv10no/cmd/post.src/devopost/charlib/BRACKETS_NOTE, revision 1.1.1.1

1.1       root        1: 
                      2:  lc, rc, lf, and rf contain PostScript code that can be used to build the top
                      3:  and bottom bracket pieces used by eqn. The files are only used if the character
                      4:  code field in the S font file for lc, rc, lf, and rf is set to 1. A code larger
                      5:  than 32 means a character from Adobe's Symbol font will be used. Think the real
                      6:  solution is to change eqn so large brackets and braces are built differently.
                      7: 
                      8:  There were some serious collisions with eqn's bracket building algorithm and
                      9:  Adobe's Symbol font. eqn extends all the pieces with the \(bv character, while
                     10:  the bracket and brace pieces available in Adobe's Symbol are all quite different
                     11:  and are designed to work with their own extenders. The reference points are
                     12:  different, but worse still the thickness of brackets and braces don't match.
                     13:  Anyway using a single extender (the way eqn does) can't ever work with the
                     14:  bracket and brace characters available in Adobe's Symbol font.
                     15: 
                     16:  The lc, rc, lf, and rf files are a very complicated attempt to get around the
                     17:  problem. Each builds the troff character by using the \(bv character from the
                     18:  Symbol font and then draws a small horizontal line at either the top or bottom
                     19:  of the \(bv. Using \(bv for the vertical part guarantees things will stack
                     20:  properly, but getting to the precise top or bottom of the \(bv (down to the
                     21:  pixel level on all devices and in all sizes) proved to be very difficult. In
                     22:  fact you would think that determining the bounding box of \(bv would be enough
                     23:  to let you draw a good bracket piece that matched up nicely with the extender.
                     24:  Not quite, at least I didn't find that it was possible to do a good job drawing
                     25:  the pieces from the \(bv bounding box. Think roundoff errors introduced by the
                     26:  CTM caused the trouble, although I expect there's more to it.
                     27:  
                     28:  Clipping a rectangular region 2 pixels smaller in height than the bounding box
                     29:  of the \(bv character, and using the corners of that box to locate the top and
                     30:  bottom of the bv for the horizontal extender solved the problems I originally
                     31:  had with the precise placement of the horizontal rule. Anyway that's what the
                     32:  clipping and idtransform are for. The initgraphics stuff is an attempt to fit
                     33:  a tight bounding box around the \(bv character independent of the rotation of
                     34:  our coordinate system. pathbbox only returns what we want if the coordinate
                     35:  system has been rotated by a multiple of 90 degrees.
                     36:  

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.