bug#14233: 24.3; Don't constrain frame size to character multiples

[martin rudalics <rudalics@gmx.at>]

 >> ** Remove the limitation that window and frame widths and heights can
 >>   be only full columns/lines.
 >
 > Right.  And I don't think the wording of the problem in both cases is
 > accurate enough.  There is no such limitation, except in functions
 > that actually resize the frame/window.  The display engine doesn't
 > require integral number of character cells.
 >
 > So, if someone wants to bite the bullet, the way to go is:
 >
 >   . introduce interfaces to specify frame/window size in pixels

I'm mostly done with the low-level parts of the implementation.  What
might be lacking is a better interface specification.  So far I have:

- An option `frame-resize-pixelwise' which, when non-nil, passes resize
   requests from the window manager pixelwise to the frame and window
   resizing routines.

- An option `window-resize-pixelwise' which, when non-nil, makes some
   window resize functions (like `adjust-window-trailing-edge' or
   `fit-window-to-buffer') operate pixelwise.

- Functions like `window-resize', `split-window' or `set-frame-size'
   take an optional argument PIXELWISE which means to interpret their
   size/delta/width/height argument pixelwise.

Some issues still deserve discussion:

- The window resize routines work pixelwise although when resizing I
   still try to preserve full lines/columns first and give the remainder
   to one window only.  That is, if I have three windows and 90 pixels
   height to distribute, by default I assign 32, 32 and 26 pixels instead
   of 30 pixels to each.  If you prefer a different solution tell me - I
   have no strong opinion here.

- We currently include a frame's fringe widths and scroll bar widths in
   the frame's pixel width but not in the frame's text width.  This is
   very inconvenient on graphic systems and leads to all sorts of subtle
   bugs like bug#14222.  Do we really care about this distinction or
   could we simply say that specifying a frame's width specifies also the
   width of that frame's root window (minus the internal border width)?

- IIUC we currently do not allow to specify the sizes of display margins
   pixelwise.  Are we interested in lifting this restriction?  We would
   have to invent suitable terms for these.

- We currently round fringe widths (in compute_fringe_widths) and scroll
   bar widths (in x_set_scroll_bar_width) to columns.  Is this still
   desirable or shall this be lifted too?

- The heights of the tool and menubar are specified in lines.  Do we
   intend to change that to pixels?

 >   . in the implementation of those interfaces, round up the sizes in
 >     column and line units to the integral numbers, so that the glyph
 >     matrices are large enough

I tried to do that.  Usually, the display routines are so robust that
hardly anything could ever break them.

martin