Btw: the file_ops.c has not been changed - I'll omit whitespace changes before committing...

Will address all issues this evening, especially the "thumbnails" comment - didn't try that yet. In this view it would be possibly even better to increase the font drawing size too.

Is "structs first" in our coding guidelines? I was always trying to group parameters logical but it's no problem to rearrange them ;)

Mind having a final look, Bastien?

So, just to give all followers a status on this topic. Mont and me discussed it in IRC now and I agree with Mont on both points (it's a hack and it should work for the complete fonts list). Therefore I bite the bullet and implement it - but this time the right way. News will follow next weekend (2015-02-01)..

Campbell, would also like your opinion here. :)

Hi Cambell, will change the patch accordingly when I process all the other things. Thanks for the heads up - I agree with you about the BLF_* not having to know about the ImBuf.

Hi @Campbell Barton (campbellbarton),

I'm just processing all points and got a question concerning freeing the BLF_* from my preview generation method.

The problem
As I understood your comment, I should only use the high level BLF_ methods to create a font (get a fontid), draw the preview and free the font again. This introduces one major problem because we're creating the thumbnails in a threading manner. As there are many forks processing different font previews at the same time, the global_font[ ] is filled rapidly (currently only 16 max) even though I unload the font after the preview.

Possible fixes

• Use the internal methods from blf_font inside my previous generation method (moved to filesel.c) but then I would have to include blf_internal.h and blf_internal_types.h (which I find is nonsense architecture wise). OR
• Increase the global_font[ ] size to a much bigger size (in my folder are at least 300 fonts processed OR
• We leave the method internal to blf_font and let all the magic happen there.

What's your opinion about that? Which route should I take to stay safe architecture wise...?

I didn't push my current diff yet because I don't want to push a version that does not work but if you want to see the problems just look there... http://www.pasteall.org/57632/diff

@Thomas Beck (plasmasolutions), okay, this is a bit more involved re: threading.

We could go about this, considered both these options.

Expose the API (partially)

Expose a part of the BLF api that loads fonts (parts of blf_internal.h, probably under a new API), Would want to keep the FontBLF struct opaque, but we could at least expose some of the functions which act on it.

Extend the API

Add a new function for font drawing which loads the font, draws and frees it. eg

BLF_draw_buffer_fontfile(..., const char *fontfile, int (draw_callback)(...), void *user_data)

This has the advantage that the changes to the API are isolated to a single function, and it can be reused in different places.

psudocode

void BLF_draw_buffer_fontfile(
        buffer info, const char *fontfile, ...,
        draw_callback, void *user_data)
{
    load font;

    BLFDrawData draw_data;

    while (draw_callback(&draw_data, user_data)) {
        draw font using draw data;  /* string, position, color... etc */
    }


    free font;
}

This way you would just have to define a callback which draws the preview and pass it to BLF_draw_buffer_fontfile,
This isn't really such a big task, the function would likely be <50 lines.

Committed rB8c539b0ab521d442d88c70243c04cbb9e40fe412

Made some changes...

• There is one necessary bad level call from (IMB -> BLF), (going from IMB -> ED is worse really), isolated code and marked the bad level call into a single file.
• Replace byte buffer with float.
• Image had artifacts at the edges from drawing onto black-alpha. (fill the image [1,1,1,0] to avoid).
• Change preview text to be more generic.
• Preview method now scales (so generating larger thumbnails is supported). - can request 512x512 image for eg, font size scales up to match.

Great work guys! I noticed it also supports preview for complex fonts like Chinese, Japanese and Korea, which is really cool. However, the preview text seems always be English. IMHO, for such fonts, it would make much more sense to use localized characters or symbols. I wonder if it would be possible, too?

Current display in BI:

Example in winOS:

Hi @Leon Cheung (leon_cheung),

that's right - atm it's a hardcoded string. In the future I plan to support much more like sorting by font styles, a user definable preview text, and so on. But that's a topic after Bastians asset-experiments and therefore part of a completely new patch.

Greetings, Thomas

Ah I see. Thanks for the information. :D

These strings could go via translations too, it should only be a minor change.

Added translations here (rBf75bbe27e23d2f794).

Note currently only for french & japanese (as test cases), next update of PO's will add it for everybody (once translated of course).
Also, following Blender's approach to completely ignore i18n stuff when disabled, you have to enable translations to get it working (can still have everything in UI in English by disabling label & tooltips translations though).