Re: gdi32: pOS2->xAvgCharWidth can be negative however tmAvgCharWidth needs a positive value
Aric Stewart <aric(a)codeweavers.com> wrote:
- TM.tmAveCharWidth = (pFT_MulFix(pOS2->xAvgCharWidth, x_scale) + 32) >> 6; + TM.tmAveCharWidth = (pFT_MulFix(abs(pOS2->xAvgCharWidth), x_scale) + 32) >> 6;
Did you test what Windows does in that case? -- Dmitry.
Windows response appears to not allow the user to install the fonts at all. It reports any of the fonts I have which have negative OS/2 xAveCharWidth as invalid fonts when I try to install them. This blocks out a few of the main Mac UI fonts. -aric On 2/20/12 10:49 PM, Dmitry Timoshkov wrote:
Aric Stewart<aric(a)codeweavers.com> wrote:
- TM.tmAveCharWidth = (pFT_MulFix(pOS2->xAvgCharWidth, x_scale) + 32)>> 6; + TM.tmAveCharWidth = (pFT_MulFix(abs(pOS2->xAvgCharWidth), x_scale) + 32)>> 6;
Did you test what Windows does in that case?
Aric Stewart <aric(a)codeweavers.com> wrote:
Windows response appears to not allow the user to install the fonts at all. It reports any of the fonts I have which have negative OS/2 xAveCharWidth as invalid fonts when I try to install them.
This blocks out a few of the main Mac UI fonts.
-aric
On 2/20/12 10:49 PM, Dmitry Timoshkov wrote:
Aric Stewart<aric(a)codeweavers.com> wrote:
- TM.tmAveCharWidth = (pFT_MulFix(pOS2->xAvgCharWidth, x_scale) + 32)>> 6; + TM.tmAveCharWidth = (pFT_MulFix(abs(pOS2->xAvgCharWidth), x_scale) + 32)>> 6;
Did you test what Windows does in that case?
So, what Mac does in that case? Why do you think that your fix is correct? -- Dmitry.
On 2/21/12 9:39 AM, Dmitry Timoshkov wrote:
Aric Stewart<aric(a)codeweavers.com> wrote:
Windows response appears to not allow the user to install the fonts at all. It reports any of the fonts I have which have negative OS/2 xAveCharWidth as invalid fonts when I try to install them.
This blocks out a few of the main Mac UI fonts.
-aric
On 2/20/12 10:49 PM, Dmitry Timoshkov wrote:
Aric Stewart<aric(a)codeweavers.com> wrote:
- TM.tmAveCharWidth = (pFT_MulFix(pOS2->xAvgCharWidth, x_scale) + 32)>> 6; + TM.tmAveCharWidth = (pFT_MulFix(abs(pOS2->xAvgCharWidth), x_scale) + 32)>> 6;
Did you test what Windows does in that case?
So, what Mac does in that case? Why do you think that your fix is correct?
The mac handles the fonts without issue. The issue appears to be that the windows tmAveCharWidth should never be negative, and yet this logic causes it to be so for these fonts. If we want to be able to support these fonts, which work in every other regard, we need to have a fix like this. -aric
Aric Stewart <aric(a)codeweavers.com> wrote:
So, what Mac does in that case? Why do you think that your fix is correct?
The mac handles the fonts without issue. The issue appears to be that the windows tmAveCharWidth should never be negative, and yet this logic causes it to be so for these fonts. If we want to be able to support these fonts, which work in every other regard, we need to have a fix like this.
You didn't answer the question. -- Dmitry.
On 2/21/12 10:03 AM, Dmitry Timoshkov wrote:
Aric Stewart<aric(a)codeweavers.com> wrote:
So, what Mac does in that case? Why do you think that your fix is correct?
The mac handles the fonts without issue. The issue appears to be that the windows tmAveCharWidth should never be negative, and yet this logic causes it to be so for these fonts. If we want to be able to support these fonts, which work in every other regard, we need to have a fix like this.
You didn't answer the question.
Didn't I?
what Mac does in that case?
The mac handles the fonts without issue
Why do you think that your fix is correct?
..windows tmAveCharWidth should never be negative, and yet this logic causes it to be so for these fonts. If we want to be able to support these fonts, which work in every other regard, we need to have a fix like this.
What did I not answer? -aric
Aric Stewart <aric(a)codeweavers.com> wrote:
what Mac does in that case?
The mac handles the fonts without issue
Why do you think that your fix is correct?
..windows tmAveCharWidth should never be negative, and yet this logic causes it to be so for these fonts. If we want to be able to support these fonts, which work in every other regard, we need to have a fix like this.
What did I not answer?
What value does Mac return for these kind of fonts? Does it take an abs() like in your patch? Does it trancate the value? Does it calculate it somehow (like taking an average of glyphs say a+z and A+Z)? Does it do something different? -- Dmitry.
On 2/21/12 10:17 AM, Dmitry Timoshkov wrote:
Aric Stewart<aric(a)codeweavers.com> wrote:
what Mac does in that case?
The mac handles the fonts without issue
Why do you think that your fix is correct?
..windows tmAveCharWidth should never be negative, and yet this logic causes it to be so for these fonts. If we want to be able to support these fonts, which work in every other regard, we need to have a fix like this.
What did I not answer?
What value does Mac return for these kind of fonts? Does it take an abs() like in your patch? Does it trancate the value? Does it calculate it somehow (like taking an average of glyphs say a+z and A+Z)? Does it do something different?
Why dos it matter what values Mac returns? Mac does not do GetTextMetrics, looking at the CTFont object it does not even have methods to get an average character width. -aric
Aric Stewart <aric(a)codeweavers.com> wrote:
What value does Mac return for these kind of fonts? Does it take an abs() like in your patch? Does it trancate the value? Does it calculate it somehow (like taking an average of glyphs say a+z and A+Z)? Does it do something different?
Why dos it matter what values Mac returns? Mac does not do GetTextMetrics, looking at the CTFont object it does not even have methods to get an average character width.
It matters because it's not clear what is the best way to handle a negative xAvgCharWidth value, especially since Windows considers this kind of fonts broken, and some apps/dlls (native gdiplus.dll does it for sure) may dig into font data directly, or use the metrics provided by GDI. How are you planning to fix that apps? -- Dmitry.
participants (2)
-
Aric Stewart -
Dmitry Timoshkov