Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doc bug: package is experimental or not? #634

Open
nxg opened this issue Apr 11, 2024 · 1 comment
Open

Doc bug: package is experimental or not? #634

nxg opened this issue Apr 11, 2024 · 1 comment

Comments

@nxg
Copy link

nxg commented Apr 11, 2024

A minor documentation bug: The PDF documentation for the package, generated from unicode-math.dtx and available to users using texdoc, still describes itself as ‘Experimental Unicode mathematical typesetting’, and stresses experimental again in the introduction. However the package's CTAN page doesn't suggest anything experimental about the package, and the GitHub page goes no further than saying the author is ‘a little wary of encouraging people to use this package for production work’.

Given the latter, the documentation's announcement of itself as ‘experimental’ seems to be selling itself short, and is at least a little confusing. While I appreciate and applaud the instinct for caution, or modesty, and wouldn't want to hurry the authors towards a premature declaration of completeness, it would be less confusing if any residual... beta-ness (?) of the package were described in a different way, especially – and I think this might be the key point – since there doesn't seem to be any other reasonable way of including the same font support.

‘Provisional’, ‘development’, ‘beta’ or ‘release candidate’ might be less unexpected ways for the package to characterise what appears to be its real status in practice.

@wspr
Copy link
Collaborator

wspr commented Jul 18, 2024

I appreciate the comments :) Will look into it. Work in this area certainly isn't complete -- it might be in the future that the LaTeX format itself provides a lot of this support automatically using different interfaces, in which case the package might need to change or drop certain features. But you're right it's been around for quite a long time now, so changing the language around this would certainly be appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants