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
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
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 details.
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
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
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
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
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 use
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
2013/1/23 Werner LEMBERG w...@gnu.org
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);
On Wed, Jan 23, 2013 at 11:10 AM, David Turner da...@freetype.org 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) {
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
What is the largest possible height change between the old and new
implementation? Can it exceed one pixel?
2013/1/23 Werner LEMBERG w...@gnu.org:
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
On Wed, Jan 23, 2013 at 10:50 AM, Wojciech Mamrak wmam...@gmail.com 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
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.
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 glyph,
And why would anyone make it differ from that? :)
2013/1/23 Alexei Podtelezhnikov apodt...@gmail.com:
On Wed, Jan 23, 2013 at 10:50 AM, Wojciech Mamrak wmam...@gmail.com wrote:
What is the largest possible height change between the old and new
implementation? Can it exceed one pixel?
It
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. IIRC, there are
18 matches
Mail list logo
