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