Text: support font widths >16

[Reel-Deal]

As mentioned in issue #308. BDF fonts with a width >16 are not rendered properly. For testing purposes, here are some fonts that come in sizes >16.

Spleen (32) : https://github.com/fcambus/spleen
HaxorNarrow (17, 18): https://github.com/metan-ucw/fonts

[pinterf]

Thanks for the samples. Spleen-32x64 works, but the HaxorNarrow ones are not displayed properly, even for size 15.

[Reel-Deal]

That's odd. I just checked with FreeSub and it works:

Blankclip()
FreeSub("TEST", font="HaxorNarrow-15.bdf")

[pinterf]

They seem to be not fixed size fonts. E.g. the exclamation mark (!) is defined only on width=1 (and not drawn in the middle of a 8 pixel wide area). The quotation mark is defined by a x=7 y=4 box, etc.. My (not so sophisticated) BDF loader assumes that the global character box is valid for all other characters. The boudinx box sizes are different in this font type for almost all characters. So it's a limitation, and I'd like to implement more from the BDF standard, but it's highly unlike to implement non-fixed size display.

[pinterf]

Nice :( Ubuntu 18.04 build failed with internal compiler error ?!

/home/runner/work/AviSynthPlus/AviSynthPlus/avs_core/core/info.cpp:1338:28: internal compiler error: in finish_member_declaration, at cp/semantics.c:3029
       fontline = fonts[num * FONT_HEIGHT + ty] << xstart; // shift some pixels if leftmost is chopped
                        ~~~~^~~~~~~~~~~~~

I have to do some workaround or reorganization of source then...

[Reel-Deal]

They seem to be not fixed size fonts. E.g. the exclamation mark (!) is defined only on width=1 (and not drawn in the middle of a 8 pixel wide area). The quotation mark is defined by a x=7 y=4 box, etc...

Thanks for the info, I did not know that about bdf fonts. I only linked to that specific font because it sizes >16 which are not so common to find.

Would it be possible to detect those fonts and error out with a message like "non fixed size fonts are not supported" rather than just not rendering properly?

[pinterf]

Actually, they were fixed sized fonts but defined in a tricky way which I did not implement originally.

And yes, I'm gonna put those font size warning, but first of all, the actual rendering core is so inefficient after recent feature additions that I must rewrite it. That would probably result in that the size limitation could even be omitted.

[Reel-Deal]

Wow pinterf you went all out on this filter. Very little left of what it used to be :)

I'll leave the issue open for now and test it whenever there's a new test version. I have a few other minor bugs to report also.

[pinterf]

Since I forgot to mention this issue number in the commit texts, here are the commits: 1653e64 and 6559f4e.

One thing left (which is now a lot easier to achieve): honor the original chroma location e.g. top_left for 4:2:0, or left (mpeg2) for 4:2:2.
Presently the easiest and quickest one "center" is implemented.

[Reel-Deal]

Oh nice, so a new chroma placement parameter for Text or will it be hardcoded?

[pinterf]

It could be read from frame properties, or a "placement" parameter.
I won't support all combinations, but "left" (mpeg2) is relatively easy to implement. Unlike "top_left" for 420.
I remember Layer only to support mpeg1 (center) and mpeg2 (left) through its "placement" parameter.
I think, if implemented, mpeg2 (left) would be the default for 422, "center" is good for 420.

[Reel-Deal]

I don't think anyone would complain if left is default for both 420 and 422 since almost all (except uhd blurays) consumer video use left.

[pinterf]

placement: started a new issue #328

[pinterf]

Finally implemented via commits 1653e64 and 6559f4e. Max. 32 pixel width of my first implementation is no longer a limiting factor.