Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Precise font metrics

Hi,

> For that to work, besides adding floating precision to font metrics, we 
> would also need to add floating precision all other graphics. Agreed ?

No, that's not necessary except for an alternative glyph positioning/rendering mode.

> I mean, how good is to able to measure the height of line in floating 
> precision if you won't be able to draw the next line at some floating 
> point location.

If you look closely at the text rendering in other packages, you will notice that they don't usually position text at subpixel precision in the Y-direction. I am assuming that this is ok because usually, there is enough distance between lines to get away with rounding and the rendering looks much crisper and consistent. For my problem concerning the line offsets, it would be enough if the error didn't accumulate until the end of the page, as is the case now.

However, for horizontal glyph positioning, you are right. There would need to be the option to support subpixel positioning. Many graphics APIs allow to specify a glyph positioning mode to the rendering engine. Sometimes this is called "char spacing" versus "string spacing" (but sometimes that means kerning on/off). Swing calls it fractional positioning, for example. I believe that all native backends that SWT supports would support such a toggle.

> As you can imagine, that would be a big work.

I am thinking only the FontMetrics could be extended and GC could have an additional text anti-aliasing mode. It is already an int, not a boolean. So the API would change minimally, while I am sure there would be a lot of work in the backends. The code I have glimpsed (GTK) uses hard coded font rendering setup in many places.

> Anyhow, the problem you are having is that your editor shows less lines 
> that some other editor (given the same text, font, client area) ? Is that 
> right ?

Well yes, that is one problem. What is a total mystery to me is how exactly SWT arrives at a certain *pixel* size of a font, when I request a certain *point* size. If we are talking float to int rounding, the difference in line height should not be more than one pixel per line, or perhaps 3 pixels maximum if ascent, descent and leading are each rounded up to the nearest int and the line height is simply the sum of those. But the difference I am seeing is much more than 3 pixels.

When I calculate the size of the paper in pixels, I am using the screen PPI value. This is consistent with other packages, i.e. my paper preview has the same size in onscreen pixels as other software running concurrently. But as I said, I have no idea how SWT arrives at a pixel size for a requested font point size. I had expected it to use the same principle that I am using to calculate the paper size, but I am not sure at all this is the case. Does it even apply some user configured global font scaling? How do I control this conversion to give me precisely what I intended? Any information and pointers would be greatly appreciated.

Best regards,
-Stephan


Back to the top