[ft-devel] Re: FT_MAX_CURVE_DEVIATION vs ONE_PIXEL cont'd
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, I'm going to apply your patch. However, you are changing ONE_PIXEL/8 back to ONE_PIXEL/4. Is this intended? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: FT_MAX_CURVE_DEVIATION vs ONE_PIXEL cont'd
On Mon, Nov 1, 2010 at 2:44 PM, Werner LEMBERG w...@gnu.org wrote: 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. I'm going to apply your patch. However, you are changing ONE_PIXEL/8 back to ONE_PIXEL/4. Is this intended? Yes. This exactly corresponds to 2.4.3. The quality in 2.4.3 is good (see previously communicated images). This also makes sense because dx can be as much as *double* the distance from the control point to the center of the chord. I just want to go back in line with 2.4.3 and use it as a stable benchmark for my future patches. ___ 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
I also consider conic0.png to be slightly better (I did the blind test *before* reading Werner's response). Yes, conic0 == 2.4.3, conic_0 == HEAD The attached is hinted rendering now. Look for differences between e's and o's. The most notable difference is the rendering of `s' IMHO (e.g. at 23 ppem). hinted_conic.png is much better; in this image, it's no longer a personal opinion... How shall we proceed? Werner ___ 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
Hello all, On Fri, Oct 22, 2010 at 7:12 AM, Werner LEMBERG w...@gnu.org wrote: Don't hurry. Both Graham and Bevan are busy people (and me too), so it will take a while to get proper responses. However, I second Graham's request for images which help a lot in the discussion. Attention: blind test. Check the quality of o's. The better image is vanilla 2.4.3. The worse image is the HEAD. I consider conic0.png the better image. However, the differences are very subtle. I also consider conic0.png to be slightly better (I did the blind test *before* reading Werner's response). Regards, -- Leon ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: FT_MAX_CURVE_DEVIATION vs ONE_PIXEL cont'd
Don't hurry. Both Graham and Bevan are busy people (and me too), so it will take a while to get proper responses. However, I second Graham's request for images which help a lot in the discussion. Attention: blind test. Check the quality of o's. The better image is vanilla 2.4.3. The worse image is the HEAD. I consider conic0.png the better image. However, the differences are very subtle. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[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
