Re: [ft-devel] Patch to fix the ttsubpix implementation
> Guys, I'm not a hardcore C coder, and don't know about private RAM > allocation per-process, and how that's impacted by putting structs > inside of .c files instead of .h files. Of course, I'm willing to > understand why that's the case, I just don't necessarily know some > of that stuff. So, likely all code that I write is going to have > the potential of being implemented more efficiently by people with > more experience in coding. I don't really want to burden you guys > with "babying" me through the best way to implement code, but if you > can nudge me in the right direction sometimes that would be helpful. Don't worry! *Many* people are following the FreeType git repository, and only David (who currently doesn't follow regularly) has noticed it. His background as a developer for embedded systems has sharpened his eyes for such glitches. And thankfully he has some time again to contribute. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] severe problems with subpixel hinting
> Well, I'm trying to set a variable inside the execution context > during Ins_FDEF that will set compatibility mode to "on" for the > rest of the execution of glyph hinting for that entire face. OK. > I'm assuming that the FDEFs are only read once during the prep, and > not every time a glyph is loaded. Yes. > But, it "seems" (yes, a vague word) like compatibility mode isn't > always on during execution, even though I know that the function > opcode patterns were triggered, and compatibility_mode was set to > TRUE for that execution context. Have you tried to insert some debugging messages to check your problem? > So, that makes me wonder if my assumptions about the execution > context are even correct. Like, let's say that Times New Roman gets > loaded, and Ins_FDEF detects that compatibility_mode should be set > to TRUE. I set it as such, and then, Oxygen gets loaded, which sets > compatibility_mode to FALSE, because it's a modern font without the > triggering opcode patterns. You can only load a single font into an FT_Face structure. In real life, there are multiple faces used in parallel, managed by higher-level libraries. > Then, I load another glyph from Times New Roman. Will the execution > context for that glyph have compatibility_mode set to TRUE or FALSE? It *must* be TRUE in the FT_Face object which holds Times New Roman. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Patch to fix the ttsubpix implementation
On 13-01-17 02:13 AM, Werner LEMBERG wrote: > >> Guys, I'm not a hardcore C coder, and don't know about private RAM >> allocation per-process, and how that's impacted by putting structs >> inside of .c files instead of .h files. Of course, I'm willing to >> understand why that's the case, I just don't necessarily know some >> of that stuff. So, likely all code that I write is going to have >> the potential of being implemented more efficiently by people with >> more experience in coding. I don't really want to burden you guys >> with "babying" me through the best way to implement code, but if you >> can nudge me in the right direction sometimes that would be helpful. If you have some time to read, this is a good place to start: http://www.akkadia.org/drepper/dsohowto.pdf > Don't worry! *Many* people are following the FreeType git repository, > and only David (who currently doesn't follow regularly) has noticed > it. His background as a developer for embedded systems has sharpened > his eyes for such glitches. And thankfully he has some time again to > contribute. Werner, just don't rely too much on that. For example, I check most commits that go in, but when there's a big patchset, it's just not possible to *quickly* verify it, so I guess most people skip. behdad > > Werner > > ___ > Freetype-devel mailing list > Freetype-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/freetype-devel > -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] severe problems with subpixel hinting
It *must* be TRUE in the FT_Face object which holds Times New Roman. Ok, after more experimentation, it *does* detect and store compatibility_mode correctly when I store it in the TT_Face object. I am running into an odd issue with Firefox and TNR however. For some reason, the patterns are not detected with Times New Roman Regular. And I know that Ins_FDEF is being executed because I used debug messages. Perhaps I'll have to be even more verbose with the messages. I have not seen this problem with any other face I've tested, and it only happens in firefox. Any ideas what might cause that? Is it possible that firefox is doing something incorrectly? Other than that issue, it appears that I'm now able to detect when compatbility_mode should be activated instead of relying on hard coding! Thanks, Erik ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Patch to fix the ttsubpix implementation
If you have some time to read, this is a good place to start: http://www.akkadia.org/drepper/dsohowto.pdf Thanks Behdad, I'll check it out. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Patch to fix the ttsubpix implementation
Behdad Esfahbod wrote: > >> Guys, I'm not a hardcore C coder, and don't know about private RAM > >> allocation per-process, and how that's impacted by putting structs > >> inside of .c files instead of .h files. Of course, I'm willing to > >> understand why that's the case, I just don't necessarily know some > >> of that stuff. So, likely all code that I write is going to have > >> the potential of being implemented more efficiently by people with > >> more experience in coding. I don't really want to burden you guys > >> with "babying" me through the best way to implement code, but if you > >> can nudge me in the right direction sometimes that would be helpful. > > If you have some time to read, this is a good place to start: > > http://www.akkadia.org/drepper/dsohowto.pdf Reading that paper made my head hurt :) It's full of descriptions of various tricks and jumps through the hoops how to avoid limitations of dynamic libraries implementation under Linux which is based on old, questionable and inefficient design. This really has nothing to do with the problem David has fixed. -- Dmitry. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
