Return to BRACKETS_NOTE CVS log

Up to [Research Unix] / researchv10no / cmd / postscript / devopost / charlib

Annotation of researchv10no/cmd/postscript/devopost/charlib/BRACKETS_NOTE, revision 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.