Re: [ft] Off by one error in freetype (or in programmer?)

On Fri, 06 Apr 2018 07:15:56 +0200 (CEST), Werner LEMBERG wrote: >>> In TrueType, for example, all glyphs are shifted by (-1/2,-1/2) >>> internally to align pixel centers with the grid. >> >> > > Nice, but completely irrelevant. For

Re: [ft] Off by one error in freetype (or in programmer?)

>> In TrueType, for example, all glyphs are shifted by (-1/2,-1/2) >> internally to align pixel centers with the grid. > > Nice, but completely irrelevant. For the conversion of font outlines to pixmaps or graymaps, pixels *are*

[ft] Freetype2 returns different descender value after upgrading 2.6.x to 2.8.x

Hello freetype! I'm minho sun who is working at Samsung Research. My main work is making text winset work in our UI framework named DALi. We use freetype to get font information and freetype2 worked perfectly since we updated it 2.6.x to 2.8.x. After updating, freetype2

Re: [ft-devel] Time for a new FreeType release

here it is ;-) https://github.com/felipesanches/freetype2/commits/meson_build 2018-04-05 19:29 GMT-03:00 Nikolaus Waxweiler : > If anyone would like to take a look, I can publish it in my own git repo >> for a review and surely some further improvements. >> > > I suppose

Re: [ft-devel] Time for a new FreeType release

If anyone would like to take a look, I can publish it in my own git repo for a review and surely some further improvements. I suppose posting it won't hurt :) ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] Time for a new FreeType release

(Oh yeah, and the ftver.rc thing and include/freetype/tttags.h are missing from the source package) I don't understand this remark. Please elaborate. I still need to look at the ftver.rc issue Alexie pointed out. The tttags.h file does not show up in the source package you can generate

Re: [ft-devel] Time for a new FreeType release

Can you be specific which cmake problems you "cleaning up"? 1. Add optional external libraries as option()s, more idiomatic than just using some defines 2. Set some properties not globally, but on the freetype library target. That's neater. 3. Minor, mostly cosmetic changes to the CPack

Re: [ft-devel] Who needs FT_CONFIG_OPTION_PIC?

Wow. That one was so obscure that Google didn't immediately find something on it. Good riddance. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft] Off by one error in freetype (or in programmer?)

On Thu, 05 Apr 2018 13:08:40 +0200 (CEST), Werner LEMBERG wrote: > Yes. Pixels *do* have dimensions :-) > > In TrueType, for example, all glyphs are shifted by (-1/2,-1/2) > internally to align pixel centers with the grid.

Re: [ft-devel] Who needs FT_CONFIG_OPTION_PIC?

> Just to be clear, why is the PIC macro needed? Why isn't it enough > to use -fPIC? The BREW compiler cannot emit position-independent code by itself; everything has to be done by the user. Werner ___ Freetype-devel mailing list

Re: [ft-devel] Who needs FT_CONFIG_OPTION_PIC?

Just to be clear, why is the PIC macro needed? Why isn't it enough to use -fPIC? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Who needs FT_CONFIG_OPTION_PIC?

>> Hence, who needs FT_CONFIG_OPTION_PIC today? > > I suggest that we remove the FT_CONFIG_OPTION_PIC code completely, > as David Turner suggested > . OK, let's do that after the next release. Werner

Re: [ft-devel] Who needs FT_CONFIG_OPTION_PIC?

On Fri, Mar 30, 2018 at 9:14 AM, Alexei Podtelezhnikov wrote: > Hence, who needs FT_CONFIG_OPTION_PIC today? > I hear crickets and I am not surprised: BREW is basically abandoned, RVCT evolved to support bare-metal PIE generation. I suggest that we remove the

Re: [ft] Off by one error in freetype (or in programmer?)

>> Just for completeness: Bitmap cell 0 is from coordinate 0 to 1, bitmap >> cell 1 is from 1 to 2, ..., bitmap cell 655 is from 655 to 656. > > I'm not sure I understand this - are you saying that the > rasterization goes *between* the rows, not on them? i.e., for a > glyph which hypothetically

Re: [ft] Off by one error in freetype (or in programmer?)

>> So, I may be about to embarrass myself, because fencepost errors >> are like that, but here goes. If I look at the glyph /H in Source >> Sans Pro in a font editor, the top right bound is a point at >> (562,656) and the bottom left point is at (90,0). > > You compute correctly width (472) and

Re: [ft] Off by one error in freetype (or in programmer?)

Hello Simon, You compute correctly width (472) and height (656) of bitmap. So addressable rows are 0 to 655 (included) - row 0 is 1st line, row 1 is 2nd line and so on. So you cannot access row 656 which is 657th line. - Laco. Dňa 5.4.2018 11:14 AM použÃvateľ Simon Cozens

[ft] Off by one error in freetype (or in programmer?)

So, I may be about to embarrass myself, because fencepost errors are like that, but here goes. If I look at the glyph /H in Source Sans Pro in a font editor, the top right bound is a point at (562,656) and the bottom left point is at (90,0). If I were to think about this as a bitmap, I can