Thread: [java-gnome-hackers] Layout size related methods
Brought to you by:
afcowie
|
From: Andrew C. <an...@op...> - 2008-09-16 07:15:17
|
Vreixo,
I've been working on the 'pango' branch. I'd like to include it in 4.0.9
as it nicely complements the 'textview' work.
I'm a bit concerned about the size related methods in Layout. I've taken
an number of different cracks at it, and now I've got it to:
getSizeWidth()
getSizeHeight()
and
getPixelWidth()
getPixelHeight()
which seems to be a fairly decent stab at regularizing the completion
space. Still, I'm not 100% about it.
Part of my doubt is that now that we've got these normalized, these
methods now seem to return the same thing - just the sort of thing to
make me somewhat unconvinced that we actually need both pairs. That
said, it is probably best we leave both sets there - there is return
type to be considered.
The real issue, of course, is *explaining* what the difference is, and
that's where I got a bit vague. I have a hunch that it is the whole
points vs device units vs pixels thing that I'm getting confused by.
And, of course, just to spice things up, none of these have anything to
do with Layout's setWidth() but its probably best to leave that one
alone too [I am tempted by setWrapWidth()]. For now I added some extra
emphasis to its documentation in an attempt to make things clear.
My work (building on yours) is at 'hackers/andrew/pango'.
AfC
Sydney
|
|
From: Owen T. <ot...@re...> - 2008-09-16 09:10:17
|
On Wed, 2008-09-17 at 00:15 +1000, Andrew Cowie wrote:
> Vreixo,
>
> I've been working on the 'pango' branch. I'd like to include it in 4.0.9
> as it nicely complements the 'textview' work.
>
> I'm a bit concerned about the size related methods in Layout. I've taken
> an number of different cracks at it, and now I've got it to:
>
> getSizeWidth()
> getSizeHeight()
>
> and
>
> getPixelWidth()
> getPixelHeight()
>
> which seems to be a fairly decent stab at regularizing the completion
> space. Still, I'm not 100% about it.
>
> Part of my doubt is that now that we've got these normalized, these
> methods now seem to return the same thing - just the sort of thing to
> make me somewhat unconvinced that we actually need both pairs. That
> said, it is probably best we leave both sets there - there is return
> type to be considered.
>
> The real issue, of course, is *explaining* what the difference is, and
> that's where I got a bit vague. I have a hunch that it is the whole
> points vs device units vs pixels thing that I'm getting confused by.
Without looking at your code, it's hard for me to say where you are
getting confused. Some points that may be helpful.
* All functions to get size and metrics in Pango work in the same
coordinate space. This coordinate space is equivalent to the cairo
user space. If you haven't made any transformations, then this
coordinate space has units of pixels.
* Lengths are usually in fixed point 22.10 format. (Called "pango
units.) In C, you interconvert
pixel_length = PANGO_PIXELS(length) // also PANGO_PIXELS_FLOOR/CEIL
length = pixel_length * PANGO_SCALE
* It's a frequent operation to want extents *in integer pixels*;
doing the rounding properly round a fixed point rectangle to the
small enclosing integer pixels is slightly tricky, and something
you commonly want todo so there are functions like
pango_extents_to_pixels() pango_layout_get_pixel_extents()
pango_layout_get_pixel_size()
E.g., if you have a rectangle with x = 0.9 width = 5.2, the pixel
width is not 5 (rounded) or 6 (ceiling), it's 7.
How does this map to Java? It's partly a question about how much you are
deviating from the Pango API. If you want to stick close, all you need
is break get_extents() into:
Rectangle getInkRectangle()
Rectangle getLogicalRectangle()
And on Rectangle have:
Rectangle toPixels()
int getX()/getY()/getWidth()/getHeight()
That's complete in terms of mapping all of
pango_layout_get_[size/pixel_size/extents/pixel_extents]. Beyond that,
you might want to add for layout:
getPixelWidth()/getPixelHeight()
As convenience functions. I'm not sure that getSizeWidth()/getSizeHeight()
are necessary. Ugly names...
- Owen
|
|
From: Andrew C. <an...@op...> - 2008-09-25 01:48:50
|
On Tue, 2008-09-16 at 11:46 -0400, Owen Taylor wrote:
> Without looking at your code, it's hard for me to say where you are
> getting confused. Some points that may be helpful.
I replied quickly to Owen thanking him for his input. Furthermore this
background info was fantastic and really helpful.
Before delving into the specifics, I just wanted to quickly write the
part that was implicit in the work that Vreixo and I have been doing,
but perhaps missing from this thread.
The path we've been following is the following:
* Drawing is done with Cairo (and indeed the only drawing API
we're interested in).
* While there is a "toy" font API in Cairo, real text rendering in
GNOME is done with Pango, of course (and so, again that's what
we have chosen to expose for when you need to write text when
doing manual drawing).
From there, someone made the observation that when you're busy drawing
away with Cairo in an Widget.ExposeEvent handler, it seemed *really*
awkward to have to keep switching from the doubles that you're working
in with Cairo the the huge fixed point ints that you have to feed Pango
functions.
So, it wasn't a huge leap for suggest that we normalize the Pango
methods to be in the same units as the rest of one's Cairo drawing. I
liked that idea very much, and it certainly made the test code I was
trying all this out with look *WAY* nicer. So, {shrug} away we went.
Owen wrote,
> How does this map to Java? It's partly a question about how much you are
> deviating from the Pango API. If you want to stick close...
So, really, it wasn't about sticking to the underlying API (which we
otherwise do rather rigorously modulo the stylistic things we have
adopted to make completion spaces better, type safety, etc) as it was
trying to make the overall drawing experience a bit more coherent.
I think I'll stop there; if people want to bitch they can, but that's
the direction we were heading. It seemed to make good sense. Meanwhile
I'm going to re-read what Owen wrote and see how that information
illuminates what we were doing.
People who are actually using java-gnome (and especially doing any
drawing) are welcome to chime in.
AfC
Sydney
|