freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ft-devel] suggested improvement to FT_GlyphSlot_Embolden


From: Graham Asher
Subject: RE: [ft-devel] suggested improvement to FT_GlyphSlot_Embolden
Date: Thu, 26 Jul 2007 10:23:01 +0100

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:address@hidden 
Sent: 25 July 2007 22:32
To: address@hidden
Cc: address@hidden
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]