Re: [ft] How to get nominal width of monospaced fonts

[Sam Varshavchik]

Werner LEMBERG writes:

> Just checking the terminology: There are three steps that are
> necessary to transfer the font file data to the screen.
>
>   (1) Reading global font data → FT_New_Face
>   (2) Loading and (optionally) hinting a single glyph → FT_Load_Glyph
>       (without using FT_LOAD_RENDER)
>   (3) Converting the vector outline to a bitmap (a.k.a. `rendering')
>       → FT_Render_Glyph
>
> Steps (1) and (2) are necessary to get the information you need; step
> (3) is optional and doesn't change any metrics data.  So the answer to
> your question is: Yes, you don't need to render a glyph to get the
> advance width.  However, it must be loaded, and optionally hinted.

Sometimes there's step 0: calculate the dimensions on the screen for the  
rendered font, in advance. Let's say you're working with a monospaced font,  
and you want to compute the rendering area for X characters, say 20  
characters. Given that it's a monospaced font, it should be possible to  
determine that beforehand, then you have an area where you can render up to  
20 characters.

> > I was seeing differences that were more than two pixels.  I would
> > think that hinting-related differences would not translate to more
> > than a pixel's worth of a difference.
>
> Please prepare exact numbers.  Which font, which glyph, which ppem,
> etc., etc.  You might compile FreeType statically with debugging
> output (doing `make devel; make' without calling the `configure'
> script), then setting the `FT2_DEBUG' variable as described in
> `docs/DEBUG'.  This should give you plenty of information that
> probably helps us locate and explain the issue.

I'm going to look at it. But I can tell you that it's a stock liberation  
mono font. After opening in, with FT_New_Face() and using  
FT_Set_Pixel_Sizes() specifying no (0) width, and a specific height value,  
when the specific pixel height value exceeded either 21 or 23 pixels (I  
forget at the moment), the difference between max_advance and the individual  
glyphs' advances exceeded 2 pixels.

> > That pretty much answers my question.  In the interim, I am using a
> > heuristic approach of loading a sample set of glyphs from each face,
> > and averaging out their advance.
>
> For a monospaced font?

Yes. This is for a widget toolkit I'm working on. I want an input field  
that's "n" characters wide, and that's how I compute the widget's actual  
pixel size. I find that with this approach, and when using a monospaced font  
for displaying the typed-in text, the results are as expected. I can type up  
to n-1 characters in it (leaving one more for the cursor), incrementally,  
before I end up scrolling it.

This also works reasonably well with variable-spaced fonts as well, to set  
the requested width of the input field to a value that's decsribed as being  
the number of characters. The actual number of characters that can be typed  
in without scrolling will vary, of course.

pgp8avN6meSOX.pgp
Description: PGP signature