Posibility to enhance FontMetrics?

[laeubi]

I'm currently in the situation of computing some size of text, and stumbled about SWT FontMetrics but it only offers very general information, also a lot of helper functions are used around the place e.g. in SWT to do some guesswork.

Looking at the AWT FontMetrics I used in the "swing days" it offers much more advanced function especially getStringBounds and a like what in SWT is somehow connected to the GC object... So I wonder if there is a possibility to enhance SWT FontMetrics in a similar way (e.g. working on the FontData) that does not require a full GC object?

[akurtakov]

The major roadblock to enhancing SWT's API has always been the fact that one has to implement the new API with 3 different WSs - win32, gtk and cocoa. Finding someone that can do it for all 3 happens to be close to impossible task but the other option (organizing different people to implement it for different WSs) is not easier unfortunately.
Now to the specific issue - Font's have their properties measured in pts and in order to get "real" StringBounds a GC is needed in order as it gives a physical meaning to pt depending on the GC's scale and etc. Even AWT's FontMetrics.getStringBounds takes Graphics as a parameter for the same reasons I would guess.
So short answer - There is no technical reason to not implement it but the GC requirement would have to stay . Drawable could probably be enough if enhanced so Display.getCurrent/getDefault could be passed but that might put too much requirements on Printer(or other Device children).

[laeubi]

A FontMetrics is currently created from a GC (and then seem to be safe to share) at laest that is what I see in a lot of JFace code e.g. org.eclipse.jface.dialogs.Dialog.convertHorizontalDLUsToPixels(FontMetrics, int) and FontMetrics seems to be a "shared" class so I was hoping there might be a chance to add some things (e.g. the convertXXXX method) in a system independent way.

[akurtakov]

Well, these convert* methods are for "illustrative purposes" to allow the Dialog's to have some OKish sizes for widgets but they rely on things like average char width, (max) height and etc. which makes it OK for "layouting" purposes but in no way fine for getting "real" String bounds. Just think about strings that contain mostly letters that are usually above the average width (like m, w, ш, щ, etc.) and your bounds would not fit the string horisontally and vice versa (mostly i, j, l) and you'll get a lot of empty space in one of the ends horisontally. And if you think of newer fonts with ligatures things become even more unpredictable if one doesn't do exact calculation based on the actual text renderer.