>> This has been replaced with
>>
>> ascender_int = round(ascender_26.6);
>> descender_int = round(descender_26.6);
>> height_int = ascender_int - descender_int;
>>
>
> This seems to assume that height_26.6 was always ascender_26.6 + -
> descender_26.6. I'm not sure this is always true. IIR
And why would anyone make it differ from that? :)
2013/1/23 Alexei Podtelezhnikov :
> On Wed, Jan 23, 2013 at 10:50 AM, Wojciech Mamrak wrote:
>> What is the largest possible "height" change between the old and new
>> implementation? Can it exceed one pixel?
>>
>
> It should not exceed 1 pixel un
>> I wonder whether we should do the same for non-TrueType fonts. I
>> think yes, but please comment!
>
> With TrueType fonts, one expects Windows-like behavior. With
> others, one does not. That said, there is a virtue in consistency.
> Either way, man.
If you look at the code for a single g
Here are the latest updates I've been working on for the subpixel
hinting stuff. This removes a few hard-coded tweaks in favor of
automatic detection. In addition it attempts to follow the MS
whitepaper more by restricting the conditions of the FDEFs to those
specified instead of "everything"
On Wed, Jan 23, 2013 at 10:50 AM, Wojciech Mamrak wrote:
> What is the largest possible "height" change between the old and new
> implementation? Can it exceed one pixel?
>
It should not exceed 1 pixel unless the height specified in the font
differs from (acsender - descender) by more than 1 pixe
What is the largest possible "height" change between the old and new
implementation? Can it exceed one pixel?
2013/1/23 Werner LEMBERG :
>
>> I was just wondering if we have any examples of real-world, visual
>> impact of the change, whether that's on hinting or something else.
>
> Oops, it's not
My recent patch to reformat the subpixel code broke C++ compilation, sorry
about that.
However, here's a fix
It turns out that C++ doesn't allow you to declare (and not define) a
static constant.
- David
0001-Fix-C-compilation.patch
Description: Binary data
On Wed, Jan 23, 2013 at 11:10 AM, David Turner wrote:
> Unless I'm missing something (which is entirely possible, and I've not
> looked at the patch details yet).
>
> If that so, maybe add some code to deal with this, e.g.:
>
> if (height_26.6 == ascender_26.6 - descender_26.6) {
> height_in
2013/1/23 Werner LEMBERG
>
> Folks,
>
>
> just a heads-up which might influence applications: I've just fixed a
> bug in the TrueType handler to correctly compute the `height' value of
> the `FT_Face' structure. Up to now, the following was done:
>
> ascender_int = round(ascender_26.6);
> de
I wonder whether we should do the same for non-TrueType fonts. I
think yes, but please comment!
Are there any known TTF fonts where the hinting is impacted
(positively or negatively) by this change?
No, this change is not related to hinting at all. It affects *all*
TrueType fonts regardless
> I was just wondering if we have any examples of real-world, visual
> impact of the change, whether that's on hinting or something else.
Oops, it's not
FT_Face->height
but
FT_Face->size->metrics->height
which gets computed differently now. Sorry for the confusion.
All programs which us
On Wed, Jan 23, 2013 at 5:31 AM, Werner LEMBERG wrote:
> just a heads-up which might influence applications: I've just fixed a
> bug in the TrueType handler to correctly compute the `height' value of
> the `FT_Face' structure...
>
> ...to be in sync with Windows.
>
> I wonder whether we should do
>> I wonder whether we should do the same for non-TrueType fonts. I
>> think yes, but please comment!
>
> Are there any known TTF fonts where the hinting is impacted
> (positively or negatively) by this change?
No, this change is not related to hinting at all. It affects *all*
TrueType fonts re
> Freetype encounters an error when open the embeded font. the error
> code is 2.
I've extracted the font with pdftk, and the current git renders this
font just fine (and version 2.4.11 also works).
Werner
___
Freetype-devel mailing list
Freetype
I wonder whether we should do the same for non-TrueType fonts. I think
yes, but please comment!
Are there any known TTF fonts where the hinting is impacted (positively
or negatively) by this change? I had a version of Inconsolata Bold that
looked like crap after this change, but it turns o
Thanks.
That looks to be exactly the information I was looking for.
-Original Message-
From: Huw Davies [mailto:h...@codeweavers.com]
Sent: 23 January 2013 09:23
To: Tony Smith
Cc: freetype-devel@nongnu.org
Subject: Re: [ft-devel] Generating Windows text metrics
On Tue, Jan 22, 2013 at 0
Folks,
just a heads-up which might influence applications: I've just fixed a
bug in the TrueType handler to correctly compute the `height' value of
the `FT_Face' structure. Up to now, the following was done:
ascender_int = round(ascender_26.6);
descender_int = round(descender_26.6);
heig
On Tue, Jan 22, 2013 at 04:03:20PM +, Tony Smith wrote:
>
> In the Windows API function ::CreateFont the height can be passed in two ways.
> A negative height gives metrics for fit to character height and a positive
> heights means fit to cell height.
> Here is the MSDN page for some more deta
Hi,
Freetype encounters an error when open the embeded font. the error code is 2.
Adobe reader can render correct.
Could you please take a look?
Thanks.
Johnson Y. Yan
This email may contain information which is privileged, confidential, legally
privileged, and/or exempt from disclosure und
[No need to post twice! Be patient and wait a few days until doing a
`ping' in case you don't get a reponse.]
> In the Windows API function ::CreateFont the height can be passed in
> two ways.
>
> A negative height gives metrics for fit to a character height and a
> positive heights means fit
In the Windows API function ::CreateFont the height can be passed in two
ways.
A negative height gives metrics for fit to a character height and a
positive heights means fit to a cell height.
Here is the MSDN page for some more details.
http://msdn.microsoft.com/en-gb/library/windows/desktop/dd1
> I think I've figured out the issue here, and (huge surprise) it's
> not firefox. I was making the detection of opcode patterns
> dependent on ignore_x_mode being set, however this doesn't get set
> until glyphs are loaded.
Doh. Yes, for speed reasons the parsing of tables is lazy, at least
pa
22 matches
Mail list logo
