Re: [ft-devel] Question on glyph outline rendering for openType
I would like to load a font , get it's glyph outline and then render it as a path so that I can fill the glyph with custom stuff such as gradients and patterns.I have seen examples of this for free Type and true Type in win32. This has been answered on comp.fonts. I wish to know if this is possible with OpenType? and my targeted platform is win32. Yes, FreeType 2 supports OpenType fonts, but what you want to do is not FreeType's primary target. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Revisiting LSB [2]
Sorry for replying that late. I tried to do it in time but obviously my message didn't get through. Checking the archive I found this message missing which I still had a copy of. I try again. I'm no expert in font rasterisation and in FreeType's approach on that matter. There are many members of this list who are experts in both subjects, first of all, David and Werner, the creators (?) of FreeType. George Williams writes: My claim is that there is no single correct answer. There may be many good solutions. This is correct but I still think that this fact doesn't imply that it isn't possible to set up a test suite. As far as I understand FreeType will generate a certain rasterisation result depending on the parameter settings and the environment it detects. There might be and probably will be other rasterisation results which are good or even better but they aren't generated by FreeType because the algorithms chosen simply don't generate them. If the cache system were replaced, extended or improved e.g. the rasterisation results should still be the same. And exactly this kind of fact should be proven by a test suite. There could be other aspects included within the test suite like memory used or time consumed. It would be a good thing to include those additional parameters to avoid surprises but it is not that simple to collect the data and compare them in a meaningful way. Perhaps with truetype, with the bytecode interpreter turned on there is a deterministic process which should always produce the same answer. But with the autohinter (or postscript hints) I do not believe this is the case. Requiring such leaves no room for improvement of hinting. It seems that we're still talking about slightly different things. So far I don't see why some bits of the rasterisation result are randomly set. Which part of FreeType does introduce random? Of course, after improving the rasterisation algorithm checking the result by a human being is required and the data of the test suite which are used while comparing the results when the test suite is executed have to be replaced by the new samples. But even in that case a test suite might well be helpful as not necessarily all generated glyphs get a new shape. Work can then be focussed upon the ones that have changed. I would appreciate it if one of the experts shed some light on that. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] comp is reserved word in Apple SC compiler?
On 2005-10-28 13:11, [EMAIL PROTECTED] said: OSStatus status = FMCreateFontFamilyIterator( NULL, NULL, options, famIter ); -FMFontthe_font = NULL; -FMFontFamily family = NULL; +FMFontthe_font = ( FMFont ) NULL; +FMFontFamily family = ( FMFontFamily ) NULL; gcc 4 on Mac OS X gives a warning about this too. As you said, FMFont is not a pointer but an integer. Using 0 I think is the best solution. -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Revisiting LSB [2]
On Fri, 2005-10-28 at 03:54, Ulrich wrote: This is correct but I still think that this fact doesn't imply that it isn't possible to set up a test suite. As far as I understand FreeType will generate a certain rasterisation result depending on the parameter settings and the environment it detects. There might be and probably will be other rasterisation results which are good or even better but they aren't generated by FreeType because the algorithms chosen simply don't generate them. The algorithms used by FreeType change over time. Perhaps with truetype, with the bytecode interpreter turned on there is a deterministic process which should always produce the same answer. But with the autohinter (or postscript hints) I do not believe this is the case. Requiring such leaves no room for improvement of hinting. It seems that we're still talking about slightly different things. So far I don't see why some bits of the rasterisation result are randomly set. Which part of FreeType does introduce random? Sorry. I mean that using the bytecode interpreter it might be possible to define a correct result for a glyph. Using the autohinter it is not possible because today's autohinter is different from last year's. If the autohinter chooses to move a spline a little bit more to the left because we think it looks better today that will invalidate all test suites based on the previous behavior. Of course, after improving the rasterisation algorithm checking the result by a human being is required and the data of the test suite which are used while comparing the results when the test suite is executed have to be replaced by the new samples. That's why I believe the testsuite is useless. I think this will happen far too frequently, that the overhead involved in checking minor changes will not be worth the results gained. It is not like a compiler testsuite where there is only one right answer (except possibly in the case above). So any change to the autohinter will probably introduce irrelevant changes in the results which will require much checking and correction. But even in that case a test suite might well be helpful as not necessarily all generated glyphs get a new shape. It's more than just shape. It's the difference between a pixel having 0xfe and 0xfd. Work can then be focussed upon the ones that have changed. I would appreciate it if one of the experts shed some light on that. Anyway that remains my opinion. Your view keeps being repeated, so obviously I am not convincing. Perhaps if you write the testsuite and show that it is useful you can confound me. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Revisiting LSB [4]
On Fri, 2005-10-28 at 14:38, Ulrich wrote: It's more than just shape. It's the difference between a pixel having 0xfe and 0xfd. Sorry for using the wrong term shape. It should have been result. I assume that every single change in the result has to be checked as one pixel being on or off might have a servere impact on the result's quality. It's not a black white bitmap any more. It's a grey scale image. So it's not just a pixel changing from black to white, it's a pixel changing from 0xfd to 0xfe or whatever. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
