Xref: utzoo comp.lang.postscript:5751 gnu.ghostscript.bug:226
Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!parcplace!aladdin!ghost
From: ghost@aladdin.com (L. Peter Deutsch)
Newsgroups: comp.lang.postscript,gnu.ghostscript.bug
Subject: FontBBox, again
Message-ID: <11.UUL1.3#5127@aladdin.com>
Date: 12 Aug 90 16:01:24 GMT
Organization: Aladdin Enterprises, Menlo Park, CA
Lines: 32

Sigh.  The examples in the Red Book all use *non*-executable arrays.
The one example in the Black Book (p. 11), and the one Adobe font
I've examined (the Cheq chessboard font), use *executable* arrays.

I don't see any way to resolve this problem.  Code that expects one
of the two formats will break when it encounters the other, unless it
uses the locution
	/FontBBox load
(if it wants an array), or
	/FontBBox load aload pop
(if it wants 4 numbers), instead of simply
	FontBBox

Since the only piece of code I've seen that expects FontBBox to be
executable used the locution
	[ FontBBox ]
one can imagine a hack that defines FontBBox as a procedure as
follows:
	currentfont /FontBBox get
	1 index mark eq { aload pop } if
But this is just a hack, and in any case I don't see how to get a
procedure definition of FontBBox to take precedence over the actual
FontBBox entry in the font, since the current font is typically the
top element on the dictionary stack.

I guess Ghostscript fonts, which use Adobe Type 1 format, will have
to match the Adobe convention and use an executable array for the
FontBBox.  Sigh.

L. Peter Deutsch		ghost@aladdin.com   --or--
Aladdin Enterprises		...{uunet,sun,decwrl!}parcplace!aladdin!ghost
P. O. box 60264, Palo Alto, CA 94306