[comp.windows.news] Scaleing in NeWS

hugh@hoptoad.uucp (Hugh Daniel) (12/31/89)

  There is a simple solution to the problem of the current batch
of moniters not being able to tell the OS what there DPI is.  Simpley
use a enviornment variable, say setenv DPI display1=72,display2=116
or some such rot.  This even lets users change the dpi on there screens
to say, make EVERYTHING look bigger.
  Of cource the problems with this is that all of Sun's code is dependent
on screen size, as in the File Manager's waste basket which comes up
in the middle of a 1600x1200 screen (a XView app., but the same is true
of Suns NDE (no more name changes...) toolkit).
  Also, with the low res of the screens Sun (and theire non Compeditors)
use (say, screens with less the 2kx2k and less then 4 bits deep) one has
to go to a LOT of work to get PostScript glyphs to look right, which has
not been done.  The alturnitive is to define everything by Pixels, which
the last rev. that I saw of the Open Look spec. is back to using.  This
also is a lot of work, but the short term advantage is that at one dpi
things look right, of cource next month when the next higher res. screen
comes in someone gets to do all that work again...

                ||ugh Daniel
hugh@toad.com                   Grasshopper  Group,   +1 415/668-5998
hugh@xanadu.com			210 Clayton St. San Francisco CA94117

montnaro@spyder.crd.ge.com (Skip Montanaro) (01/01/90)

In article <9443@hoptoad.uucp> hugh@hoptoad.uucp (Hugh Daniel) writes:

 There is a simple solution to the problem of the current batch of moniters
 not being able to tell the OS what there DPI is.  Simpley use a enviornment
 variable, say setenv DPI display1=72,display2=116 or some such rot.  This
 even lets users change the dpi on there screens to say, make EVERYTHING look
 bigger.

It seems to me that enhancing the console entry in the eeprom or adding one
or more screen entries with DPI information would be a more permanent
solution. After all, the resolution of the screen isn't likely to change with
each user. I agree the user should be able to override this info, however,
in a manner as Hugh suggests.

--
Skip (montanaro@crdgw1.ge.com)