DEG41560@UA1VM.BITNET (Rob Smith) (02/22/89)
Hi,
I would like to get a BDF gothic and/or script font. Can anyone out there
tell me if one of the fonts included with X11r3 distribution (contrib or
otherwise) fits either bill? If so, I have another question:
My bdf2gf convertor works fine on the oldx10 and oldx11 fonts,
but fails on the other contributed X fonts. Any fixes?
If not, does anyone no where a gothic or script BDF file is available?
Or where a similar file is available in GF format?
Thanks,
Robharkcom@potato.pa.Yokogawa.Co.jp (Alton Harkcom) (11/11/90)
In article <HARKCOM.90Oct27144414@potato.pa.Yokogawa.Co.jp> harkcom@potato.pa.Yokogawa.Co.jp (Alton Harkcom) writes: =} I recently tried to make a rather small 2 byte font which used the 7x14 =}font from X11R4 and my additions up in 1nnnnnnn nnnnnnnn. After running it =}through bdftosnf, I got back an extremely large font of 1.1 MEGS! And =}what's worse, the X server jumps up over 2 MEGS when I load it. =} =} Are all of the undefined characters between 00000000 nnnnnnnn and =}1nnnnnnn nnnnnnnn taking up memory? Well, I got -0- in the way of replies to this one. But I realize that my original post was to the wrong newsgroup... Sorry about that. Anyway, I think I am correct in my original assumption that the fonts are handled this way due to the method of storage and retireval. The method is simple, and fast (though it can waste resources. But why does the server suck up more than twice the font's size to hold it when smaller fonts barely take up their size in memory? HELP!!!!! -- -- $@2#2OEE5!3t<02q<R(J PA$@#15;#22](J TEL 0422-52-5748 FAX 0422-55-1728 E-mail harkcom@pa.yokogawa.co.jp
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (11/11/90)
Are all of the undefined characters between 00000000 nnnnnnnn and
1nnnnnnn nnnnnnnn taking up memory?
The font gets compiled with a matrix encoding (see the X protocol doc for
a description). bdftosnf computes the "minimum" bounding matrix encoding.
The font file contains (all-zero) metric information for each valid column
in each valid row between the first and the last rows. There are 16 bytes
of metric information for every such glyph. If the font gets compiled with
ink metrics in addition to bitmap metrics, then there will be two sets of
metrics in the file, making it twice as large.
But why does the server suck up more than twice the font's size to hold it
when smaller fonts barely take up their size in memory?
Depends to some extent on how your system's memory allocator works. But in
addition, if your client queries for the font metrics (e.g. XLoadQueryFont),
then the server will temporarily allocate a large buffer to copy metric
information into, and this buffer will be several hundred K.davis@b11.ingr.com (Chris Davis) (12/29/90)
Why do some variable width fonts have negative lbearings? I could not find any documentation that mentions the reasoning behind this. If you look at the font "-adobe-courier-bold-r-normal--18-180-75-75-m-110-*", the 'A' and the 'm' have negative lbearings. Is there a reason for this? We are writing a terminal program and we would like to use this font, but those two cases of negative lbearings are creating several special cases to have to be dealt with. -- chris davis uunet!davis@ingr.com
mouse@LARRY.MCRCIM.MCGILL.EDU (12/30/90)
> Why do some variable width fonts have negative lbearings? I could > not find any documentation that mentions the reasoning behind this. > If you look at the font > "-adobe-courier-bold-r-normal--18-180-75-75-m-110-*", > the 'A' and the 'm' have negative lbearings. Is there a reason for > this? That's not a variable-width font, or at least shouldn't be; it claims to be monospaced (the -m-). (It doesn't claim -c-, for charactercell; that would be wrong for a font with some negative lbearings.) A negative lbearing indicates that some of the character's ink lies to the left of the character's reference point. That's all. In the case of the Courier A, I would guess that the serif on the left slanting vertical sticks out far enough to fall to the left of the refpt. As an example of a reasonable use for a (large) negative lbearing.... Imagine, if you will, an A with a swash tail on the left-hand stroke. Such a tail will extend far to the left and below the reference point; thus, the depth will be >>0 and the lbearing will be <<0....[%] [%] << and >> in the math meaning of "much less than" and "much greater than", not the C sense of left and right shift. (I know this seems obvious, but I also know how little difference that makes on the net.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu