On Wed, Oct 20, 1999 at 10:37:39AM -0400, Owen Taylor wrote: > OK, this almost certainly was what the person was describing. > He made it sound like you were autogenerating the fonts.* files, > out of some other format, but it was reasonably close to the > above. Yeah, no sense reinventing the wheel. I just stick the files in their native format in a different place and do some very mild shell manipulations to create composites where the servers actually look. > As a side note, the way that Red Hat handles the above problem > is that we install each set of fonts in a separate directory, > always runs a font server, and then have a 'chkfontpath' script > that takes care of appropriately modifying the font server's font > path and notifying the font server to reread its configuration > files. So, another case of pointless inter-distribution > incompatibility, though this one should be invisible to apps. Yes, but I'll note that my solution works with any font server or X server without demanding manipulation of their configuration files by each font package (assuming the servers are set up to read a standard set of font paths in the first place). From what you describe it sounds like the Debian way is better. <insert mindless distribution cheerleading here> Anyway, to your points: > - How does a user specify a font without becoming an expert > in X. This is already an issue normally, but becomes a big > issue when i18n comes into the picture. Because if you > are rendering internationalized text, 'Helvectica' doesn't > map to a single XLFD but to a set of XLFDs. (fontset) Well, I don't have a GUI form designer handy, but I imagine an X client could have a font selection dialog box that looks much like ones in Windows, except it has more fields that can be changed. There are something like 13 components to an LFD name. The parts that are too daunting or too seldom-used by the casual newcomer could always be tucked away in a separate dialog accessed by an "Advanced..." button, or the font dialog could be a tab book, etc. etc. When all else fails there is always the alias mechanism. When there are no collisions this works fine. I'm not sure it makes a lot of sense to tackle the issue of preventing alias collisions, or of providing "simple" font names that are easily typed on a command line -- not if we're shooting for an "easy for the end user" goal. They won't be specifying font names on the command line anyway. The more esoteric parts of the LFD can be tucked away in a GUI. An application can always construct the full LFD internally and I don't see any reason for the whole big ugly string to ever be presented to the user unless he wants to see it. At first glance, I can see a casual user wanting to manipulate foundry, family, weight, slant, point size, registry, and encoding. The latter two probably aren't important for North Americans but they are for the rest of the world. Other stuff like spacing and average width are often fixed anyway for a particular font (especially BDF ones), or are only used by people doing stuff more on the typesetting end of things, rather than word processing. For the real diehard typesetting folks X fonts are probably insufficient anyway. They want DPS. I guess what I am asking is, what need do you want to fulfill with this initiative? > > What kind of text database were you thinking of? If it's just a list of > > LFD names then the fonts will be served through a font server (be it > > internal or external to the X server) and you can either use programs like > > xlsfonts or Xlib calls to accomplish the same thing. > > Certainly. (Though the performance of xlsfonts equivalents is actually > a fairly big bottleneck in a lot of cases.) This I was unaware of. Perhaps they are not written efficiently? Or is the problem in the underlying Xlib() calls? If the latter, it may be time to talk to XFree86. If there are really performance issues, it might make sense to author an extension to XFree86 whereby a binary database of available fonts can be generated within the X server or font server and exported to client apps that want to keep track of it themselves. The X font database is static most of the time, so it makes sense to optimize for access, not record updates. LDAP springs to mind for no good reason so please shoot me now. :) Implementation details aside, if performance of shoveling lists of font NAMES around is a big deal, I'm sure it is an addressible issue. XFree86 is currently hammering on ideas about shipping around the fonts themselves, especially iso10646 varieties which may have tens of thousands of glyphs. They're active on the subject of fonts right now so it might be a good time to talk to them. > > On the other hand, there has been some discussion in Debian of late about > > the need for a standardized repository for multipurpose fonts (such as > > TrueType, which have practical application beyond the X server and in fact > > aren't supported by the stock XFree86 distribution yet). But I was going > > to wait and see if XFree86 themselves had any insight on this. If it's > > used by X, though, any font has a LFD registry name. It could be a useful > > project to come up with a way of generating less cumbersome font names for > > human consumption, but this should be done in a logical way, standardized > > across distributions, and have the input of some font gurus from XFree86 > > (probably some Metafont and PostScript hackers as well). > > In essence, these are the two problems I've been thinking about. Upon further reflection I'm not sure the demand for font name simplification is really there. Like I said above, a GUI makes it easy to hide hairy details from the user. As far as the repository goes, well, that's really just a filesystem layout kind of thing and it shouldn't take too much brainpower to come up with something reasonable. > Once I figure out a bit more about how I think handling > user-manageable names for fonts/fontsets should be managed, > I'll write up a proposal and send it around to the relevant > fora. I'd love to hear whatever you come up with and I'd be glad to work with you on such a thing and/or offer commentary. -- G. Branden Robinson | I am sorry, but what you have mistaken Debian GNU/Linux | for malicious intent is nothing more branden@ecn.purdue.edu | than sheer incompetence! cartoon.ecn.purdue.edu/~branden/ | -- J. L. Rizzo II
Attachment:
pgpcx0BOocDz2.pgp
Description: PGP signature