jma:jma@jma.UUCP (jma:jma) (02/09/89)
My company, a developer of X Windows based applications for the
Oil and Gas industry, is searching for PD source for CGM. Displayed
information is to be read back and stored in the CGM metafile format for
export to applications that will edit the image file. Also, the file will
be exported to applications tha provide plot services.
Please e-mail information to uunet!jma!jma.
If you know of any other solutions that provide plot services for the X Windows environment, please let me know.
{ The knowledge of a few can compensate for the ignorance of the many}
--
John Amason e-mail: uunet!jma!jma
Landmark Graphics Corp. phone: (713) 579-4749
333 Cypress Run, Suite 100
Houston, Texas 77094turner@daisy.UUCP (D'arc Angel) (02/10/89)
We are doing exactly the same thing here looking at CGM as a plot
metafile etc. vehicle and wrestling with the problems of hardcopy
in X. Is there a mail list out there for these issues? If not,
anyone interested in starting one? Here are some of the thoughts
that we have come up, I would welcome any comments.
1. make a screen number (e.g. unix:99) be the hardcopy device
(actually a class of display numbers, 901 is calcomp etc.).
Problem: how do you pass device dependant flags; handle the
differences in resolution; accomodate the high level abilities
of the device (everything is spans at the server level).
Advantages: it requires a minimum change for clients (-display
flag in many cases); it handles 'remote' plotting.
2. set a switch in Xlib and save the wire protocal as a metafile
format for later replay thru some kind of a metafile interpreter.
Problem: flags and resolution are not that much of a problem
since the issues could be resolved in the interpreter.
Advantages: it's a real metafile and can be passed around,
saved for later plotting etc.; adding new devices is easier.
3. write a whole new set of Xlib routines to handle hardcopy
Problem: clients need to be changed; it'll be a while before
the protocal etc are implemented.
Advantages: it'll be official.
and on and on. I make no claim as to the feasibility or value of
these solutions and the list is FAR from exhaustive. It is meant to
start a discussion. If there is already a mailing list for this....
never mind.
As always flames > /dev/null
--
Don't take life too seriously, it ain't nohow permanent - Pogo
...{decwrl|ucbvax}!imagen!atari!daisy!turner (James M. Turner)Kimbrough@dsg.csc.ti.COM (Kerry Kimbrough) (02/10/89)
> Is there a mail list out there for these issues? If not, > anyone interested in starting one? Let's just use xpert. > 1. make a screen number (e.g. unix:99) be the hardcopy device > 2. set a switch in Xlib and save the wire protocal as a metafile > 3. write a whole new set of Xlib routines to handle hardcopy Another possibility is to extend Xlib to handle a metafile as a new kind of drawable. (Perhaps this is what you meant by #3?) This would capture the part of the protocol that is relevant (output requests, graphic context creation). This is better than #1 and #2 because a metafile is much more analogous to a drawable than it is to a screen or a display. This *would* require source changes to existing clients, but they would be small. A standard metafile extension to Xlib might want to produce a standard metafile format (i.e. CGM). However, it might be better to produce a vanilla data encoding of the metafile output requests which could then be translated into CGM or any number of other metafile formats.