hatcher@INGRES.BERKELEY.EDU.UUCP (04/14/87)
By now there are thousands upon thousands of digitized images, hand drawn images, icons, and fonts available on BBS's, on shareware/freeware diskettes, and sometimes posted to Usenet. The problem is that there are so very many (often renamed in different places) that it's hard to tell what's going on. Did you ever go through a whole disk of images, looking at each with showilbm looking for one in particular that you won't know 'till you see it? Did you ever see a BBS (like Amic here in Northern California) with so many *hundreds* of pictures that it was infeasible to download them all? Wouldn't it be nice if you could download something that would give you some idea of what a bunch of them were like all at once? Some people who create fonts will include with the fonts an image that shows what the fonts look like; this is a very nice touch, and very convenient. Along these same lines (as long as I'm on my soapbox), any program that allows you to pick one of a number of fonts should ideally show the font itself in the menu. Seeing is believing, but you may not remember what font is represented by the names "emerald, usa, terminal, dotty, phoenix, klaxon" etc. So I suggest the following: to any collection of images or fonts, always add an index image which shows all of the collection on a screen, by downsizing the images. It would be really handy to be able to see, say, a four by four array of shrunk versions of the rest of the images, and you'd get the basic idea of what's in them. There are a number of easy ways to shrink images. The most widely available way is probably using Dpaint II (grab picture as a brush, and do shift-resize), but with other tools there are other ways. Eventually it'd be nice to have a program dedicated to producing such a pictorial index, but meanwhile we can do it by hand. Doug Merritt ucbvax!ingres!hatcher
spencer@eris.UUCP (04/16/87)
In article <8704140657.AA14434@ingres.Berkeley.EDU> hatcher@INGRES.BERKELEY.EDU (Doug Merritt) writes: >Along these same lines (as long as I'm on my soapbox), any program that allows >you to pick one of a number of fonts should ideally show the font itself in >the menu. Seeing is believing, but you may not remember what font is >represented by the names "emerald, usa, terminal, dotty, phoenix, klaxon" etc. > Doug Merritt ucbvax!ingres!hatcher I looked that this idea and liked it at first. Many menus have the option of bold in "bold", and the like for underline and italic. But if you display every font the system can put in your document you have to *load* every font into ram, even more important, into Chip ram. It would be better to leave fonts on disk unless really needed. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 I N F I N I T Y BBS: (415)283-5469 Now working for |||||||||||::::... . . BUD-LINX But in no way |||||||||||||||::::.. .. . Officially representing ||||||||||||:::::... .. ....ucbvax!mica!spencer s o f t w a r e spencer@mica.berkeley.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
hatcher@INGRES.BERKELEY.EDU.UUCP (04/19/87)
In article <3200@jade.BERKELEY.EDU> spencer@eris.BERKELEY.EDU (Randy Spencer) writes: In article <8704140657.AA14434@ingres.Berkeley.EDU> hatcher@INGRES.BERKELEY.EDU (Doug Merritt) writes: >>Along these same lines (as long as I'm on my soapbox), any program that allows >>you to pick one of a number of fonts should ideally show the font itself in >I looked that this idea and liked it at first. Many menus have the option >of bold in "bold", and the like for underline and italic. But if you display >every font the system can put in your document you have to *load* every font Yes, that is a problem. But not insoluble. Certainly it's not a tough enough problem to make my suggestion infeasible. Here are three possible solutions, along with comments on them: A-Have a menu command to tell it to go look at all the fonts and load a single example of each for the font menu. Problem: slow. Also inconvenient. B-Have the program give examples of the fonts that it expects to see, and then use solution (A) for any "nonstandard" fonts. Problem: inflexible...one might totally replace all "standard" fonts, or delete some. And still not as convenient as it should be. C-Run a "fontpicture" program on your fonts directory to create a single file with an example of each font. This file would then be used in the program's menu. Problems: this gets annoying if you for some reason change the contents of fonts/ often. It also leaves undefined the solution to the problem of non-CLI users coping with this. In fact, ideally this "fontpicture" process should be automated somehow so you don't have to screw with it. Solution: the word processor/layout program could compare mod times of fonts/ and the font.picture files and update it if necessary. Any of the three solutions would be better than nothing, and I think (C) is all around viable. I'm sure there are other potential solutions, too. This is a case where I think it's clear that you shouldn't give up what you want simply because there are a few implementation difficulties. The Amiga could be *so* much more impressive than it is now with some carefully done software. But getting from here to there will take both creativity and determination. The real easy stuff has mostly been done already. Doug Merritt, ucbvax!ingres!hatcher Lord, God, King Unix Hacker, unisoft!certes!doug Slayer of SIGSEGVs, hoptoad!mentat!doug Defender of Device Drivers, Chamberlin of the Royal Socketeers. [ Rogue Monster has threatened great bodily harm to me if I do not use the above signature he created for me ("a little subdued, but distinctive.") Send all flames to decwrl!mips!roger ]