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

Correct score selection in FcFontSetMatchInternal, and some debug utils #4

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Artoria2e5
Copy link

FcFontSetMatchInternal was using the strength of the first element in
deciding which score to use. This is wrong as we should look at the
priority instead.

Instead of building two scores to choose from, we now only use one
score variable and decide whether it should be used for strong, weak,
or both by testing for matcher->{strong,weak} == priority. Doing so
ensures perfect emulation of FcCompare() behavior for each priority.

Fixes #2.

This commit moves FcBitset's definition to fcint.h and adds debug
printing support. Such a function can be used for verbose output.
Two types of debug messages are added at level MATCHV. If the MATCHV
debug level is requested, FcFontSetMatchInternal now:

1) Lists all fonts in the sets along with an internal index used for
   bitsets. This makes 2) meaningful.
2) Prints the enum index of a priority level at the start of a
   priority-match loop, and the final bitset at its end.

In addition, MATCH prints the best pattern at the end like the
pre-rewrite version does.
FcFontSetMatchInternal was using the strength of the first element in
deciding which score to use. This is wrong as we should look at the
priority instead.

Instead of building two scores to choose from, we now only use one
score variable and decide whether it should be used for strong, weak,
or both by testing for matcher->{strong,weak} == priority. Doing so
ensures perfect emulation of FcCompare() behavior for each priority.

Fixes michalsrb#2.

A previous version of this commit decided between a strong and a weak
score by testing for matcher->strong == priority. This fix is
incomplete: for priorities that share the same value for strong and
weak, FcCompareValueList would use the smaller of those two when called
by FcCompare as two pointers to "score" coincide; the previous fix does
not similate this 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

Successfully merging this pull request may close these issues.

1 participant