sylvain.bertr...@gmail.com writes:
On Wed, May 22, 2019 at 07:23:02AM -0400, Sam Varshavchik wrote: > > For a monospaced font? > > Yes. This is for a widget toolkit I'm working on.Hi, please bear with me to pop in like that in this thread. A widget toolkit? Interesting, will it be open source? (x11? wayland? evil WSIs?)
Yes, GPL3, and X11, with a C++17 API. Currently Linux only, uses some kernel- specific APIs.
https://www.libcxx.org/w
I guess your text widgets (edit and display) are targeting unicode roman scripts?
Unicode-based, but should work with all scripts, and supports XIM; at least it seems to work with ibus (using X11 transport). By randomly hitting keys I could type and edit East Asian ideograms. fontconfig tells me which font files have which Unicode characters, and Freetype gets summoned to open the appropriate true type font file.
Anyway, I can't prove it, but I'm pretty sure that using a font's max_advance worked at some point, before. I don't know what changed, whether something in Freetype or in the true type font files.
Specifically: using using max_advance to compute the number of pixels, in advance, that's needed for rendering a specific number of characters from monospaced fonts. I always used to do this for monospaced fonts, before. And I got the expected results. Multiply max_advance by 20, and that's exactly how much it took to render 20 characters, before scrolling. No more, no less. And for variable-spaced fonts I used the heuristic of calculating the average advance from a sample set of characters in the font. I found that max_advance was typically too big, by several times, than a typical character from the variable-spaced font. The widest character in the font was probably much wider than a typical one (that was my guess) and using the average instead of max advance gave me acceptable results. Multiply the average by 20, and I get something that turns out to be wide enough for twenty or so characters, give or take a few.
But recently, after writing some more sample code, I found that even a monospaced font was now giving me input fields that were too wide, and I eventually tracked this down to max_advance being one or two pixels too large. So with only a 20-character field, I'm already too big by one character. But because I was already computing an average advance for most fonts, I switched to computing the average advance with monospaced fonts too, and I'm now back to getting a pixel-exact value needed to render a specific number of characters. I think I will add a test that will tell me if this stops working, in the future.
pgpRnatQU0G4u.pgp
Description: PGP signature
_______________________________________________ Freetype mailing list Freetype@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype
