[tex-live] Fontconfig for XeTeX versus regular fontconfig

[Robin Fairbairns]

Jonathan Kew <jfkthame at googlemail.com> wrote:

> On 27 Oct 2011, at 21:10, Robin Fairbairns wrote:
> 
> > 
> >>> LuaTeX is actively developed while XeTeX is IMHO not really
> >>> maintained.
> > 
> > which isn't a problem if xetex already does what is needed of it.
> > however, xetex surely _does_ need a backstop of some sort.  jonathan kew
> > occasionally answers mails, but i don't believe he codes for it any
> > more.
> 
> OK, here's an occasional response. :)

thank you, kind sir.

> That's a fair assessment, I think. While I have ideas of things I'd
> still like to do with xetex, the reality is that I don't have the time
> to devote to it these days. The last substantial new development was
> done by Han The Thanh, who added the character-protrusion support, but
> I'm not sure if he has time or interest to work on further issues at
> this time. 
> 
> Although I'm unlikely to do substantial coding on it for the time
> being, I'd be happy to review proposed patches or discuss possible
> enhancements if someone wants to take on the work. At one point,
> Jin-Hwan Cho was hoping to do further work on the output driver side,
> but I'm not sure if he has had the opportunity to actually make
> progress there. 

it's the curse of open-source projects: the people who might be able to
help are "gobbled up" by other more pressing matters.  (i would love to
be back in the swing of it -- but i last wrote anything significant
other than scripts in the 90s.)

> I believe the worst of the problems with xetex/xdvipdfmx font
> mismatches due to multiple versions of the same-named font could
> actually be fixed fairly easily, by modifying xetex so that (when
> using fontconfig to find fonts) it always writes the absolute path to
> the font file into the xdv output (as if the font had been specified
> by absolute pathname in the source document). This would of course
> make the xdv file even less "portable" between systems than is
> currently the case,

(well, you dropped the "i" in favour of the "x" at the beginning, so
there's an excuse :-)

> but in practice I don't think there's any
> significant use-case for moving xdv files around; they're essentially
> an internal representation of what will become the PDF output, and the
> fact that they can be captured on disk is incidental (though sometimes
> handy for debugging purposes).

surely a temporary workaround will likely be developed, but if a final
solution involves dropping the portability, i don't doubt it will be
accepted.

(note: we long ago gave up accepting dvi files for ctan.  they're just
too prone to trouble -- their device independence was fine when everyone
used cm for everything, but now...)

robin