Bug 175998 - no textExtent() function in the Graphics class
Summary: no textExtent() function in the Graphics class
Status: REOPENED
Alias: None
Product: GEF
Classification: Tools
Component: GEF-Legacy Draw2d (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: gef-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-01 05:48 EST by Andras Varga CLA
Modified: 2007-03-22 10:36 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andras Varga CLA 2007-03-01 05:48:41 EST
Build ID: I20060512-1600

Steps To Reproduce:
See source.

More information:
There seems to be no way to obtain text size from Graphics. One must invoke textExtent() of the underlying GC object, which is error-prone (as graphics.setFont() does not immediately propagate font setting to GC, so gc.textExtent() will return bogus results unless you made a dummy graphics.drawText() first).
Comment 1 Pratik Shah CLA 2007-03-01 11:56:57 EST
Use FigureUtilities.  This bug should be resolved as invalid.
Comment 2 Anthony Hunter CLA 2007-03-01 12:05:41 EST
Use FigureUtilities for this support.
Comment 3 Andras Varga CLA 2007-03-01 15:02:09 EST
Guys, 

Are you sure this is the Right Thing to do? Force people use a workaround, instead of fixing the issue?

draw2d.Graphics wraps each and every method of GC, *except* textExtent()? What's the reason? Other than it was left out accidentally?

BTW, I just noticed there is setForegroundPattern()/setBackgroundPattern() but no getForegroundPattern()/getBackgroundPattern()...?? GC does have them.
Comment 4 Randy Hudson CLA 2007-03-01 15:17:15 EST
It was not accidental.  Text Extent is required during layout, which occurs outside of a paint, without a GC.  Also, the GC's font might not be the one you passed in, due to ScaledGraphics.
Comment 5 Andras Varga CLA 2007-03-22 06:40:10 EDT
The problem with using FigureUtilities is that it doesn't know the textAntialias setting of the Graphics I'm using, and the difference in the result can be quite significant in either direction (see URL and screenshot attachment in bug #178552). I actually got bitten by LabelFigure because of this: it shaved off some pixel columns of labels, e.g. making trailing "d" appear as "c", and "n" as "r". Perhaps this would be worth a separate bugtracker entry.

Also, I was using the Graphics class without Figures (just for raw canvas painting) for its convenience features over GC, so I'd rather invoke a textExtent() method on Graphics than using extra class.

Is there a practical difficulty involved in adding textExtent() [and other missing methods like getForegroundPattern()/getBackgroundPattern()] into Graphics?

Comment 6 Randy Hudson CLA 2007-03-22 09:42:33 EDT
> Is there a practical difficulty involved in adding textExtent()

Yes, the font passed to ScaledGraphics is not necessarily used with any GC.

> missing methods like getForegroundPattern()/getBackgroundPattern()] into
> Graphics?

Getters are easily added.

Also, the problem you mentioned with different text sizes based on usage of advanced graphics is a real problem. But, adding getTextExtent will not solve that problem.  During layout, the figure will still incorrectly answer what it's preferred size is, so even if it measured the string later, the figure's bounds won't be big enough to paint it.  I guess if you're not using Figures at all you don't have that problem.
Comment 7 Andras Varga CLA 2007-03-22 10:36:54 EDT
> Getters are easily added.

That'd be great, thanks.

> Yes, the font passed to ScaledGraphics is not necessarily used with any GC.

I'm not sure, do you mean that the Font in the localFont member of ScaledGraphics may have been created for a different Device than the underlying GC, so localfont cannot be used for measuring? 

It looks more correct to me to call textExtent with the zoomed Font not localFont, and divide the result by the zoom factor. So when the returned size gets multiplied back by the zoom factor in some later drawXXX() call, the error would be less than one zoomed pixel, which is about as good as one can hope when using zoomed graphics.