Forum unknown
· Telecommunications
#comm/vt100/printscreen
17 messages in this thread
Don,
I agree that there would have to be custom code, but there are better ways to
handle it than 'keeping a text screen' with all its attendant overhead. A
sufficiently large circular buffer would do the trick, and you could access it
when needed, formatting the output to reflect the current screen. Sorta
'working backwards' through the captured text, if you follow what I mean.
-larry
Larry,
A circular buffer wouldn't tell you which window was on top at the time
you asked for the dump, it would only show what characters (and position
sequences) had recently been placed on the screen.
With a circular buffer, a background task writing to a window that was
'backed', could concievably wrap the buffer so only it's text was in the
buffer.
Now I realize that you could have some intelligence in your custom code
to only print to the circular buffer IF the window was on top…but then you
eliminate the ability of bringing a backed window to front and then doing a
dump since the text wouldn't have been captured in the first place.
I also see problems in the print algroithm, what if you had just issued
a clear screen and then had 1 line of text printed. Your print algorithm would
have to go backwards thru the circular buffer and fill out it's text dump as
you went to properly re-construct the screen.
To me, it would be much easier to have an 80×24 (or whatever) array and
all calls to text() would also 'print' in this array. A call to print screen
would then only have to print that buffer. Again, this would require that
screen clears would clear that particular portion of the array and that also
assumes (and I don't know for sure) if smart-refreshes calls text to re-create
the text in a window that has it's size changed, or when it poped to the back
or front.
Probably the easiest way (althou it's still not easy) is for a print
screen routine to look at the bit map and then compare bit patterns with the
bit patterns in the proper font file. From that, it could re-create the text
only and build it's array to send to the printer. Of course, one problem I see
there is that the print-screen function would have to lock the screen until it
was done.
Don
Yeah – and since there is no attribute map for that characters in the various
(many possible) console windows open, how do you know, for instance, if the top
ten lines are Ruby 12 pt and the bottom 14 are Topaz? Huh? You _need_ a text
map, and you _need_ an attribute map. Also, I think "print screen" here is
something we need to define. You can ONLY have a "printscreen" on the Amiga if
you go graphic. What you can (and should) have is a "print conwindow" which
offers the same basic capabilities that a messed-up dos machine has as a print
screen. But – you cannot DO this unless you have a record of what is there. You
can't even use pattern recognition if there are multiple fonts in the window –
if the guy is now in topaz, and he was in ruby, then the top lines are trash as
far as the pattern-parser is concerned. Really. This stuff seems pretty obvious
to me… gimme some source. I have itchy fingers. –Ben–
Ben,
Ok…my idea of a 'print screen' (vs. dump screen) is a straight text
dump. Whatever text is there is dumped, everything else is ignored.
That way, you could have an 80×24 text array in memory. Everytime an
ASCII character was printed to a window or screen, it would also be placed in
that screen's text array in the proper position. Well…maybe we'd have to
define a 132×50 line array for overscan…but I think you get the idea.
If window 1 overlays window 2 on the same screen, the text from window
1 would overlay the current text from window 2. The only thing I see 'hard'
about this is the smart-refresh. I'm not sure if the Intuition routines for
doing that call text() or not.
Don
Well, I think that a textual print screen is not reasonable to do on the Amiga,
period. Text print window, yes. Anything beyond that, and you have to get into
graphics capability, imho. So I wouldn't be interested in generating what
you're currently describing. To me, each individual conwindow should be a
complete text environment… if you want the screen's contents, do a print
screen…. which gets you all the graphics, too. –Ben–
Ben,
I agree….the GraphicDump program supplies you with the capability to
do a dump of the screen right now. However, there major drawback to that is
the speed. The way it works is that it only reads the screen, when it's ready
to print that portion of it. So if you issued the command, and then change the
screen while it's printing…you get different stuff on the top of the screen
printout than you get on the bottom of the screen printout.
The easiest way around this is to make a copy of the current screen in
another area of memory and then use that copy to do the graphic dump. It's
still slow…but at least allows you to do other things once you've issued the
command.
Don
Ben,
I agree….the GraphicDump program supplies you with the capability to
do a dump of the screen right now. However, there major drawback to that is
the speed. The way it works is that it only reads the screen, when it's ready
to print that portion of it. So if you issued the command, and then change the
screen while it's printing…you get different stuff on the top of the screen
printout than you get on the bottom of the screen printout.
The easiest way around this is to make a copy of the current screen in
another area of memory and then use that copy to do the graphic dump. It's
still slow…but at least allows you to do other things once you've issued the
command.
Don
Well, I think that a textual print screen is not reasonable to do on the Amiga,
period. Text print window, yes. Anything beyond that, and you have to get into
graphics capability, imho. So I wouldn't be interested in generating what
you're currently describing. To me, each individual conwindow should be a
complete text environment… if you want the screen's contents, do a print
screen…. which gets you all the graphics, too. –Ben–
Ben,
Ok…my idea of a 'print screen' (vs. dump screen) is a straight text
dump. Whatever text is there is dumped, everything else is ignored.
That way, you could have an 80×24 text array in memory. Everytime an
ASCII character was printed to a window or screen, it would also be placed in
that screen's text array in the proper position. Well…maybe we'd have to
define a 132×50 line array for overscan…but I think you get the idea.
If window 1 overlays window 2 on the same screen, the text from window
1 would overlay the current text from window 2. The only thing I see 'hard'
about this is the smart-refresh. I'm not sure if the Intuition routines for
doing that call text() or not.
Don
Yeah – and since there is no attribute map for that characters in the various
(many possible) console windows open, how do you know, for instance, if the top
ten lines are Ruby 12 pt and the bottom 14 are Topaz? Huh? You _need_ a text
map, and you _need_ an attribute map. Also, I think "print screen" here is
something we need to define. You can ONLY have a "printscreen" on the Amiga if
you go graphic. What you can (and should) have is a "print conwindow" which
offers the same basic capabilities that a messed-up dos machine has as a print
screen. But – you cannot DO this unless you have a record of what is there. You
can't even use pattern recognition if there are multiple fonts in the window –
if the guy is now in topaz, and he was in ruby, then the top lines are trash as
far as the pattern-parser is concerned. Really. This stuff seems pretty obvious
to me… gimme some source. I have itchy fingers. –Ben–
Don,
What 'other windows'? We were speaking of a VT100 emulator, with (presumably)
one window (or it wouldn't be VT100).
Anyway, a backward search through memory is exactly what you would need to
do, and would be far faster than the constant slowdown, as you pointed out
would happen, if a buffer was maintained. For that matter, you could reset a
couple of pointers on each receipt of a clear screen, and bingo, no buffer
contents, and for how much time taken? Perhaps 5 microseconds per clear screen
character.
-larry
Larry,
I 'expanded' the discussion of a print screen to include a generic
function…not specific to the vt100 (or any other terminal program). I guess
that's where the confusion came in.
Don
Don,
Right… saw that later. it is a considerably bigger problem that way, being
that it must, of necessty, fit in with the system as a whole.
-larry
Don,
Right… saw that later. it is a considerably bigger problem that way, being
that it must, of necessty, fit in with the system as a whole.
-larry
Larry,
I 'expanded' the discussion of a print screen to include a generic
function…not specific to the vt100 (or any other terminal program). I guess
that's where the confusion came in.
Don
Don,
What 'other windows'? We were speaking of a VT100 emulator, with (presumably)
one window (or it wouldn't be VT100).
Anyway, a backward search through memory is exactly what you would need to
do, and would be far faster than the constant slowdown, as you pointed out
would happen, if a buffer was maintained. For that matter, you could reset a
couple of pointers on each receipt of a clear screen, and bingo, no buffer
contents, and for how much time taken? Perhaps 5 microseconds per clear screen
character.
-larry
Larry,
A circular buffer wouldn't tell you which window was on top at the time
you asked for the dump, it would only show what characters (and position
sequences) had recently been placed on the screen.
With a circular buffer, a background task writing to a window that was
'backed', could concievably wrap the buffer so only it's text was in the
buffer.
Now I realize that you could have some intelligence in your custom code
to only print to the circular buffer IF the window was on top…but then you
eliminate the ability of bringing a backed window to front and then doing a
dump since the text wouldn't have been captured in the first place.
I also see problems in the print algroithm, what if you had just issued
a clear screen and then had 1 line of text printed. Your print algorithm would
have to go backwards thru the circular buffer and fill out it's text dump as
you went to properly re-construct the screen.
To me, it would be much easier to have an 80×24 (or whatever) array and
all calls to text() would also 'print' in this array. A call to print screen
would then only have to print that buffer. Again, this would require that
screen clears would clear that particular portion of the array and that also
assumes (and I don't know for sure) if smart-refreshes calls text to re-create
the text in a window that has it's size changed, or when it poped to the back
or front.
Probably the easiest way (althou it's still not easy) is for a print
screen routine to look at the bit map and then compare bit patterns with the
bit patterns in the proper font file. From that, it could re-create the text
only and build it's array to send to the printer. Of course, one problem I see
there is that the print-screen function would have to lock the screen until it
was done.
Don