Le mar. 19 mai 2020 à 10:05, Alexei Podtelezhnikov <apodt...@gmail.com> a écrit : > > On Tue, May 19, 2020 at 8:09 AM Hugh McMaster <hugh.mcmas...@outlook.com> > wrote: > > Is there any opportunity to avoid modifying ftoption.h directly to > > enable, say, subpixel rendering with a new build system? Carrying > > permanent patches for downstream packaging is annoying. > > [Presently, FT_CONFIG_OPTION_SUBPIXEL_RENDERING only alternates > between ClearType and Harmony algorithms. Most users won't be able > to tell them apart.]
Note that some users of FreeType are never going to use subpixel rendering at runtime and could do without the code. The actual amount of code is pretty negligible, but if they are never going to use it it's just extra weight, so it's nice to be able to configure it out, no matter how small the extra code for it is. > > Personally, I'd like to be able to enable various options via > > configure flags or a configurable file (JSON, anyone?) that's not a C > > header. Python could do nicely here. > > One would think that modules.cfg is a configurable file like that but it turns > out that Chromium finds special ftmodule.h more convenient. We also have to > accommodate the less fortunate without Python on embedded systems. Chromium currently finds the ftmodule.h a convenient way to tell the runtime (ftinit.c ft_default_modules) which modules got built at build time. If there were a particularly better way to do that I don't think there would be much difficulty adapting. For example if the whole service / module structure went away and libfreetype just always did what was built and the list of modules to be loaded at library init didn't need to exist then we'd just build what bits we needed in each build and drop the ftmodule.h customization bits. > Some choices in FreeType, including the service and module infrastructure and > very lean external dependencies, has helped it to spread so widely. > > > Other than that, the removal of RPATHs should be revisited. That's a > > topic for another thread. > > Ok. > > Alexei >