Re: [ft-devel] suggested improvement to FT_GlyphSlot_Embolden
> I am using FT_Glyphslot_Embolden and so far it seems to work quite > well. However, the default extra boldness (1/24 em) is too great > for my purposes, and ought to be settable via an argument, because > different values are needed at different times. For example, 1/32 em > is adequate for making DejaVu Sans Bold extra-bold. > > I therefore suggest the following changes. This looks good. However, I think a default boldness would be nice to retain. For example, the value 0 could indicate this. What do you think? Another problem is backwards compatibility. Inspite of being declared as alpha code I fear that we no longer are in the situation to change the API because it is included by default into the library :-( What about adding a new function instead, say, FT_Glyphslot_Set_Emboldening, to change the embolding value? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] suggested improvement to FT_GlyphSlot_Embolden
> If we can't change the existing function then I agree that a new one > is a good idea, but I would prefer FT_GlyphSlot_Embolden_By_Weight > or something like that to give an idea of the meaning of the new > parameter. OK. > Obviously the existing function would be re-implemented by a call to > the new one. OK. > By the way, the reason I felt free to change the signature of the > function was that the header file in the 2.3.4 version seemed to > imply that it was not yet part of the official API. Well, yes, but... David, what do you think? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] suggested improvement to FT_GlyphSlot_Embolden
Werner, I thought of using 0 as a default value but over the years I have come to dislike such special values, however cute they may seem at first; partly because I use a lot of APIs, as well as designing them, and it is just one more thing to remember. Default values are the province of the application designer, who can trivially write a wrapper to supply his preference. If we can't change the existing function then I agree that a new one is a good idea, but I would prefer FT_GlyphSlot_Embolden_By_Weight or something like that to give an idea of the meaning of the new parameter. I don't like the name FT_Glyphslot_Set_Emboldening so much because it suggests that a persistent value is being set, which is not the case. Obviously the existing function would be re-implemented by a call to the new one. By the way, the reason I felt free to change the signature of the function was that the header file in the 2.3.4 version seemed to imply that it was not yet part of the official API. Best regards, Graham -Original Message- From: Werner LEMBERG [mailto:[EMAIL PROTECTED] Sent: 25 July 2007 22:32 To: [EMAIL PROTECTED] Cc: freetype-devel@nongnu.org Subject: Re: [ft-devel] suggested improvement to FT_GlyphSlot_Embolden > I am using FT_Glyphslot_Embolden and so far it seems to work quite > well. However, the default extra boldness (1/24 em) is too great > for my purposes, and ought to be settable via an argument, because > different values are needed at different times. For example, 1/32 em > is adequate for making DejaVu Sans Bold extra-bold. > > I therefore suggest the following changes. This looks good. However, I think a default boldness would be nice to retain. For example, the value 0 could indicate this. What do you think? Another problem is backwards compatibility. Inspite of being declared as alpha code I fear that we no longer are in the situation to change the API because it is included by default into the library :-( What about adding a new function instead, say, FT_Glyphslot_Set_Emboldening, to change the embolding value? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] suggested improvement to FT_GlyphSlot_Embolden
On Thu, Jul 26, 2007 at 11:50:14PM +0200, Werner LEMBERG wrote: > > If we can't change the existing function then I agree that a new one > > is a good idea, but I would prefer FT_GlyphSlot_Embolden_By_Weight > > or something like that to give an idea of the meaning of the new > > parameter. FT_GlyphSlot_Embolden exists only for historial reasons, and is a wrapper to FT_Bitmap_Embolen and FT_Outline_Embolden. One can copy the code and modify it to suit his/her need. If new APIs are to be added, I would prefer to have FT_Glyph_Embolden and FT_Glyph_Oblique. Glyph transformations should be done to FT_Glyph, not to FT_GlyphSlot. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] suggested improvement to FT_GlyphSlot_Embolden
On Wed, 2007-07-25 at 17:32 -0400, Werner LEMBERG wrote: > > I am using FT_Glyphslot_Embolden and so far it seems to work quite > > well. However, the default extra boldness (1/24 em) is too great > > for my purposes, and ought to be settable via an argument, because > > different values are needed at different times. For example, 1/32 em > > is adequate for making DejaVu Sans Bold extra-bold. > > > > I therefore suggest the following changes. > > This looks good. However, I think a default boldness would be nice to > retain. For example, the value 0 could indicate this. What do you > think? > > Another problem is backwards compatibility. Inspite of being declared > as alpha code I fear that we no longer are in the situation to change > the API because it is included by default into the library :-( > > What about adding a new function instead, say, > FT_Glyphslot_Set_Emboldening, to change the embolding value? Given the emboldening sample in Maxim's recent article, can FreeType be made to have separate horizontal and vertical emboldening factors? > Werner -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] suggested improvement to FT_GlyphSlot_Embolden
> > > If we can't change the existing function then I agree that a new > > > one is a good idea, but I would prefer > > > FT_GlyphSlot_Embolden_By_Weight or something like that to give > > > an idea of the meaning of the new parameter. > > FT_GlyphSlot_Embolden exists only for historial reasons, and is a > wrapper to FT_Bitmap_Embolen and FT_Outline_Embolden. One can copy the > code and modify it to suit his/her need. > > If new APIs are to be added, I would prefer to have > FT_Glyph_Embolden and FT_Glyph_Oblique. Glyph transformations > should be done to FT_Glyph, not to FT_GlyphSlot. Chia-I, can you work on that? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
