[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] Re: DESC problem
Re: [Groff] Re: DESC problem
Fri, 01 Sep 2000 14:52:03 +0100
> Ted and I both have a problem we can't solve. Please help.
I'll have a guess.
> > If I look into a the `font' command DESC file, I usually see this:
> > fonts 6 0 0 0 0 0 S
> > or this:
> > fonts 14 R I B BI 0 0 0 0 0 MI S EX CW CWI
> > Now please tell me why there are the zeroes in it... Is there any
> > reason except backwards compatibility with old UNIX troff versions to
> > have this? To which shall we compatible? Is this documented?
Some bits of info.
groff knows not to place the symbol font in the font_name_table
where a zero has been specified in the DESC file.
The size of the font_name_table is initially set to the second word
of the fonts line.
Kernighan's cstr54 says for .fp.
.fp N F L R,I,B,...S
Font position. This is a statement that a font named F is
associated with position N. It is a fatal error if F is
not known. For fonts with names longer than two
characters, L refers to the long name, and F becomes a
synonym. There is general a limit of about 10 mounted
groff grows font_name_table if a .fp requests a position N that is
larger than the tables current size.
In troff, you had to mount a font before using it, e.g. `.fp 3 H'.
>From this, I'd suggest that troff fixes its equivalent of
font_name_table at the size given in DESC; it never expands it. The
symbol font is implicitly mounted in troff but you often don't
explicitly need to use it, special characters switch to it as described
in cstr54. The user expects R,I,B to be initially mounted in positions
1,2,3 and that they should mount their own fonts at positions 4,5,...
thus the symbol font needs to be out the way so it's traditionally
placed up the end of the font table; troff had to have a font mounted
to use it. That Kernighan places it at the end of the default setting
above again suggests this, and groff skipping over the zeroes when
searching for a position for the symbol font shows those positions are
reserved for the user.
Since groff grows font_name_table on demand this isn't so important,
but the gaps should be left for old documents that use position 4, etc.
Searching groff's DESC files shows the first five slots don't contain S
for most devices; there are (newer?) exceptions. Also, the first
three are R,I,B as Kernighan says, with a BI in position four which
IIRC never used to exist.
devX100-12/DESC:fonts 6 0 0 0 0 0 S
devX100/DESC:fonts 6 0 0 0 0 0 S
devX75-12/DESC:fonts 6 0 0 0 0 0 S
devX75/DESC:fonts 6 0 0 0 0 0 S
devascii/DESC:fonts 4 R I B BI
devdvi/DESC:fonts 14 R I B BI 0 0 0 0 0 MI S EX CW CWI
devhtml/DESC:fonts 6 0 0 0 0 0 S
devhtml2/DESC:fonts 5 R I B BI S
devlatin1/DESC:fonts 4 R I B BI
devlbp/DESC:fonts 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
devlj4/DESC:fonts 6 0 0 0 0 0 S
devps/DESC:fonts 9 0 0 0 0 0 SS S ZD ZDR
devutf8/DESC:fonts 4 R I B BI
PS. Having just checked Plan 9's troff I can confirm that .fp is just
a simple assignment into an array which is fixed size at 100 elements,
so it seems the zeroes allow for troffies like me that do `.fp 3 H' and
for the other devices to work they should perhaps have some zeroes