Hi,
We had report of regression in GTK markups rendering in Ubuntu precise,
(i.e label would render underlined), I've tracked the issue to
that commit:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b0962ac34e66052ccfee7996e5468f30d4bd5a72
It turns out that same commit als
> We had report of regression in GTK markups rendering in Ubuntu
> precise, (i.e label would render underlined), [...]
>
> We have reverted that commit in Ubuntu for now to workaround the
> issue but I would like to know how to determine if that's a bug in
> freetype or if other part of the stack
Werner LEMBERG wrote:
> > We had report of regression in GTK markups rendering in Ubuntu
> > precise, (i.e label would render underlined), [...]
> >
> > We have reverted that commit in Ubuntu for now to workaround the
> > issue but I would like to know how to determine if that's a bug in
> > freety
On Tue, Apr 3, 2012 at 9:05 AM, Peter Hurley wrote:
> Werner LEMBERG wrote:
>> > We had report of regression in GTK markups rendering in Ubuntu
>> > precise, (i.e label would render underlined), [...]
>> >
>>
>> AFAIK, the problem is in gtk. For years, FreeType had this metrics
>> bug, and unfort
> This is not strictly a vertical line spacing problem. The primary
> impact of this fix is that the metrics are now integer-scaled rather
> than fractionally scaled. (Indeed, this appears to be the reason the
> TT driver overrides the default size_request.)
Yes. This is what the TrueType standa
> Yes. This is what the TrueType standard mandates for bi-level and
> grey-level glyphs. Note that ClearType is *not* implemented in
> FreeType yet! As soon as this happens, the situation changes.
BTW, section 3.3.2 in the document below gives a nice description of
fractional advance widths an
On Tue, 2012-04-03 at 12:01 -0400, Werner LEMBERG wrote:
> > Yes. This is what the TrueType standard mandates for bi-level and
> > grey-level glyphs. Note that ClearType is *not* implemented in
> > FreeType yet! As soon as this happens, the situation changes.
>
> BTW, section 3.3.2 in the docum
On Tue, 2012-04-03 at 11:35 -0400, Werner LEMBERG wrote:
> > This is not strictly a vertical line spacing problem. The primary
> > impact of this fix is that the metrics are now integer-scaled rather
> > than fractionally scaled. (Indeed, this appears to be the reason the
> > TT driver overrides th
> I'm referring to when the x-scale is forced to be an integer-multiple of
> units/EM.
??? This is not the case.
> For example, let's suppose that I use FT_Set_Char_Size() to specify the
> desired character width as 10.66 (really, 10 43/64). This generates a
> size_request() to the TT driver, w
On Tue, 2012-04-03 at 09:53 -0400, Alexei Podtelezhnikov wrote:
> On Tue, Apr 3, 2012 at 9:05 AM, Peter Hurley wrote:
> > Werner LEMBERG wrote:
> >> > We had report of regression in GTK markups rendering in Ubuntu
> >> > precise, (i.e label would render underlined), [...]
> >> >
> >>
> >> AFAIK, t
> I agree that my statement is hypothetical -- as was Werner's
> assertion that "What FreeType now returns is what the font designer
> has had in mind while designing the font".
My assertion is not hypothetical! As the goal of FreeType is to be
fully compatible with the MS rasterizer, unexpected
On Wed, 2012-04-04 at 01:39 -0400, Werner LEMBERG wrote:
> > I'm referring to when the x-scale is forced to be an integer-multiple of
> > units/EM.
>
> ??? This is not the case.
The description below is from a code trace in GDB. x_scale is
specifically recomputed in tt_size_reset() as:
metri
>> > I'm referring to when the x-scale is forced to be an
>> > integer-multiple of units/EM.
>>
>> ??? This is not the case.
>
> The description below is from a code trace in GDB. x_scale is
> specifically recomputed in tt_size_reset() as:
>
>metrics->x_scale = FT_DivFix( metrics->x_ppem << 6,
13 matches
Mail list logo
