You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would be a great enhancement for the user to deal with the convenient types, such as the fixed crate. Otherwise, I suggest providing a mistake-free interface and immediately requiring both halves of the number in a fixed format separately so that the users don't need to write code like this:
face.set_char_size(40 * 64, 0, 50, 0).unwrap();
I presume, though not sure yet, that * 64 is due to the Fixed(26, 6) unsigned integer required by FreeType. This is not straightforward, error-prone and not really user-friendly, while can easily be improved. Also, there is more than one way to do the same, and without optimisations, this code might really be a multiplication instead of a bit shift; who knows?
Either way, using a strict fixed-width number type would greatly reduce the complexity of the crate for the user while also providing clear requirements and leading to clear results.
Another thing it will help withis the documentation: currently, even in the FreeType itself, one must read the documentation to understand which arguments to pass there, as they all are just FT_ULong and so on, while in fact, those are fixed-width packed numbers. If we require such clear types directly in the crate interface, no one will ever be confused, and for this particular thing, no one will have to read the documentation.
I can work on it myself, should you prefer.
The text was updated successfully, but these errors were encountered:
iddm
changed the title
Why not using the existing crates for the fixed-width numbers?
Why not use the existing crates for the fixed-width numbers?
Feb 11, 2024
I think it would be a great enhancement for the user to deal with the convenient types, such as the fixed crate. Otherwise, I suggest providing a mistake-free interface and immediately requiring both halves of the number in a fixed format separately so that the users don't need to write code like this:
I presume, though not sure yet, that
* 64
is due to theFixed(26, 6)
unsigned integer required by FreeType. This is not straightforward, error-prone and not really user-friendly, while can easily be improved. Also, there is more than one way to do the same, and without optimisations, this code might really be a multiplication instead of a bit shift; who knows?Either way, using a strict fixed-width number type would greatly reduce the complexity of the crate for the user while also providing clear requirements and leading to clear results.
Another thing it will help withis the documentation: currently, even in the FreeType itself, one must read the documentation to understand which arguments to pass there, as they all are just
FT_ULong
and so on, while in fact, those are fixed-width packed numbers. If we require such clear types directly in the crate interface, no one will ever be confused, and for this particular thing, no one will have to read the documentation.I can work on it myself, should you prefer.
The text was updated successfully, but these errors were encountered: