Actually I am a bit confused - you don't seem to be using anything that
directly interact with freetype - are you trying to write a new GUI front end
to ttfautohint?
The self.splitter etc method seems to be QT routine, and has nothing to do with
freetype or ttfautohint? Anyway, if it is QT related it is probably all in
pixels (and therefore needs int), if pilcrow somehow pass the number to
freetype-py or something internal to freetype / ttfautohint , it probably is
F26.6. (That means floating numbers only have about 1/64 precision, ie two
decimal places, but nobody needs Time Roman in 12.3456 pt's in sizes with too
many decimal places）
On Friday, 27 January 2023 at 03:06:23 GMT+8, Mike Sapsard
<[email protected]> wrote:
Thanks Hin-Tak,
I did try typecasting the result, and that was worse. Strangely, Pilcrow ran
correctly with my change.
I will let them know as well.
Mike
On 26/01/2023 17:56, Hin-Tak Leung wrote:
Your fix is wrong. And you are also reporting to the wrong people too -
pillcrow is probably who you should write to. That said, it is a very common
misunderstanding: numbers in freetype are not conventional floats in other
programs. They are "encoded integers", called F26.6 in this case I think (read
the documentation), where a 32-bit integer is to be interpreted as 26bit for
the integer part and 6 bits for the fractional part (ie 128 is really 2, and
100 is 1 + 36/64).
Thus your "fix" should probably be int(width * 2 / 3 * 64), etc. For
example. Note the *64. Read the documentation on F26.6, F10.6, etc.
