jsh0447@DOMAIN_2.lerc.nasa.gov (Jeff Hojnicki) (05/30/90)
Howdy folks, Here at LeRC we are just venturing into writing some graphics software; simple stuff, i.e. line plots and etc. We are running AEGIS, SR 9.7.5 on a 4500. Here is the problem. We are trying to use the gm_$print_file call to create a PostScript file so we can get hardcopies of what we see on the screen. However, that doesn't seem to be working right. We can create a gm_$gmf file which creates a record format file, which we can print, but only draws a single rectangle. However, when we try to create a PostScript file, we get nothing. - No file, nothing. In another code, we were able to create a PostScipt file, but it again came out as record format, not uasc, which seemed a bit unusual. And we never could get it to print right. BTW, we are using "within GPR mode" if that matters. The questions are: Does the PostScript file option work? Should it really generate a rec format file? Would it be easier to bag this and create our own PostScript files separately? Any help / advice / experience / etc. would be very helpful. -- Jeff Hojnicki | jshoj@csd.lerc.nasa.gov | // // // // NASA/LeRC | jhojnicki@nasamail.nasa.gov | =====FREEDOM====== (216)-433-5393 | - - - - - - - - - - - - - - - - - -| // // () () // // "My opinions are my own, don't blame NASA for them!" | -- Jeff Hojnicki | jshoj@csd.lerc.nasa.gov | // // // // NASA/LeRC | jhojnicki@nasamail.nasa.gov | =====FREEDOM====== (216)-433-5393 | - - - - - - - - - - - - - - - - - -| // // () () // // "My opinions are my own, don't blame NASA for them!" |
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (05/30/90)
The Postscript files generated by GMR (both 2D and 3D) reference a number of
macros which are defined in the file /sys/gmr2d/macros.ps (on my SR10.2 system).
These macros are in the SR9.7 GMR manual in some obscure location which tells
you that they must be added as a prefix to your Postscript file. Why Apollo
didn't simply have GMR generate a file with the necessary header is a mystery.
I've been poking through my network as I've been reading my mail looking for
a SR9.7 version of the macro file, and I haven't found one. Apollo may not
have put one on the release tapes ... the SR10.2 file is included below for
the benefit of those SR9.7 users.
== Dave
============================================ cut here ===========================
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% procedure ANCHOR_TEXT
% when called, font, path.x, path.y, up.x, up.y, size
% and a string of text are on the stack
/anchor_text
{
% code for implementing stroke text could replace the show command
% use arguments on the stack to compute font scale and text direction
/Times-Roman findfont
setfont
show
clear
} def
% procedure BOX_TEXT
% when called, font, path.x, path.y, up.x, up.y
% and a string of text are on the stack
/box_text
{
% code for implementing stroke text could replace the show command
% use arguments on the stack to compute font scale and text direction
/Times-Roman findfont
setfont
show
clear
} def
% procedure COLOR
% when called, color id is on the stack
/color
% setting the rgb or hsb according to the color id could replace the next line
{ 0 eq { 1 setgray } { 0 setgray } ifelse
} def
% procedure PATTERN_FILL
% when called, a current path has been created and and a current color set.
/pattern_fill
{
% code to do a pattern fill could replace the next line.
eofill
} def
% procedure SET_FILL_BG_VAL
% when called, fill background value is on the stack
/set_fill_bg_val
{
% currently a no-op, just pops the value
pop
} def
% procedure SET_FILL_PATTERN
% when pattern (32 4-byte integers) is on the stack
/set_fill_pattern
{
% currently a no-op, just clears the stack
clear
} def
% procedure SET_TEXT_BG_VAL
% when called, text background value is on the stack
/set_text_bg_val
{
% currently a no-op, just pops the value
pop
} def
% procedure UDP
% when called, primitive id, number of points,
% number of arguments, point array and argument array
% are on the stack.
/udp
{
% currently a no-op, just clears the stack
clear
} def
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (05/30/90)
On a seperate note ... it has been over a year now since Apollo began promoting OSF as the wave of the future. So far HP/Apollo has declined to commit themselves to port *any* of the Apollo-specific libraries and utilities to OSF Unix. The most they will state is that they are studying the problem of which libraries are "absolutely essential". If you haven't already noticed, HP/Apollo is really pushing X Windows, Phigs, and Motiff as the graphics standards of the future ... I would not gamble on starting any new graphics programs using GPR, GMR2D, or GMR3D unless they are written in a modular fashion so that the graphics portion of the code and be easily ripped out and replaced with X or Phigs code. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
jsh0447@DOMAIN_2.lerc.nasa.gov (Jeff Hojnicki) (05/31/90)
Thanks for the responses so far. Just thought I would post a brief update since we have discovered a few things since I first posted. First, we were trying to generate the PostScript file calling gm_$print_file with a "print_style" of gm_$postscript. Well we found out that in the 9.7.5 version of the gmr include file (FORTRAN version) the variable gm_$postscript was undefined. Therefore, we were essentially sending a real value of 0.0, instead of the integer*2 of 2 which was needed. Surprisingly, this did not generate an error within the gm_$print_file routine for an undefined print_style, it just didn't generate the file. Also, we found that despite the manual's claim to the contrary, if the output file already exists, it will not overwrite it. These two problems caused us extreme headaches. We finally did get an ascii PostScript file from one of our routines, but it crashed in printing because of an undefined command called "color." Thanks to Mr. Krowitz for his help on that one, or we would have never found that we needed some mysterious header file. However, our problems are not over. We still cannot seem to get a PostScript file to be created at all from one of our routines. Does anyone know if using "within-GPR" mode could cause the problem??? Also, I would like to hear from others on Mr. krowitz opinion that gmr/gpr are not favored options in the HP/Apollo arena of the future. That bothers me since we are stuck using gpr/gmr for the forseeable future (we are also stuck at 9.7.5 for several months, but that is another story). Also, we are scheduled to soon receive a large piece of code with all the graphics written in gmr/3d. What is the scoop people? Is this really a dead package? We are anxious to get our hands on Motif, but are constrained by budget, priorities and our current operating system? Any opinions would be appreciated. -- Jeff Hojnicki | jshoj@csd.lerc.nasa.gov | // // // // NASA/LeRC | jhojnicki@nasamail.nasa.gov | =====FREEDOM====== (216)-433-5393 | - - - - - - - - - - - - - - - - - -| // // () () // // "My opinions are my own, don't blame NASA for them!" |
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (05/31/90)
If my memory serves me correctly, I recall that the GMR-2D manual mentions that the "within GPR" mode of GMR disables a fair amount of the auto scaling, translation, etc. functions of GMR. I think this would apply to the GMR_$PRINT... calls, too. We use the GM_$PRINT_FILE call to produce GMF bitmap files and OUT1 vector-dump files (for later translation to HPGL) in a wide range of home-built graphics utilities. In general, we have had a *LOT* of problems with it -- incorrect instance/transform operations, missing text strings, internal arithmetic overflows, etc. The situation has not gotten better with GMR-2D version 2.0 - 2.2 (the SR10 versions of 2D GMR). If anything, they have become worse. I have just received version 2.3 of 2D GMR, which I will install and test in a day or two to see if it fixes any of the bugs which Apollo introduced at version 2.0 -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)