[FFmpeg-user] drawtext, suggestion for improvement

[Ted Park]

Hi,

> On Mar 27, 2020, at 17:58, Reino Wijnsma <rwijnsma at xs4all.nl> wrote:
> 
> Hello Michael,
> 
> On 2020-03-26T20:28:02+0100, Michael Koch <astroelectronic at t-online.de> wrote:
>> How to reproduce:
>> Use Windows Notepad to create a UTF-8 text file which contains only the word "test".
>> This is how the file looks in a hex editor:
>> EF BB BF 74 65 73 74
>> 
>> Now run this command line and have a look at the output image.
>> 
>> C:\Users\mKoch\Desktop>c:\ffmpeg\ffmpeg -f lavfi -i color=c=white -vf drawtext=textfile=test.txt -frames 1 -y out.png
>> ffmpeg version git-2020-03-23-ba698a2 Copyright (c) 2000-2020 the FFmpeg developers
>>  built with gcc 9.2.1 (GCC) 20200122
>>  [...]
> Your FFmpeg binary looks very recent, but what about the FontConfig library you compiled this FFmpeg binary with?
> 
> I was only able to reproduce this with one of the very first FFmpeg binaries I compiled myself (N-86393, dated 2017-06-06 and compiled with FontConfig 2.12.1).
> The next FFmpeg binary I compiled (N-86763, dated 2017-07-12 and compiled with FontConfig 2.12.4), and all that come after it, don't show this behavior.
> 
> I think updating FontConfig (and recompiling FFmpeg) would most likely solve your problem.
> 
> -- Reino
> 

That is bizarre, is there no way to change that behavior (in Notepad?) A byte order mark in UTF-8 is a bit confounding, I wonder if there is some history behind it.

Manually entering the code point in a UTF-8 document goes so far as to crash the character viewer pane on my Mac, I’ll have to test on more. In the drawtext filter it seems to depend on the actual font and its glyph table, some of them render it as literally a “zero-width nonbreaking space” which is indistinguishable to it not being there and some fonts do the missing glyph box thing.

Regards,
Ted Park