1#ident "%Z%%M% %I% %E% SMI" /* SVr4.0 1.1 */ 2# 3# CDDL HEADER START 4# 5# The contents of this file are subject to the terms of the 6# Common Development and Distribution License, Version 1.0 only 7# (the "License"). You may not use this file except in compliance 8# with the License. 9# 10# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE 11# or http://www.opensolaris.org/os/licensing. 12# See the License for the specific language governing permissions 13# and limitations under the License. 14# 15# When distributing Covered Code, include this CDDL HEADER in each 16# file and include the License file at usr/src/OPENSOLARIS.LICENSE. 17# If applicable, add the following below this CDDL HEADER, with the 18# fields enclosed by brackets "[]" replaced with your own identifying 19# information: Portions Copyright [yyyy] [name of copyright owner] 20# 21# CDDL HEADER END 22# 23 24 lc, rc, lf, and rf contain PostScript code that can be used to build the top 25 and bottom bracket pieces used by eqn. The files are only used if the character 26 code field in the S font file for lc, rc, lf, and rf is set to 1. A code larger 27 than 32 means a character from Adobe's Symbol font will be used. Think the real 28 solution is to change eqn so large brackets and braces are built differently. 29 30 There were some serious collisions with eqn's bracket building algorithm and 31 Adobe's Symbol font. eqn extends all the pieces with the \(bv character, while 32 the bracket and brace pieces available in Adobe's Symbol are all quite different 33 and are designed to work with their own extenders. The reference points are 34 different, but worse still the thickness of brackets and braces don't match. 35 Anyway using a single extender (the way eqn does) can't ever work with the 36 bracket and brace characters available in Adobe's Symbol font. 37 38 The lc, rc, lf, and rf files are a very complicated attempt to get around the 39 problem. Each builds the troff character by using the \(bv character from the 40 Symbol font and then draws a small horizontal line at either the top or bottom 41 of the \(bv. Using \(bv for the vertical part guarantees things will stack 42 properly, but getting to the precise top or bottom of the \(bv (down to the 43 pixel level on all devices and in all sizes) proved to be very difficult. In 44 fact you would think that determining the bounding box of \(bv would be enough 45 to let you draw a good bracket piece that matched up nicely with the extender. 46 Not quite, at least I didn't find that it was possible to do a good job drawing 47 the pieces from the \(bv bounding box. Think roundoff errors introduced by the 48 CTM caused the trouble, although I expect there's more to it. 49 50 Clipping a rectangular region 2 pixels smaller in height than the bounding box 51 of the \(bv character, and using the corners of that box to locate the top and 52 bottom of the bv for the horizontal extender solved the problems I originally 53 had with the precise placement of the horizontal rule. Anyway that's what the 54 clipping and idtransform are for. The initgraphics stuff is an attempt to fit 55 a tight bounding box around the \(bv character independent of the rotation of 56 our coordinate system. pathbbox only returns what we want if the coordinate 57 system has been rotated by a multiple of 90 degrees. 58 59