ktk@SPAM.ISTC.SRI.COM (Katy Kislitzin) (09/15/89)
Newsfolks--
My sales rep has sent me two messages on sun's open windows aka X11/NeWS +.
I am forwarding both messages on to the group, which I hope is legit.
Have trimmed the offending sales rep's name from the message.
This is the first of two messges. Note the EMPHASIS on x11. Note that
NeWS provides x users with display postcript capablities. hmmmm....
looks like NeWS needs an image-lift.
have fun.
--kt ( uunet!syzygy!ktk, hoptoad!syzygy!ktk )
------- Forwarded Message
Subject: a little bit of info on Open Windows
Please send all questions to ow@gorman (sun!gorman!ow).
Sun will announce and begin shipping OpenWindows on Monday September 18,
1989. SPARC is the platform of choice for running OpenWindows. This message
is intended to give you an update of the current status of the product. We
will be sending additional information on September 10th, including pricing
information.
This update includes the following information:
1. OpenWindows Positioning (short)
2. Availability
- ----------------------------------------------------------------------------
1. OpenWindows Positioning (short)
- ----------------------------------------------------------------------------
Our windows story continues to reflect our OpenWindows announcement at
Uniforum. It reinforces Sun's primary focus for FY90: SPARC, OPEN LOOK, UNIX.
Through OpenWindows, Sun delivers the network-based window system that offers
developers a larger sales-volume opportunity than any other company (or group
of companies) in the industry.
o This release is targeted primarily at ISVs and developers.
o This is a SPARC release. SPARC is Sun's best price/performance
platform.
o A large number of our customers will continue using SunView and
will start using OpenWindows in the future when a large number of
applications are ported from SunView to XView.
OpenWindows is a complete application environment available TODAY:
X11/NeWS: A high-performance X window system with the PostScript
language and imaging model capability of NeWS.
OPEN LOOK: The premium user interface for Unified UNIX System VR4.
Open Fonts: Access to over 50 high quality outline fonts that
exactly match printer output.
XView: A proven X toolkit for OPEN LOOK, bringing the 2100-strong
SunView applications to OPEN LOOK and X with easy migration.
DeskSet: OPEN LOOK desktop applications.
August 31, 1989
- 2 -
Sun's commitment to the elements of OpenWindows: X11/NeWS, OPEN
LOOK, Open Fonts, XView, and DeskSet remains strong and unwavering.
- ----------------------------------------------------------------------------
2. Availability
- ----------------------------------------------------------------------------
OpenWindows 1.0 is planned to be shipped on September 18, 1989; we are
currently working out details of that procedure. Through the field-supported
"specials" program, and through the SPARCware development kit supported
by corporate marketing, critical customers are already working with early
releases of OpenWindows. The "specials" program will be discontinued with
the FCS of OpenWindows 1.0.
System Configurations
OpenWindows 1.0 will be released as a standalone product on SPARC.
OpenWindows will require SunOS 4.0 and a minimum memory configuration of 8 MB.
------- End of Forwarded Messagebob@tinman.cis.ohio-state.edu (Bob Sutterfield) (09/15/89)
In article <8909142134.AA05482@pongfs.istc.sri.com> ktk@SPAM.ISTC.SRI.COM (Katy Kislitzin) writes:
Note that NeWS provides x users with display postcript capablities.
You mean "PostScript capabilities for display", not "Display
PostScript(tm) capabilities", right? I didn't see any mention of the
latter, and we wouldn't really expect to.korp@TRIPOLI.EES.ANL.GOV (12/22/89)
One of the many bugs listed in the developers release of Open Windows is the fact that the NeWS side is not device independent! Sun has done a lot of things wrong in attempting to promote NeWS but taking the device independence out of PostScript has to rank among the big ones. One of the major reasons we develop under NeWS was the fact that PostScript was device independent. Sun does not consider this a very important bug according to the ratings in the bug report. How can this be? Could someone please enlighten me about why this was done or if it will change any time soon? Peter korp@athens.ees.anl.gov Argonne National Laboratory
doc@jalapeno.UUCP (Tom Dockery) (12/23/89)
Inre the message: > >One of the many bugs listed in the developers release of Open Windows is >the fact that the NeWS side is not device independent! Sun has done a lot of >things wrong in attempting to promote NeWS but taking the device independence >out of PostScript has to rank among the big ones. One of the major reasons >we develop under NeWS was the fact that PostScript was device independent. >Sun does not consider this a very important bug according to the ratings in >the bug report. How can this be? Could someone please enlighten me about >why this was done or if it will change any time soon? > > > Peter > korp@athens.ees.anl.gov > Argonne National Laboratory > The answer is somewhat simple: it's rather difficult to scale everything appropriately to handle differing device densities if your have no way of determining those densities. As most (though certainly not all) monitors do not have any provisio for providing this information to the framebuffer (and most framebuffers wouldnt know what to do with it anyway), certain assumptions have to be made about the attached devices in advance. In our shop, we regularly swap 16 and 19 inch color monitors around. On a Sun cg-3 these both have a resolution of 1152 X 900; this means the 16 inch monitor has a higher density of pixels per unit measure in either dimension than the 19 inch. The basic unit of measure in PostScript is the point, 1/72 of an inch; not too metric, to be sure, but having a basis in the printing industry. If the PostScript (or NeWS) programmer knows, or can query, the density of the device to be driven, s/he can transform everything accordingly, so that the same PS source prints to the same result on a 300 or 900 dpi printer. The higher density printer then simply provides just that. If the programmer can neither know in advance, nor find out a run-time by query the density of the output device, however, s/he faces a quandry. There is no real way, short of modifying the hardware, to solve the problem in a device independent way; so the NeWS programmers took the approach of changing the abstraction somewhat, from representing a point as a fixed measure, to representing it as a pixel. This is *not* truely device independent, but it does mean I can scale my output on the basis of frame- buffer resolution, which at least is something. At least NeWS attempts to make some sort of abstraction; under X, you must handle the abstraction yourself. Which is the better approach? Whatever works, I suppose. The only way this situation will change, though, is for the window server to take advantage of the newer hardware that does provide density information, so that the programmer can work at the same level of abstraction s/he uses with a PostScript printer. Whew, maybe it wasnt that simple an answer! I hope it helps. Tom Dockery, Market Focus Technologies sun!suntan!fajita!doc
chan@hpfcmgw.HP.COM (Chan Benson) (12/28/89)
> The answer is somewhat simple: it's rather difficult to scale everything > appropriately to handle differing device densities if your have no way > of determining those densities. As most (though certainly not all) > monitors do not have any provisio for providing this information to the > framebuffer (and most framebuffers wouldnt know what to do with it anyway), > certain assumptions have to be made about the attached devices in advance. > In our shop, we regularly swap 16 and 19 inch color monitors around. On > a Sun cg-3 these both have a resolution of 1152 X 900; this means the 16 > inch monitor has a higher density of pixels per unit measure in either > dimension than the 19 inch. Certainly it would have been very easy (though a bit ugly) to have a config file in which the user could indicate the resolution (in dpi) of the monitor they have hooked up. -- Chan Benson HP Fort Collins
rxb@ASC.SLB.COM (Rafael Bracho) (12/30/89)
Re: doc%jalapeno.UUCP%fajita.UUCP@suntan.West.Sun.COM (Tom Dockery)'s
message
>The answer is somewhat simple: it's rather difficult to scale everything
>appropriately to handle differing device densities if your have no way
>of determining those densities. As most (though certainly not all)
>monitors do not have any provisio for providing this information to the
>framebuffer (and most framebuffers wouldnt know what to do with it anyway),
>certain assumptions have to be made about the attached devices in advance.
>In our shop, we regularly swap 16 and 19 inch color monitors around. On
>a Sun cg-3 these both have a resolution of 1152 X 900; this means the 16
>inch monitor has a higher density of pixels per unit measure in either
>dimension than the 19 inch.
I agree with you in that it's impossible to find out actual monitor
size. I still agree with Peter's original message in that the server
should change the default matrix between an 1152 x 900 and a 1600 x 1280
framebuffers, so the same PostScript program should produce the same
sized windows, on the same size monitors, regardless of framebuffer
resolution.
>The basic unit of measure in PostScript is the point, 1/72 of an inch; not
>too metric, to be sure, but having a basis in the printing industry. If
>the PostScript (or NeWS) programmer knows, or can query, the density of
>the device to be driven, s/he can transform everything accordingly, so that
>the same PS source prints to the same result on a 300 or 900 dpi printer.
>The higher density printer then simply provides just that. If the
>programmer can neither know in advance, nor find out a run-time by query
>the density of the output device, however, s/he faces a quandry. There
>is no real way, short of modifying the hardware, to solve the problem in a
>device independent way ...
I must disagree with you. The same PostScript source will produce the
same output, without any resolution inquiries, providing the interpreter
sets the default transformation matrix such that the default coordinate
system is still 1/72's of an inch per unit (not quite points, but close
enough). Thus the program:
gsave
0 setgray
/Helvetica findfont 14 scalefont setfont
144 144 scale
1 1 translate
(Hello there!) show
showpage
grestore
will produce a page with the string "Hello there!" in 14 point
Helvetica, 2 inches above and 2 inches to the right of the lower left
corner, *independently* of the printer's resolution.
Note that it is possible to get in trouble by using 'setmatrix' instead
of 'translate' and 'scale', particularly if one is not careful.
Rafael Bracho
rxb@asc.slb.com