Re: Type error in ttfautohint Re: Freetype-devel Digest, Vol 216, Issue 3)

[Hin-Tak Leung]

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 <mike.sapsard@gmail.com> 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.