[tex-live] texdoc euscript

[Robin Fairbairns]

Philip Taylor (Webmaster, Ret'd) <P.Taylor at rhul.ac.uk> wrote:

> Reinhard Kotucha wrote:
> > On 12 October 2010 Axel E. Retif wrote:
> >
> >   >  Just to let you know, `` texdoc euscript '' opens
> >   >
> >   >  /usr/local/texlive/2010/texmf-dist/doc/latex/mathmode/images/EuScript.pdf
> >   >
> >   >  instead of
> >   >
> >   >  /usr/local/texlive/2010/texmf-dist/doc/fonts/amsfonts/euscript.pdf
> >
> > Maybe case folding is done too early in the program.  Both files get
> > the same score (4) because of "exact match".  Maybe case folding
> > should add penalties (maybe 0.5).

agreed: that would catch that problem.

> Some sort of statistical analysis of false positives might perhaps be
> worthwhile; in this case, weighting
> 
> 	/usr/local/texlive/2010/texmf-dist/doc/fonts/amsfonts/euscript.pdf
> 
> higher than
> 
> 	/usr/local/texlive/2010/texmf-dist/doc/latex/mathmode/images/EuScript.pdf
> 
> on the basis of "less complex path" would also achieve the desired end.

again, would catch this situation, but both of these ad hoc rules could
easily cause problems elsewhere, with packages with different naming
conventions and/or directory structures.

the problem is the well known one of herding cats.

the earlier LPPL.txt looks entirely reasonable, except that (a) it's a
generic file, applicable to lots of things, (b) it's freezing the state
at the time the package was completed and lppl was still in development,
and (c) plnfss.txt doesn't even point to it, but rather to the latex
project web site copy.

so why did the file appear in the plnfss distribution? -- because it
seemed appropriate to the person who submitted to ctan, at the time the
package was submitted.  (gpl appears, irrelevantly, somewhat more often.)

and of course, statistical analysis of the problems would be a *good*
*thing*, but collecting the data to analyse would be a nightmare.

what's more, i suspect that the results of the analysis would provide
really rather little by way of "general rules".