On 12-12-19 08:20 PM, John Ralls wrote: > I was actually thinking about that last night. I'm in favor: That code gets > loaded anyway, there's no practical way to select what gets loaded, so might > as well make it a shared library and link it directly at start up.
As it stands today, each pango backend (pangofc, pangowin32, pangocoretext) has exactly one shaper backend. As for language modules, there's three of them. Two always included, one only if libthai is available. All in all, there simply is no point in having that extension point. In the past ten years, there have been two external modules in development: a graphite one, and a libm17n. The first one is obsolete by the hb-graphite backend, the latter not that interesting, and again, belongs into harfbuzz if anything. I'll put this into my holiday-hacking. I probably just remove the loadable-module support and only support static modules, that way we can keep the pangox-compat library working, but forever put an end to the pango.modules headache. That leaves only pango.aliases still being used by the Win32 backend. I'll just get rid of that one also and then we'll have no configuration files whatsoever. Just like what you expect of a text rendering library. If someone feels like doing it, we can change the Win32 backend to look into the registry for font fallback preferences. That's the right thing to do anyway. behdad > Regards, > John Ralls -- behdad http://behdad.org/ _______________________________________________ gtk-i18n-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
