[tex-live] TeXLive2007: Bug in (Xe)TeX for 64bit and big endianess

[Thanh Han The]

On Wed, May 09, 2007 at 02:34:34PM +0200, Frank K�ster wrote:
> "Thanh Han The" <hanthethanh at gmail.com> wrote:
>
> > My vote is to have pdftex linked statically against xpdf
> > codes, and apply relevant patches to the xpdf codes in the
> > source tree of pdftex if needed. The responsibity should be
> > on the pdftex team to verify and apply any patch if needed.
>
> What do you mean with "pdftex team"?  The developers on
> ntg-pdftex at ntg.nl?  Are you really willing to take this responsibility?
> In a timely manner?  Also for old versions which might still be
> supported by distributors?
>
> For Debian, that would currently be 1.10b, 1.21a, 1.30.4 and 1.40.1.

we didn't promise such a thing, and I see no reason why we
should do that. Our goal is to keep the latest pdftex
stable.

regards "pdftex team"'s responsibility: since EuroBachoTeX
2007, the person responsible for pdftex source control is
Taco Hoekwater. Any patch must pass Taco's approvement
before it can get into pdftex official sources. Taco of course
discusses things with other people in the team and makes the
final decision according to his best judgement.

> > yes, this is little (if at all) related to pdftex, since I
> > didn't talk about pdftex in this case but xpdf. From the
> > perspective of an end Debian user, it doesn't look good when
> > the distro I use provides xpdf binary that segfaults and the
> > original one from Derek (with the same version) doesn't.
> > Which raises the question: do the patches provided by
> > distros really improve xpdf?
>
> I don't know which patches are applied to xpdf and why.  But usually
> there's a reason for such fixes, and on the other hand it's okay to
> question this decision.
>
> But I still don't get how that is relevant in this discussion.  Do you
> want to draw an analogy "if distributors' patches for xpdf lower the
> quality, so will patches to pdftex"?

I mean this: those patches while trying to fix certain
issues, might bring another class of problems themselves,
and we don't want to deal with things that are issues of
distributors. We don't want to prevent third-parties to use
poppler instead of xpdf, but we also don't want to be
dependent of poppler. At least for the moment. So pdftex
should be built with xpdf code by default, and anyone who
wishes to use poppler instead is free to do so. Martin has
promised to provide an easy way to do that. Or anyone from
the distributors can submit a patch for this purpose. And if
Taco considers the patch good enough, it will be in.

> > As you mentioned above, since I cannot afford the time to
> > learn and understand all xpdf and poppler code and related
> > patches, I have to trust someone who understands xpdf best
> > and is responsible for xpdf.
>
> Ah, so it's not going to be you who does the verifying you claimed above
> should be done by the pdftex team?  Who else?

as I said above: Taco is responsible for pdftex sources
now. If Taco doesn't have the time to do that, he will
have to discuss with people and makes the decision he
considers as the most appropriate.

> > For me it's the xpdf author,
> > Derek, and not the poppler maintainers, sorry. If a serious
> > problem with xpdf is found, I believe Derek would deal with
> > it in the way that is best to him, since after all it's also
> > his interest to have xpdf reliable.
>
> In the past, we never got any help from Derek in creating patches for
> old versions.

I think it's another story, but let's stop here.


Regards,
Thanh