Hello List!, I would like to present some of my questions and doubts regarding mostly glyphs' metrics and positioning. I will try to be concise.
Data reliability in glyphSlot->metrics Based on the image from tutorial step 2: http://www.freetype.org/freetype2/docs/tutorial/metrics.png advance = bearingX + width + x //for horizontal text layouts Assume I need to know the value of x - I can obtain it from the above formula. I've made a test: freetype 246, font arial 5.10, font size 40px, FT_LOAD_FORCE_AUTOHINT, FT_RENDER_MODE_LCD, FT_LOAD_TARGET_LCD, FT_LCD_FILTER_DEFAULT, character '1': (values based on 26.6 pixel format) advance: 22.0px bearingX: 4.0px width: 11.0px Attached image presents the rendered glyph with additional border so that bearingX can be verified. Values taken from the image (ft_1.png): advance: 22px bearingX: 4px width: 13px //!! I have also noticed some issues with metrics.advance. Specification as above except: font size 12px, character 'e': Values from ft: advance: 7.0px bearingX: 1.0px width: 6.0px Values taken from the image (ft_e.png): advance: 7px bearingX: 1px width: 7px //!! What can cause the above discrepancies? Is data in metrics reliable? I will keep my other doubts until I receive an answer to that, since they follow from it. Thanks, regards PS. Additional question: Across almost all tutorial examples (ignore those using transformations) the following code is used: /* now, draw to our target surface */ my_draw_bitmap( &slot->bitmap, pen_x + slot->bitmap_left, pen_y - slot->bitmap_top ); Since bitmap_left origins from the bitmap, it is always rounded to integer pixel coordinates (i.e., it is a multiple of 64), right? What follows from it is that it can't be used when implementing full wysiwyg rendering systems (i.e. with subpixel positioning), and instead slot->metrics.horiBearingX should be used. It is my assumption from the definitions of both, which are very similar. What is more interesting these values are never equal to each other (the difference is usually one pixel) TBH I don't like situations when the same data is duplicated in two forms: accurate and less accurate :) Are my assumtions correct?
<<attachment: ft_1.png>>
<<attachment: ft_e.png>>
_______________________________________________ Freetype mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype
