Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
graphics program oddity
29 views
Skip to first unread message
tho...@antispam.ham
Jan 20, 2012, 7:00:44 AM1/20/12
to
I have a Fortran plotting program that was built using CVF 6.6c,
the graphics library, and the QUICKWIN option. It generates a
scatter plot, labeling each point, and also labeling each of the
axis tick marks. The program is designed to plot one point,
then its label, then the next point, its label, and so on. When
I run it under Windows XP, it works fine. When I run it under
Windows 7, on a few rare occasions, it has actually worked as
it's supposed to, but most of the time, it generates only the
axes and points, but no labels. Because the generation of
points and labels are interleaved, it's obviously not dying
before it gets to the stage where it is supposed to generate a
label. Indeed, it seems to behave normally, with no error
messages.
At first, I thought it was a font issue, Windows 7 perhaps not
having the same font as used by Windows XP, but because I have
seen it generate labels on a few occasions, I have discarded
that notion.
On one occasion, I tried generating one particular plot several
times in a row, with failure to generate labels each time. Then
I tried it on a different plot and it worked. Then I went back
to the previous plot, and it worked! So it's a bit unpredictable
as to when it will work and when it will fail, but the failure
rate is unacceptably high.
Has anyone seen behavior like this with a solution to the
problem?
the graphics library, and the QUICKWIN option. It generates a
scatter plot, labeling each point, and also labeling each of the
axis tick marks. The program is designed to plot one point,
then its label, then the next point, its label, and so on. When
I run it under Windows XP, it works fine. When I run it under
Windows 7, on a few rare occasions, it has actually worked as
it's supposed to, but most of the time, it generates only the
axes and points, but no labels. Because the generation of
points and labels are interleaved, it's obviously not dying
before it gets to the stage where it is supposed to generate a
label. Indeed, it seems to behave normally, with no error
messages.
At first, I thought it was a font issue, Windows 7 perhaps not
having the same font as used by Windows XP, but because I have
seen it generate labels on a few occasions, I have discarded
that notion.
On one occasion, I tried generating one particular plot several
times in a row, with failure to generate labels each time. Then
I tried it on a different plot and it worked. Then I went back
to the previous plot, and it worked! So it's a bit unpredictable
as to when it will work and when it will fail, but the failure
rate is unacceptably high.
Has anyone seen behavior like this with a solution to the
problem?
Gordon Sande
Jan 20, 2012, 9:10:11 AM1/20/12
to
the plot under reasonable assumptions. But if the symbol and label
are not transparent then it becomes very confusing as what you see
is order dependent. Changing tranparency defaults is the sort of thing
that may happen in changing Windows versions. Symbols and labels can be
hard to see if they are the same color as the background. For printer
plotters it can be hard to find transparent symbols so if they are
doing a good job of emulating a printer plotter it may not be what
you wanted. I can attest to the fact that emulating overprinting for
a printer plotter is a serious pain.
Try plotting one point, then a few points and then more points on a plot
before displaying the results. Check the settings for color and tranparency.
I like black on white displays for editors and such. Often the default is
white on black. If I mangle the change of settings I find it hard to read
white text on a white background, or even black on black. I can not even
read dark blue on black that some web sites thing is artistic. :-(
dpb
Jan 20, 2012, 9:17:39 AM1/20/12
to
On 1/20/2012 6:00 AM, tho...@antispam.ham wrote:
...
I'd suggest trying to update any video drivers and as Gordon suggests,
checking the video settings. I suspect it's a rendering problem of some
variety, not code...
--
...
> I run it under Windows XP, it works fine. When I run it under
> Windows 7, on a few rare occasions, it has actually worked as
> it's supposed to, but most of the time, it generates only the
> axes and points, but no labels. Because the generation of
> points and labels are interleaved, it's obviously not dying
> before it gets to the stage where it is supposed to generate a
> label. Indeed, it seems to behave normally, with no error
> messages.
>
> At first, I thought it was a font issue, Windows 7 perhaps not
> having the same font as used by Windows XP, but because I have
> seen it generate labels on a few occasions, I have discarded
> that notion.
...
> Windows 7, on a few rare occasions, it has actually worked as
> it's supposed to, but most of the time, it generates only the
> axes and points, but no labels. Because the generation of
> points and labels are interleaved, it's obviously not dying
> before it gets to the stage where it is supposed to generate a
> label. Indeed, it seems to behave normally, with no error
> messages.
>
> At first, I thought it was a font issue, Windows 7 perhaps not
> having the same font as used by Windows XP, but because I have
> seen it generate labels on a few occasions, I have discarded
> that notion.
I'd suggest trying to update any video drivers and as Gordon suggests,
checking the video settings. I suspect it's a rendering problem of some
variety, not code...
--
Terence
Jan 22, 2012, 5:40:44 PM1/22/12
to
You didn't say how the labels were generated.
Assuming Calcomp-style plotting syntax, (which I used just a few months ago
to create a nice plotting library), there are two ways to produce a numeric
label (e.g. for a tick mark).
These are:
SUBROUTINE SYMBOL(X,Y,SIZE,CSTR,ANG,LCH)
SUBROUTINE NUMBER(X,Y,SIZE,F,ANG,I)
Where X.Y are the start point coordinates, SIZE is a vertical measure of
character height, ANG is the angle in degrees counterclockwise from
horizontal (normally 0.0 for 2-D graph tick marks), and F is the real value
to be turned into a string with I decimals, or CSTR is the print-ready
string of count LCH characters to be used. Length units are in inches.
In my case I had to write my own NUMBER subroutine to turn the data into a
new string to be then output with a call to SYMBOL. This was because of the
inconsistent (with Calcomp) ways I found NUMBER to be be used in programs
of the 1960's. I also found many cases in old Fortran programs, where the
order of parameters was not as per the then-current standard, including the
passing of integer values where a real variable was expected in F.
Could you give a short sample of code relating to the generation of the tick
labels?
I was using CVF/DFV 6.6.1c with no problems.
Assuming Calcomp-style plotting syntax, (which I used just a few months ago
to create a nice plotting library), there are two ways to produce a numeric
label (e.g. for a tick mark).
These are:
SUBROUTINE SYMBOL(X,Y,SIZE,CSTR,ANG,LCH)
SUBROUTINE NUMBER(X,Y,SIZE,F,ANG,I)
Where X.Y are the start point coordinates, SIZE is a vertical measure of
character height, ANG is the angle in degrees counterclockwise from
horizontal (normally 0.0 for 2-D graph tick marks), and F is the real value
to be turned into a string with I decimals, or CSTR is the print-ready
string of count LCH characters to be used. Length units are in inches.
In my case I had to write my own NUMBER subroutine to turn the data into a
new string to be then output with a call to SYMBOL. This was because of the
inconsistent (with Calcomp) ways I found NUMBER to be be used in programs
of the 1960's. I also found many cases in old Fortran programs, where the
order of parameters was not as per the then-current standard, including the
passing of integer values where a real variable was expected in F.
Could you give a short sample of code relating to the generation of the tick
labels?
I was using CVF/DFV 6.6.1c with no problems.
Terence
Jan 23, 2012, 10:43:55 PM1/23/12
to
It just aoccurred to me what the problem might be.
The "normal" Calcomp routines start by defining an array as a work area and
and opening (usually unit 9) a file as an output plooter instruction text
file to command a plotter.
The pen commands that have special codes which invoke closing one plot and
openeing another.
These can be confused by the programmer to do something very different form
what is intended.
I arranged to use a worm area to plot into and then write out the files
matrix as RTF-coded text to maintain the image for printing via Word or RTF
reader/writes (and then zero out the work matrix).
I found it necessary to do something else different form yhr normal pen code
and modify what the possibles pen code did as follows (NDPI is dots per
inch; X.Y are new or old origin coordinates in inches..
SUBROUTINE PLOT(X,Y,JPEN)
C NOTE: ORIGINAL CALCOMP CODE SET CURSOR TO X,Y OR NEW X,Y (0.,0.)
C JPEN=
C 0 SET FRAME SIZE TO X INCH BY Y INCH (i.e. X+NDPI,Y*NDPI)
C 1 JUST SET CURSOR TO (X,Y)
C -1 SET NEW ORIGIN (X,Y), BUT DOES NOT END THIS PLOT (DOUBLE AXES?)
C 2 DRAW LINE FROM LAST POINT TO RELATIVE X,Y; SET CURSOR.
C -2 DRAW LINE FROM LAST POINT TO RELATIVE X,Y; THIS BECOMES ORIGIN
C 3 MOVE TO RELATIVE POINT X,Y. SET CURSOR.
C -3 MOVE TO RELATIVE POINT X,Y. SET AS NEW ORIGIN. ENDS THIS PLOT.
C>998 CLOSES PLOT FILE
The "normal" Calcomp routines start by defining an array as a work area and
and opening (usually unit 9) a file as an output plooter instruction text
file to command a plotter.
The pen commands that have special codes which invoke closing one plot and
openeing another.
These can be confused by the programmer to do something very different form
what is intended.
I arranged to use a worm area to plot into and then write out the files
matrix as RTF-coded text to maintain the image for printing via Word or RTF
reader/writes (and then zero out the work matrix).
I found it necessary to do something else different form yhr normal pen code
and modify what the possibles pen code did as follows (NDPI is dots per
inch; X.Y are new or old origin coordinates in inches..
SUBROUTINE PLOT(X,Y,JPEN)
C NOTE: ORIGINAL CALCOMP CODE SET CURSOR TO X,Y OR NEW X,Y (0.,0.)
C JPEN=
C 0 SET FRAME SIZE TO X INCH BY Y INCH (i.e. X+NDPI,Y*NDPI)
C 1 JUST SET CURSOR TO (X,Y)
C -1 SET NEW ORIGIN (X,Y), BUT DOES NOT END THIS PLOT (DOUBLE AXES?)
C 2 DRAW LINE FROM LAST POINT TO RELATIVE X,Y; SET CURSOR.
C -2 DRAW LINE FROM LAST POINT TO RELATIVE X,Y; THIS BECOMES ORIGIN
C 3 MOVE TO RELATIVE POINT X,Y. SET CURSOR.
C -3 MOVE TO RELATIVE POINT X,Y. SET AS NEW ORIGIN. ENDS THIS PLOT.
C>998 CLOSES PLOT FILE
glen herrmannsfeldt
Jan 24, 2012, 6:20:45 AM1/24/12
to
Terence <tbwr...@bigpond.net.au> wrote:
> It just aoccurred to me what the problem might be.
> The "normal" Calcomp routines start by defining an array as a work area and
> and opening (usually unit 9) a file as an output plooter instruction text
> file to command a plotter.
> The pen commands that have special codes which invoke closing one plot and
> openeing another.
Reminds me of another interesting way that the Calcomp routines work.
> It just aoccurred to me what the problem might be.
> The "normal" Calcomp routines start by defining an array as a work area and
> and opening (usually unit 9) a file as an output plooter instruction text
> file to command a plotter.
> The pen commands that have special codes which invoke closing one plot and
> openeing another.
There is a SCALE routine that computes an appropriate scale factor
and origin for an array of data values. (Separately for X and Y.)
Instead of the more usual returning the scale factor and origin
through subroutine arguments, they are added as elements N+1 and N+2
to the array.
The arrays must be dimensioned at least two more than the number
of data points. Also, if one isn't careful, one could get the data
points and scale factor/offset mixed up with very strange plot
results. (Especially for pen plotters, where the pen could move
off the paper.)
-- glen
tho...@antispam.ham
Jan 24, 2012, 7:01:02 PM1/24/12
to
Not explicitly, but I did say that I use CVF 6.6c's graphics library.
> Assuming Calcomp-style plotting syntax, (which I used just a few months ago
> to create a nice plotting library), there are two ways to produce a numeric
> label (e.g. for a tick mark).
>
> These are:
>
> SUBROUTINE SYMBOL(X,Y,SIZE,CSTR,ANG,LCH)
> SUBROUTINE NUMBER(X,Y,SIZE,F,ANG,I)
>
> Where X.Y are the start point coordinates, SIZE is a vertical measure of
> character height, ANG is the angle in degrees counterclockwise from
> horizontal (normally 0.0 for 2-D graph tick marks), and F is the real value
> to be turned into a string with I decimals, or CSTR is the print-ready
> string of count LCH characters to be used. Length units are in inches.
I use
CALL OUTGTEXT(Text(1:4))
> In my case I had to write my own NUMBER subroutine to turn the data into a
> new string to be then output with a call to SYMBOL. This was because of the
> inconsistent (with Calcomp) ways I found NUMBER to be be used in programs
> of the 1960's. I also found many cases in old Fortran programs, where the
> order of parameters was not as per the then-current standard, including the
> passing of integer values where a real variable was expected in F.
>
> Could you give a short sample of code relating to the generation of the tick
> labels?
> I was using CVF/DFV 6.6.1c with no problems.
The above call is used after every point is plotted. Each point is
labeled with a four digit number.
> Assuming Calcomp-style plotting syntax, (which I used just a few months ago
> to create a nice plotting library), there are two ways to produce a numeric
> label (e.g. for a tick mark).
>
> These are:
>
> SUBROUTINE SYMBOL(X,Y,SIZE,CSTR,ANG,LCH)
> SUBROUTINE NUMBER(X,Y,SIZE,F,ANG,I)
>
> Where X.Y are the start point coordinates, SIZE is a vertical measure of
> character height, ANG is the angle in degrees counterclockwise from
> horizontal (normally 0.0 for 2-D graph tick marks), and F is the real value
> to be turned into a string with I decimals, or CSTR is the print-ready
> string of count LCH characters to be used. Length units are in inches.
CALL OUTGTEXT(Text(1:4))
> In my case I had to write my own NUMBER subroutine to turn the data into a
> new string to be then output with a call to SYMBOL. This was because of the
> inconsistent (with Calcomp) ways I found NUMBER to be be used in programs
> of the 1960's. I also found many cases in old Fortran programs, where the
> order of parameters was not as per the then-current standard, including the
> passing of integer values where a real variable was expected in F.
>
> Could you give a short sample of code relating to the generation of the tick
> labels?
> I was using CVF/DFV 6.6.1c with no problems.
labeled with a four digit number.
Tim Prince
Jan 24, 2012, 7:02:17 PM1/24/12
to
tho...@antispam.ham
Jan 24, 2012, 7:05:18 PM1/24/12
to
"Terence" <tbwr...@bigpond.net.au> writes:
> It just aoccurred to me what the problem might be.
> The "normal" Calcomp routines start by defining an array as a work area and
> and opening (usually unit 9) a file as an output plooter instruction text
> file to command a plotter.
It's been years since I wrote the program, so maybe my memory of the
> It just aoccurred to me what the problem might be.
> The "normal" Calcomp routines start by defining an array as a work area and
> and opening (usually unit 9) a file as an output plooter instruction text
> file to command a plotter.
graphics library in CVF 6.6c is fuzzy, but I don't recall seeing
anything specific to CALCOMP. The problem definitely seems to be
related to running the program under Windows 7 rather than Windows XP.
Really frustrating is the fact that I haven't yet noticed any pattern
to when the few cases that worked occurred.
Richard L. Citerley
Jan 24, 2012, 8:43:28 PM1/24/12
to
The Calcomp routines that I have show that SCALE defines FIRSTV and DELTAV
for the parameters given.
These parameters are then placed in the arrays X and Y as X(N+1) and X(N+2),
likewise for Y. AXIS starts with
FIRSTV and DELTAV, but modifies the location of "tic" marks using an array
called SAVT. This array establishes
a normalized and scaled value from 1.0 to 10.0. From this definition, a
power (10.0**ipower) function scales the
array to be plotted. So, the two definitions of FIRSTV and DELTAV may be
different. NUMBER uses the second
definition (using SYMBOL) to correctly place the scaled number along the
proper "Tic" marks. LINE places either
a series of dots, connected dots or line(s).
Dr. Norman Lawrence, " Compaaq Visual Fortran" shows how to use the various
screen functions supplied in
CVF 6.6 (b or c) to map the eventual Calcomp results into a screen
coordinate system. Functions nexx, neyy and
others are used to translate a point from a Calcomp space into a screen
space under the QUICKWIN option.
A demonstratioon *.for program :
subroutine start_TEST
USE DFLIB
USE DFWIN
implicit real*4(a-h,o-z)
DIMENSION X(75),Y(75)
DATA XMIN/0.0/,XMAX/8.0/,XLEN/4.0/,YMIN/0.0/YMAX/8000.0/
DATA YLEN/4.0/,N/73/
OPEN(99,FILE='',FORM='FORMATTED',STATUS='UNKNOWN') ! output text file
CALL GET_USER('CAR')
CALL PLOTS(-1,1,1)
! [ initializes plot file next_plot=19,
CALL FACTOR(.75)
! defines the type of screen
M1=N+1
! the actual size of the screen (XLEN=4.0
M2=N+2
! YLEN 4.0)]
C X(M1)=XMIN
C Y(M1)=YMIN
C X(M2)=XMAX/XLEN
C Y(M2)=YMAX/YLEN
call scale(x,xlen,n,1,0)
C CALL PLOT(1.250,1.250,-3)
CALL AXIS(0.,0.0,'CAR MODEL AGE(YRS.)',-19,XLEN,0.,X(M1),X(M2),1) !
call scale(y,ylen,n,1,1)
CALL AXIS(0.,0.0,'CAR VALUE (DOLLARS)',19,YLEN,90.,Y(M1),Y(M2),1)
X(1)=XMIN
DO 10 I=2,N
10 X(I)=X(I-1)+0.1111111
DO 30 I=2000,8000,500
Y(1)=FLOAT(I)
DO 20 J=2,N
20 Y(J)=0.972*Y(J-1)
CALL LINE(X,Y,N,1,0,0)
30 CONTINUE
CALL SYMBOL(2.5,3.0,0.165,'AVERAGE CAR VALUE',0.,17)
C status = RECTANGLE( $GBORDER, INT2(0), INT2(0), maxx, maxy )
CALL EXIT
END
<tho...@antispam.ham> wrote in message
news:jfngnt$gns$1...@speranza.aioe.org...
for the parameters given.
These parameters are then placed in the arrays X and Y as X(N+1) and X(N+2),
likewise for Y. AXIS starts with
FIRSTV and DELTAV, but modifies the location of "tic" marks using an array
called SAVT. This array establishes
a normalized and scaled value from 1.0 to 10.0. From this definition, a
power (10.0**ipower) function scales the
array to be plotted. So, the two definitions of FIRSTV and DELTAV may be
different. NUMBER uses the second
definition (using SYMBOL) to correctly place the scaled number along the
proper "Tic" marks. LINE places either
a series of dots, connected dots or line(s).
Dr. Norman Lawrence, " Compaaq Visual Fortran" shows how to use the various
screen functions supplied in
CVF 6.6 (b or c) to map the eventual Calcomp results into a screen
coordinate system. Functions nexx, neyy and
others are used to translate a point from a Calcomp space into a screen
space under the QUICKWIN option.
A demonstratioon *.for program :
subroutine start_TEST
USE DFLIB
USE DFWIN
implicit real*4(a-h,o-z)
DIMENSION X(75),Y(75)
DATA XMIN/0.0/,XMAX/8.0/,XLEN/4.0/,YMIN/0.0/YMAX/8000.0/
DATA YLEN/4.0/,N/73/
OPEN(99,FILE='',FORM='FORMATTED',STATUS='UNKNOWN') ! output text file
CALL GET_USER('CAR')
CALL PLOTS(-1,1,1)
! [ initializes plot file next_plot=19,
CALL FACTOR(.75)
! defines the type of screen
M1=N+1
! the actual size of the screen (XLEN=4.0
M2=N+2
! YLEN 4.0)]
C X(M1)=XMIN
C Y(M1)=YMIN
C X(M2)=XMAX/XLEN
C Y(M2)=YMAX/YLEN
call scale(x,xlen,n,1,0)
C CALL PLOT(1.250,1.250,-3)
CALL AXIS(0.,0.0,'CAR MODEL AGE(YRS.)',-19,XLEN,0.,X(M1),X(M2),1) !
call scale(y,ylen,n,1,1)
CALL AXIS(0.,0.0,'CAR VALUE (DOLLARS)',19,YLEN,90.,Y(M1),Y(M2),1)
X(1)=XMIN
DO 10 I=2,N
10 X(I)=X(I-1)+0.1111111
DO 30 I=2000,8000,500
Y(1)=FLOAT(I)
DO 20 J=2,N
20 Y(J)=0.972*Y(J-1)
CALL LINE(X,Y,N,1,0,0)
30 CONTINUE
CALL SYMBOL(2.5,3.0,0.165,'AVERAGE CAR VALUE',0.,17)
C status = RECTANGLE( $GBORDER, INT2(0), INT2(0), maxx, maxy )
CALL EXIT
END
<tho...@antispam.ham> wrote in message
news:jfngnt$gns$1...@speranza.aioe.org...
Terence
Jan 26, 2012, 1:01:05 AM1/26/12
to
Sorry, I saw a lot of typos but that doesn't excuse not communicating.
I meant that if you work with someone else's Fortran programs that plot
data, it is probable that due to time lapse, the programs will use a form of
the Calcomp calls, being a useful "minimum" set of routines to perform
plotting with some complexity..
And Yes, there are also SCALE and AXIS routines which several programmers
offering Calcomp-similar routine libraries, refused to include as "not being
well understood". Still, I included them in mine, ( I added an option to
NOT store the start and scale values in the last two positions of each
vector to be plotted, but return the values) as well as a few combination
routines like "FRAME" to produce a rectangular inside-ticked box, with
angled corners, and DRAW to plot the point pairs defined by two vectors.
I think it's a good idea to plot to memory and output this memory block
horizontal row by row from the last upper row first. I chose to do this as
RTF code for more flexibility in display.
I meant that if you work with someone else's Fortran programs that plot
data, it is probable that due to time lapse, the programs will use a form of
the Calcomp calls, being a useful "minimum" set of routines to perform
plotting with some complexity..
And Yes, there are also SCALE and AXIS routines which several programmers
offering Calcomp-similar routine libraries, refused to include as "not being
well understood". Still, I included them in mine, ( I added an option to
NOT store the start and scale values in the last two positions of each
vector to be plotted, but return the values) as well as a few combination
routines like "FRAME" to produce a rectangular inside-ticked box, with
angled corners, and DRAW to plot the point pairs defined by two vectors.
I think it's a good idea to plot to memory and output this memory block
horizontal row by row from the last upper row first. I chose to do this as
RTF code for more flexibility in display.
Terence
Jan 26, 2012, 1:03:24 AM1/26/12
to
Calcomp suggest six characters (digits, sign and decimal point if needed) is
a minimum size.
Of course, Calcomp used inch measures.
a minimum size.
Of course, Calcomp used inch measures.
0 new messages