gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coordinate system


From: Alexander Malmberg
Subject: Re: Coordinate system
Date: Sat, 03 May 2003 23:00:36 +0200

BALATON Zoltan wrote:
> > There
> > is no way to get at device pixels through the dps interface.))
> 
> This is not true on OPENSTEP. Look at the description of the windowdevice
> and windowdeviceround operators at
> http://www.toodarkpark.org/computers/objc/AppKit/Functions/PSOperators.html

Well, that's true, but we don't have windowdeviceround. :)

I'll adjust my statement a bit: There is currently no way to get a
device pixels through our dps interface. The exceptions would be
specialized operators for setting a device-pixel matrix, or for
extracting raw image data from a window; nothing -gui should normally
do.

[snip]
> To implement DPSwindowdevice a way to get the resolution from the server
> (back/Source/x11) would also be nice if it is not possible yet. Ideally
> the graphics part should not depend on X functions.

I'm not sure the dpi settings returned by X can always be trusted, and
you might want to override them, so I'd suggest a defaults key for
setting it, falling back to what X says if it isn't set.

Also, I'm not sure calling it a dpi setting is the best solution.
Effectively, it is a way of scaling the entire interface, and it isn't
purely a function of the dpi of the output device (eg. if you have
reduced sight).

[snip]
> > Handling this is up to the backend. back-art can do (and, currently,
> > always does) subpixel rendering. When clarity is more important than
> > accurate rendering, you use strokeadjust (not implemented in back-art)
> > and screen fonts (implemented in back-art).
> 
> strokeadjust is supported by ghostscript so it is easy in the gslib
> backend,

For back-art, I plan on using strokeadjust as a general hint to make
things clear and crisp at the cost of accuracy. With lots of
antialiasing and very low resolutions, plain strokeadjust (at least in
the form I've read about) isn't as applicable, but other tricks are (and
some I already apply unconditionally, like trying to line up dashes with
device pixels so the dashes focus rectangles on views don't turn into a
gray anti-aliased mess).

> fonts are still not straitforward though (if you also want both
> performance and being able to print them correctly on paper).

No, but we have a solution, and implementing it is, at least
conceptually, straightforward.

- Alexander Malmberg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]