Joined: 11 Jan 2006 Posts: 83 Location: Lower Saxony (DE)
Hi there everybody,
preparing a documentation for some colleagues and trainees of mine again I am missing a special feature in our companies 3270 emulation (IBM Host on Demand):
I'd like to capture 3270 screens fully or partly and paste these captures in a Word document.
Needles to say there are two common ways to do so:
First is to mark the area and copy and paste the text. When pasted in the document the text remains text and can by marked, copied, pasted and so on by the author or the reader. But this does not copy the formattings / colours. So if the author wants to have the text in its original colours (for highlighting or what ever) he has to re-colour the capture. - Only a half of what I am looking for
The other way is to take a screenshot (full screen or with a snipping tool) and paste it in the Word document. Doing so all the colourings remain. But the text can not be marked and so on anymore 'cause it's just a picture. - The other half but as well only a half
Does anybody of you know a 3270 emulator which combines both techniques and provides a feature which copies the text with his formattings?
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
This might be a Good Idea, but you forgot four important details:
Which word processor? They are all different; inserting the color (and font, for that matter) markups are pretty much word processor dependent.
Which color map? Many emulators allow the user to fiddle with the color map. Certainly I do, so my colors, which are readable to me because my color vision is just a bit out of whack, may confuse your reader who is probably expecting the standard color map.
Font? Most of the time you'll find a screen image, as a graphic, is too large or too small when printed. I also find most PC fonts are very weird in their leading; which affects their appearance on the screen and in printing, and it will make sizing the image more difficult. Resizing an image is easier than resizing a purely text area.
Production (of the publication). Printers don't like dealing with colors. What looks simple on screen becomes expensive on the press and it affects how much your reader has to pay for your publication. Actually your monochrome copy and paste works well for the printer.
Joined: 11 Jan 2006 Posts: 83 Location: Lower Saxony (DE)
steve-myers wrote:
This might be a Good Idea, but you forgot four important details:
Which word processor? They are all different; inserting the color (and font, for that matter) markups are pretty much word processor dependent.
Which color map? Many emulators allow the user to fiddle with the color map. Certainly I do, so my colors, which are readable to me because my color vision is just a bit out of whack, may confuse your reader who is probably expecting the standard color map.
Font? Most of the time you'll find a screen image, as a graphic, is too large or too small when printed. I also find most PC fonts are very weird in their leading; which affects their appearance on the screen and in printing, and it will make sizing the image more difficult. Resizing an image is easier than resizing a purely text area.
Production (of the publication). Printers don't like dealing with colors. What looks simple on screen becomes expensive on the press and it affects how much your reader has to pay for your publication. Actually your monochrome copy and paste works well for the printer.
Hi Steve,
some good points.
Which word processor? An 'ordinary' word processor like MS-Word or similar
Which color map? Well, I'd say that colours that are displayed in the emulator. The main thing is there are different colours to distinguish different meanings of the shown text. No matter if reserved COBOL words are red and variables are green or vice versa.
Font? Should be a monospaced font. Hasn't each emulator its own default font settings - which perhaps could be changed by the user?
Production of publication Yes, d'accord. But this problem remains when using screen capture pictures in the documentation. Maybe it's helpful to invert the colours or minimum the background colour. But an invert colour feature might be step 2.
One note: in the most fancy format, you may have to change some characters to cater for differences in UK and German codepages. Samples of the output (REXX only) are at Prino's z/OS Tools and utilities
Joined: 14 Dec 2009 Posts: 6 Location: Perth, Western Australia
Back in the early 00s, I was frustrated by the low fidelity of IBM 3270 terminal screen captures in the IBM product documentation that I was writing.
At the time, the people responsible for publishing that documentation would not accept terminal screen captures as bitmaps; they wanted text. Bitmaps would have been an easy way for me to reproduce the 3270 screens in their original colors, and with other attributes, such as underlining, preserved. In hindsight, I am grateful to those people, because it pushed me to develop a better solution.
I developed an in-house tool, "Capter", that uses the IBM Personal Communications (PCOMM) terminal emulator to capture screens in various text-based formats with color and other attributes, including underlining, intact: in DITA, (X)HTML, and Microsoft rich text format (RTF).
Why PCOMM? Because that's what my colleagues and I use; it's the emulator my employer provides.
Capter uses PCOMM's "print screen (to disk file)" combined with custom printer definitions. I developed printer definition tables (PDTs) that "print" to DITA, XHTML, and RTF. Capter uses the PCOMM COM interface to set the appropriate PDT, and then SendKeys "[printps]" to capture the screen.
To render 3270 screens in color in IBM product publication PDFs, I developed an XSLT stylesheet that transforms the Capter-generated DITA <screen> elements into encapsulated PostScript (EPS).
For examples of this EPS in use, see page 82 (PDF sheet 94) in the following PDF file:
Outside of IBM product documentation, I use Capter to reproduce 3270 screens in Microsoft Word and PowerPoint. I have a custom toolbar button in Word and PowerPoint; I click the button, and then a capture of my current PCOMM session A appears at the Word insertion point, or on the current PowerPoint slide.
I use the XHTML-format captures in web browsers; for example, to report issues with z/OS ISPF panels in Atlassian Jira (requires the Jira html macro).
For examples of Capter-generated 3270 screens in PowerPoint (rendered in the IBM Plex Mono font), see my video "The Lifecycle of an IMS Connect Transaction" recently published on the IBM Z YouTube channel:
Capter is an in-house tool, not publicly available. However, it's not magic: I simply followed the PCOMM documentation to create my own PDTs, and then wrote a minimal VBScript wrapper to automate it.
Joined: 14 Dec 2009 Posts: 6 Location: Perth, Western Australia
For what it's worth (I realize this is just the lipstick; you want the pig ), here's the "Screen" paragraph style that I use in Word for 3270 screen captures:
Font: Consolas, 10 pt,
Do not check spelling or grammar,
Indent: Left: 2.1 mm, Right: 6 mm,
Keep with next,
Keep lines together,
Border: Top: (Single solid line, Auto, 0.25 pt Line width, From text: 6 pt Border spacing: )
Bottom: (Single solid line, Auto, 0.25 pt Line width, From text: 6 pt Border spacing: )
Left: (Single solid line, Auto, 0.25 pt Line width, From text: 6 pt Border spacing: )
Right: (Single solid line, Auto, 0.25 pt Line width, From text: 6 pt Border spacing: )
Pattern: Clear (Custom Color(RGB(248,248,248)))
Based on: Normal
That is: carefully chosen indents and border properties to fill the width of the page (US Letter with 1-inch margins); thin black border; light gray background.
I used to use the Lucida Console font, then I switched to Consolas. More recently, in some contexts, I use IBM Plex Mono (caution: Plex Mono does not yet contain box-drawing characters).
Word's "Text Highlight Color" tool (to highlight text background) is very useful for highlighting text in these screen captures. PowerPoint has a similar tool.
Before developing Capter, I used to painstakingly re-insert underlining in 3270 screen captures. I feel your pain.
I deliberately use a light background instead of black, but I've parameterized the colors so that it's easy enough to switch to a black background if required. Some people still like to print hardcopies; black-background screen captures are heavy on toner/ink.
Joined: 14 Dec 2009 Posts: 6 Location: Perth, Western Australia
I don't have any first-hand experience with Host On-Demand emulators. I gather from the Host On-Demand product documentation in IBM Knowledge Center that those emulators run Java inside a web browser; is that correct? The documentation also refers to using printer definition tables; I might be wrong, but, based on a cursory glance, the format looks identical to the same files in PCOMM.
Do you also have PCOMM? Or are you restricted to those in-browser emulators?
I wish I could simply provide you with Capter, rather than glibly referring to creating PDTs and writing a VBScript wrapper. There are some gotchas, some devils in the detail, that I've worked through.
Given enough interest, I could petition my employer for the time to make Capter publicly available.
Let me know if you are interested. Anyone else?
Another advantage of text-based 3270 screen captures: it's easy to replace sensitive data that you don't want published. Sometimes, it's not so easy to do that on "live" screens. It's possible to replace data in pixel-based captures, but far more onerous (I've been there).
For what it's worth, here's a playlist of videos I've created; all of them (so far) created in PowerPoint, most of them containing 3270 screen captures generated by Capter:
While that video doesn't contain examples of zooming in on 3270 screen captures, it does zoom in on a plain-text report. The same technique could be used for 3270 screens (I just haven't found the right excuse to do it yet): that is, to use the PowerPoint Morph transition to smoothly zoom in from a complete 3270 screen to an enlarged portion. By "smooth", I'm not just referring to the animation; I'm also referring to the fact that the zoomed-in portion is rendered as text, not just a jagged close-up of a pixel-based image.
In several of those videos, I use the Morph transition to smoothly scroll down through a "long" 3270 screen capture. I do something similar in Word documents: I "concatenate" into a single figure a set of screens that, in practice, in a terminal emulator, you'd need to (press PF8 to) scroll through.
Too much info? Sorry. I've invested some time and effort in capturing and rendering 3270 screens in various output formats. It's nice to get the chance to write about it.
I don't think I've published any similar Word-based documents containing 3270 captures on the Web; I mostly use such documents for training in-house.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
Graham Hannington wrote:
I wish I could simply provide you with Capter, rather than glibly referring to creating PDTs and writing a VBScript wrapper. There are some gotchas, some devils in the detail, that I've worked through.
Given enough interest, I could petition my employer for the time to make Capter publicly available.
Let me know if you are interested. Anyone else?
What would your employer loose by making it publicly available? They would gain quite a bit of goodwill by putting it under a liberal licence on the CBTTape site.
When I left Willis in 1996, and asked if I could take the source (all REXX) of some tools I had written while working for them, the then chief-programmer told me that he would have been surprised if I hadn't already taken it. ;)
All my stuff (see signature) is available under the GPL V3 (or later)
Joined: 14 Dec 2009 Posts: 6 Location: Perth, Western Australia
prino wrote:
What would your employer lose by making it publicly available?
My time. I'd want to improve the packaging and documentation before making it publicly available. That might take several days. I don't have much "spare" time (busy at work; two young children at home).
prino wrote:
They would gain quite a bit of goodwill by putting it under a liberal licence on the CBTTape site.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
prino wrote:
What would your employer loose by making it publicly available? They would gain quite a bit of goodwill by putting it under a liberal licence on the CBTTape site.
When I left Willis in 1996, and asked if I could take the source (all REXX) of some tools I had written while working for them, the then chief-programmer told me that he would have been surprised if I hadn't already taken it.
...
Would that still be true today? When I joined my present employer in 2010 I had to sign several pages of Intellectual Property legalese.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
don.leahy wrote:
prino wrote:
What would your employer loose by making it publicly available? They would gain quite a bit of goodwill by putting it under a liberal licence on the CBTTape site.
When I left Willis in 1996, and asked if I could take the source (all REXX) of some tools I had written while working for them, the then chief-programmer told me that he would have been surprised if I hadn't already taken it.
...
Would that still be true today? When I joined my present employer in 2010 I had to sign several pages of Intellectual Property legalese.
I don't know, that's why I nowadays develop my tools on my own z/OS system.
When I joined my present employer in 2010 I had to sign several pages of Intellectual Property legalese.
Quote:
that's why I nowadays develop my tools on my own z/OS system.
ok when on employer time and using employer equipment
but ...
when - a loong time ago - i signed that HM for IBM
it was clearly specified that the rule covered also artifacts developed on my own time and my own equipment
( at that time people could not afford to be be choosy )
), here's the "Screen" paragraph style that I use in Word for 3270 screen captures:
