Hiltjo Posthuma <hil...@codemadness.org> writes: > On Mon, Sep 24, 2018 at 09:15:55AM +0200, Silvan Jegen wrote: >> On Mon, Sep 24, 2018 at 8:32 AM Eric Pruitt <eric.pru...@gmail.com> wrote: >> > >> > On Sun, Sep 23, 2018 at 11:19:46PM -0700, AR Garbe wrote: >> > > On 23 September 2018 at 11:56, Eric Pruitt <eric.pru...@gmail.com> wrote: >> > > > It's not just about Emoji or anti-aliasing. If you work with languages >> > > > that use non-Latin characters, support for fallback fonts is a must. >> > > >> > > Well, are you using st with glyphs that require fallback fonts? >> > > I wonder if at suckless we should aim for the general purpose. >> > >> > Yes, st's fallback font support is the main reason I began to use it. I >> > use st and dwm with Japanese and Chinese text almost every single day. >> >> Just chiming in to say that I am using st with Japanese/Chinese fonts every >> day as well. >> >> I don't think we should throw out support for a feature that more than a >> billion >> people on the planet rely on. That doesn't mean that we can't rethink how we >> go about supporting that feature though. >> >> >> Cheers, >> >> Silvan >> > > I agree its useful. (Complex) fall-back font support has been on my mind also. > An idea could be of instead of supporting fallback fonts we could write some > font merge script (pre-runtime).
Very good! That's where the problem should be addressed. Solving font problems pre-runtime at font-file level saves many lines of code. Normally, in non-asian setups only a fraction of the glyphs beyond ascii are used at a time and those few can easily be merged in pre-runtime if not already present e.g. some emojis. It also keeps font files small and avoids loading many megabytes of unneeded glyphs into memory. Regards, Manu
