Re: Pango process_modules_file () module path

[Behdad Esfahbod <behdad behdad org>]

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/