Re: Coordinate system

[BALATON Zoltan]

Hello,

On Thu, 1 May 2003, Alexander Malmberg wrote:
> Stefan Urbanek wrote:
> > I am confused. What is the coordinate system for drawing
> > in gnustep? Is it pixels or points? Or is it pixels on screen
> > and points on PostScript output?
>
> Points, always. ((Well, the default matrix is such that one unit in user
> space is one point; you can change this so one unit is one mm, or one
> meter, or anything else that you can get as a multiple of a point. 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

> All(?) current backends assume that the display is 72dpi, so that 1
> pixel==1 point, but this is an implementation limitation. back-art has

Or they implement the OPENSTEP behaviour of windowdeviceround by assuming
72 dpi.

> no problems rendering at other resolutions, but we'd still need to fix
> back/Source/x11/* to convert sizes and coordinates of events and windows
> between points and pixels.

Same for the gslib backend. (Yes, I'm still alive and intend to work on
it, but it seems I had no time for a while now.) I've asked before if we
should switch the default unit to points for device independence, but
because of limitations in other backends and matching OPENSTEP behaviour
it was decided to use pixels for now. It would be also interesting to know
what default units MacOSX uses.

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.

> [snip]
> > Another problem should be drawing between pixels, but this can
> > be solved by rounding to integer values in backend.
>
> 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, fonts are still not straitforward though (if you also want both
performance and being able to print them correctly on paper).

Regards,
BALATON Zoltan