robert@gitpyr.gatech.EDU (Robert Viduya) (12/21/86)
>amamaral@elrond.UUCP (Alan Amaral) (amamaral@elrond.UUCP, <507@elrond.UUCP>): > In article <6901@decwrl.DEC.COM>, rost@decwrl.DEC.COM (Randi Rost) writes: > > I have created a library of C routines for reading/writing/creating > > Object File Format files... > > I'm not sure about distributing the sources on the network, but if > > there is enough demand, perhaps I can twist some upper-management > > arms to let me do such a thing. > > Please do post the sources if humanly possible. I have been looking for > some reasonable file format that I can use where I stand a snowballs chance > in hell of exchanging info with others easily. There are other file formats floating around that will handle porting graphics from machine to machine. The one I'm most familier with is Commodore's IFF (Interchange File Format) which allows to store not only graphics but other info as well such as sound or even just plain text. The Amiga uses IFF and full documentation as well as a few sample C programs for reading and writing IFF files can be found in the ROM Kernal Reference Manual for the machine. Putting my obvious bias aside (I own an Amiga) and looking at things objectively, I would say that the best thing to go with is the new GKS Metafile format that ANSI and ISO are supposedly working on. I've not been able to find this particular standard in the GaTech library (I'm not sure it's even an accepted standard yet), so I can't really say much about it. However, it does have a few things going for it: o It's a standard developed and supported by an organization devoted to standards. These tend to not change too much as time goes on and when they do, it's almost always guaranteed to be compatible and always has a good reason for the change. o Standards developed by companies tend to have a more difficult time being accepted by other companies, especially those in direct competition to the developing company. Instead, those other companies tend to come up with their own standards (incompatible, of course) leading to a plethora of incompatible standards. As an example of this, look at the various sets of control sequences used for terminal control. It's only been recently that ANSI's X3.64 standard has garnered wide-spread acceptance. Of course, there are drawbacks with things developed by a committee. However, I think those drawbacks are more acceptable than the total anarchy that would ensue if the standard organization didn't exist. robert -- Robert Viduya robert@pyr.ocs.gatech.edu Office of Computing Services (404) 894-4660 Georgia Institute of Technology Atlanta, Georgia 30332
andrea@hp-sdd.HP.COM (Andrea K. Frankel) (12/25/86)
In article <2824@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes: >GKS Metafile format that ANSI and ISO are supposedly working on. >I've not been able to find this particular standard in the GaTech >library (I'm not sure it's even an accepted standard yet) I think you are referring to the Computer Graphics Metafile (CGM). This IS in fact an accepted standard! As of 8/27/86, it is American National Standard X3.122-1986, available from ANSI 1430 Broadway New York, NY 10018 The same document is also an international standard, IS 8632 (accepted just this fall, and still being typeset I believe). Both standards have four parts: Part 1 defines the functionality, Part 2 is a Character Encoding (cryptic and compact, good for I/O transmission), Part 3 is a Binary Encoding (good for file storage), and Part 4 is a Clear Text Encoding (good if you have to read or edit the thing). The CGM was developed to be used by GKS and others for archiving pictures. In addition to vector graphics functions, it also includes a rudimentary raster format (CELL ARRAY), and "hooks" for putting in implementation-dependent information in the file (APPLICATION DATA, GENERALIZED DRAWING PRIMITIVE, and ESCAPE). The CGM is the basis for the CGI (interface to graphics "Virtual Devices") and for an Extended CGM which will provide GKS audit trail capability and the CGI's extended raster functionality (among other things). By all means, if you want to implement something that has some chance of being portable between different vendors, and an expected lifetime longer than the current rev of <your favorite o/s here>, check out the CGM! Andrea Frankel, Hewlett-Packard (San Diego Division) (619) 592-4664 "...like a song that's born to soar the sky..." ______________________________________________________________________________ UUCP : {hplabs|hp-pcd|hpfcla|hpda|noscvax|gould9|sdcsvax}!hp-sdd!andrea UUCP : {cbosgd|allegra|decvax|gatech|sun|tektronix}!hplabs!hp-sdd!andrea ARPA : hp-sdd!andrea@nosc.arpa CSNET : hp-sdd!andrea@hplabs.csnet USnail: 16399 W. Bernardo Drive, San Diego CA 92127-1899 USA
bferrer@Bonnie.ICS.UCI.EDU (02/07/91)
Can somebody please send me on file formats for GIF and raw RGB files? thanks in advance bill
torgerse@udel.edu (Todd Torgersen) (02/07/91)
Does anyone out there know of a public domain device
driver for an HP 7221C pen plotter. In particular, I
would like to convert from HPGL to the device.
Sorry to bother the group with such a trivial item,
but I have called HP numerous times. On those rare occasions
when I actually get a HUMAN to talk to, he or she has refered
me to some other phone number which either does not answer or
refers me to ......
Thank you. Please respond directly by e-mail to (Todd Torgersen):
torgerse@mthcsc.wfu.edu (128.109.96.1)mcastle@mcs213f.cs.umr.edu (Mike Castle {Nexus}) (02/07/91)
In article <9102061257.aa28859@Bonnie.ics.uci.edu> bferrer@Bonnie.ICS.UCI.EDU writes: > > Can somebody please send me on file formats for GIF ^^^ These can be obtained (in a non-compressed form) from vmtecmex.cem.itesm.mx (132.254.1.4). It has files for both 87a and 89a formats. This is a VM/CMS IBM SYS/370 machine. When you login, do CD GIF or CD GIF-L (been a while, I forget which). > and raw RGB files? ^^^^^^^ 3 files, one for each color plane, ordered (generally) top-down, left-right. That is info for (1,1),(2,1),(3,1).....(MaxX,1),(1,2),(2,2)....(1,MaxY),(2,MaxY) (3,MaxY)....(MaxX,MaxY). No header information in the file, just pure 24-bit color information. >thanks in advance > >bill -- Mike Castle (Nexus) S087891@UMRVMA.UMR.EDU (preferred) | RN ate my mcastle@mcs213k.cs.umr.edu (unix mail-YEACH!)| .newsrc! Life is like a clock: You can work constantly, and be right | I am not all the time, or not work at all, and be right twice a day. | happy :-<