freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mike Sapsard
Subject: Re: Type error in ttfautohint Re: Freetype-devel Digest, Vol 216, Issue 3)
Date: Fri, 27 Jan 2023 07:36:15 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

I am using the Pilcrow font generator to create a variable font.

It is at https://github.com/simoncozens/pilcrow.

If you scroll down that page, you will see the GUI it creates.

I have not spent any time trying to understand the code. I just ran it, and fixed dependencies and that typecast to get it working.

I am using Linux Mint 21.1, so I think you are probably right about it being a qt problem.

Mike

On 26/01/2023 22:55, Hin-Tak Leung wrote:
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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]