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

calt feature should be enabled by default #133

Open
khaledhosny opened this issue Feb 15, 2020 · 2 comments
Open

calt feature should be enabled by default #133

khaledhosny opened this issue Feb 15, 2020 · 2 comments

Comments

@khaledhosny
Copy link
Contributor

I’m under the impression that this is not currently the case but many fonts depend on it being on by default.

On general, it might be a good idea to follow the features HarfBuzz enables by default as it is probably more tested (it would have been helpful if the OpenType spec was more reliable here, but currently it isn’t).

@zauguin
Copy link
Member

zauguin commented Feb 15, 2020

I’m under the impression that this is not currently the case but many fonts depend on it being on by default.

I agree that we should activate it, I'm currently mostly asking myself about some implementation detail: We could either make it a "global" default feature or a default feature for every script.
On an abstract level, it feels more like a global default feature, but until now such features are generally handled as script specific defaults. (The difference is important if someone changes the default configuration in luaotfload.conf for some script: Global default features are still applied, script-specific ones are overwritten.)

On general, it might be a good idea to follow the features HarfBuzz enables by default as it is probably more tested (it would have been helpful if the OpenType spec was more reliable here, but currently it isn’t).

@khaledhosny Do you have some examples where HarfBuzz and the spec disagree and especially why they disagree? Generally I strongly prefer following the specification instead of replicating some other implementation.

See also a recent TeX.SX question where this lead to problems.

@khaledhosny
Copy link
Contributor Author

Generally I strongly prefer following the specification instead of replicating some other implementation.

OpenType is an odd case. There is an ISO standard but it only covers the file format, the layout behavior is not not part of the standard and is documented separately by Microsoft in a set of “Script development specs” that basically describe what Microsoft implementation was doing at certain point in time and are often incomplete or outdated. Also the documentation is unversioned and can be silently updated when Windows implementation changes behavior and others will only know about it when people complain the fonts work differently with different implementations.

There is also a feature tag registry that was mostly written before OpenType was even implemented and full of wishful thinking and outdated idea about how OpenType was supposed to be handled. It also often contradicts the script specs.

For long time Windows was all that matters and fonts were built to work with it (would good it be to build fonts against some standard if they don’t work on the dominant platform). We don’t have the source code of Microsoft implementation (the de facto standard) and Microsoft documentation is often incomplete or outdated. HarfBuzz is the next good thing as it tries to be compatible with Microsoft implementation and is widely used enough that any incompatibility is likely to be caught (if not already).

@khaledhosny Do you have some examples where HarfBuzz and the spec disagree and especially why they disagree?

Here is an example. In this case they don’t explicitly disagree, but the spec does not accurately document the Windows behavior of the feature.

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