[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

3471.0. "$VIEW/FORM=PS don't work (VMS 5.4)" by NBOFS1::HERMANN (SMService PHILIPS-Nuernberg) Tue Oct 16 1990 07:52

    Since VMS V5.4 (DECwindows 2.1) a new item in the /FORMAT switch
    is available (PS) with the DCL VIEW command.
    
    Our customer uses a VT1200 Terminal (Firmware V2.0) and wants to
    take a look with the Postscript Previewer to his postscript file.
    
    The big view window appears on the VT1200 Terminal and in the mid-
    dle of the window there came following error message:
    
    (Command entered on the Client:)
    
    $ VIEW / FORMAT = PS / INTERFACE = DECWINDOWS filename.PS
             
    	  **** Server don't have Postscript Extension  ****
          
    The same error if we enable the Remote Session Manager on the 
    VT1200.
    
    I got following statement from the VT1200 Product Management:
    
    - This is not problem of the VT1200, it's a problem of the current
      VMS or DECwindows Version.
    
    Who knows at which time the customer is able to use the Postscript
    Previewer as  promised ?
    
    Regards.
    Hermann

T.R	Title	User	Personal Name	Date	Lines
3471.1	Need support in vt1200 rom and contract with adobe	STAR::BMATTHEWS		`Tue Oct 16 1990 09:04`	10
	Display postscript is implemented as a server extension. That is the code to process display postscirpt most be in the display server for CDA to display postscript. In your case that is the vt1200. Ulrtix and VMS workstations have display postscript support in their display servers. I believe VIPS and PCSG are looking into adding display postscript to their servers and are trying to negotiate contracts with adobe. VMS and ULTRIX have to pay royalties to adobe for every VMS and ULTRIX workstation that is capable of displaying postscript. Bill
3471.2	Extensions are bonuses - what about client side support?	LENO::GRIER	mjg's holistic computing agency	`Tue Oct 16 1990 19:29`	20
	Extensions are supposed to be treated as wondrous, blessed events in X, with the client depending upon a fallback scheme if the extension isn't present. Rather like server-side fonts being found or allocations succeeding - don't depend on them to work if you're writing a well behaved client. Doesn't this say that we should have client-side postscript interpretation code which can detect upon connection to a server whether the server is capable of handling the PS directly or if the client should handle it? The dps extension looks really neat, but I'm worried if we start writing applications which really start using it, when many of the X terminals (at least for the next few generations) won't have dps. Or are we just not worried about interoperability?? (low blow, but let's face it, the world of interoperability and portability is lowest-common-denominator software development, and value-added stuff like dps is nice, but unless we can handle it not being there, we're not following the spirit, if not the letter of the interoperability goals of X windows.) -mjg
3471.3		DECWIN::FISHER	I like my species the way it is" "A narrow view...	`Wed Oct 17 1990 13:53`	11
	You are right. Talk to product management. In addition, in terms of common denominators, the following workstations all support Display PostScript: DEC IBM (also their X terminals) NeXT (DPS clients, not XDPS) Silicon Graphics (recently announced) Burns
3471.4	`Sorry' is a reasonable fallback in my opinion	CVG::PETTENGILL	mulp	`Wed Oct 17 1990 19:42`	20
	It is certainly very important for our products to provide more support for extensions than the rest of the market as long as these extensions are defacto standard. If we generally provide 80% of the extensions while the average product only provides 50%, then we have a competitive advantage. Clearly we don't want to make our products appear proprietary by supporting extensions that aren't commonly implemented and then making them critical to operation of many applications. And you must expect that extensions will in many cases cost real money for the customer. No matter where you put it, Adobe is going to charge for PostScript support, but the customer may very reasonably refuse to pay for it. (If you have looked at the quality of PostScript output on a 75 dpi display, I'm sure that you can understand this position: it is often unusable.) If the X Window market expands to the point that many people are moving from MS Windows, then perhaps MicroSoft would develop some sort of support environment that would allow Windows applications to be run on X Window systems without modification. Whether this was pure client software or a mix of client and server extensions, MicroSoft would obviously demand a royalty, yet many X Window users wouldn't care a bit about this support.
3471.5		DECWIN::FISHER	I like my species the way it is" "A narrow view...	`Thu Oct 18 1990 17:34`	9
	Try looking at a .PS file under DECwindows V3 when it is available. You should find it much better. (We are now matching up the font requested with DECwindows fonts, so that if you ask for a size and orientation that we have, we will use the hand-tuned bitmap fonts.) In addition, Adobe is in the process of producing code (derived from ATM, I understand) which generates much better glyphs at low res. Burns