[ft-devel] Re: FT_MAX_CURVE_DEVIATION vs ONE_PIXEL cont'd
Werner, Graham, Please do not let this slip through the cracks. If you do not want to harmonize conic and cubic splines completely, you have two choices: 1) DOWNSCALE(ONE_PIXEL) in the conic splines 2) move UPSCALE coordinates to the top of the conic function The former is ugly in my opinion. The latter at least harmonizes how the conic and cubic splines work from the start. Also, you may consider moving back to ONE_PIXEL / 4 in the conics, as Graham originally intended, but may need some rendering quality control. As it stands right now the truetypes are dog-ugly. Alexei 2010/10/17 Алексей Подтележников apodt...@gmail.com: On Sun, Oct 17, 2010 at 4:53 AM, Werner LEMBERG w...@gnu.org wrote: It turns out that since 2.4.3 the cubic deviations have been estimated *after* UPSCALE, whereas conic ones have been evaluated *before* UPSCALE. This was probably the original sin that led to the misuse of FT_MAX_CURVE_DEVIATION that we've just fixed in cubic. Let's fix the original sin now. I won't comment the patch itself since I'm not too acquainted with those intricate geometric details. However, please resend your patch as an attachment; your mailing program inserts replaces ordinary spaces with non-breaking space characters at arbitrary places... Ok. I'm resending the non-intrusive patch as an attachment. The intrusive harmonization of the conic and cubic splines is to follow in a separate thread. Alexei -- Alexei A. Podtelezhnikov, PhD ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: FT_MAX_CURVE_DEVIATION vs ONE_PIXEL cont'd
Please give evidence of ugliness in the form of images, preferable in sets of three: (i) before the patch from David Bevan and myself; (ii) using the current version of FreeType; (iii) using your suggested patch. Thanks, Graham - Original Message From: Алексей Подтележников apodt...@gmail.com To: Werner LEMBERG w...@gnu.org Cc: freetype-devel@nongnu.org Sent: Wednesday, 20 October, 2010 13:19:52 Subject: [ft-devel] Re: FT_MAX_CURVE_DEVIATION vs ONE_PIXEL cont'd Werner, Graham, Please do not let this slip through the cracks. If you do not want to harmonize conic and cubic splines completely, you have two choices: 1) DOWNSCALE(ONE_PIXEL) in the conic splines 2) move UPSCALE coordinates to the top of the conic function The former is ugly in my opinion. The latter at least harmonizes how the conic and cubic splines work from the start. Also, you may consider moving back to ONE_PIXEL / 4 in the conics, as Graham originally intended, but may need some rendering quality control. As it stands right now the truetypes are dog-ugly. Alexei 2010/10/17 Алексей Подтележников apodt...@gmail.com: On Sun, Oct 17, 2010 at 4:53 AM, Werner LEMBERG w...@gnu.org wrote: It turns out that since 2.4.3 the cubic deviations have been estimated *after* UPSCALE, whereas conic ones have been evaluated *before* UPSCALE. This was probably the original sin that led to the misuse of FT_MAX_CURVE_DEVIATION that we've just fixed in cubic. Let's fix the original sin now. I won't comment the patch itself since I'm not too acquainted with those intricate geometric details. However, please resend your patch as an attachment; your mailing program inserts replaces ordinary spaces with non-breaking space characters at arbitrary places... Ok. I'm resending the non-intrusive patch as an attachment. The intrusive harmonization of the conic and cubic splines is to follow in a separate thread. Alexei -- Alexei A. Podtelezhnikov, PhD ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] How to get the position of a glyph without rendering it
A Dimecres, 20 d'octubre de 2010, vàreu escriure:
Hi,
On Wed, 20 Oct 2010 01:29:29 +0100
Albert Astals Cid aa...@kde.org wrote:
That code works fine for most of the fonts i tried but now i have
encountered a case in which
round(-glyphMetrics-horiBearingX / 64.0);
is -2 and
-slot-bitmap_left;
is 26
Could you tell me any sample fonts to reproduce
this issue?
I think, the metric infos available before rendering
come from metric tables, and the metric infos available
after the rendering come from glyf table, so there
can be incompatible values (rather, broken font may
have different values).
Here some sample code and the font.
Any help more than welcome,
Albert
Regards,
mpsuzuki
#include ft2build.h
#include FT_FREETYPE_H
#include FT_OUTLINE_H
#include FT_SIZES_H
#include FT_GLYPH_H
static void eerror(const char *msg, FT_Error e)
{
printf(%s 0x%0x\n, msg, e);
exit(1);
}
int main(int argc, char *argv[])
{
FT_Face face;
FT_Vector offset;
FT_GlyphSlot slot;
FT_UInt gid;
FT_Matrix matrix;
FT_Library lib;
FT_Error e;
if (e = FT_Init_FreeType(lib))
eerror(1, e);
if (e = FT_New_Face(lib, font.ttf, 0, face))
eerror(2, e);
if (e = FT_New_Size(face, face-size))
eerror(3, e);
if (e = FT_Set_Pixel_Sizes(face, 0, 28))
eerror(6, e);
matrix.xx = (FT_Fixed)(0);
matrix.yx = (FT_Fixed)(65536);
matrix.xy = (FT_Fixed)(-65536);
matrix.yy = (FT_Fixed)(0);
offset.x = 0;
offset.y = 0;
FT_Set_Transform(face, matrix, offset);
slot = face-glyph;
gid = (FT_UInt)45;
if (e = FT_Load_Glyph(face, gid, FT_LOAD_NO_BITMAP))
eerror(4, e);
FT_Glyph_Metrics *glyphMetrics = (face-glyph-metrics);
int x = -glyphMetrics-horiBearingX / 64.0;
int y = glyphMetrics-horiBearingY / 64.0;
int w = glyphMetrics-width / 64.0;
int h = glyphMetrics-height / 64.0;
if (e = FT_Render_Glyph(slot, ft_render_mode_normal))
eerror(5, e);
int x2 = -slot-bitmap_left;
int y2 = slot-bitmap_top;
int w2 = slot-bitmap.width;
int h2 = slot-bitmap.rows;
printf(%d %d\n, x, x2);
printf(%d %d\n, y, y2);
printf(%d %d\n, w, w2);
printf(%d %d\n, h, h2);
}
font.ttf
Description: application/font-ttf
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
