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 |