On Tue, Jan 13, 2009 at 12:09 AM, Luca <luca...@gmail.com> wrote: > For who asked: I wanted to write down an utility that given a Font can > enable a raise effect that major the size of 100%, 200%, ... > > Well in that case, it seems that knowing the "size" value passed to the constructor is only half of what you need to make a font at twice the size of the original. Wouldn't you need to know the first argument to the Font constructor as well - the filename/object parameter that determines the .ttf file to use as well? It seems like your api should take the arguments for the Font constructor (as opposed to Font objects), and then you can use whatever internal mechanism for tracking sizes you like (like say a Font wrapper that stores both the source ttf and the size - or maybe a font wrapper that stores the source, and has a dict of Font objects at different sizes and the client of the wrapper asks for the Font object of the size it wants)
> PS: you think that adding at C level a new font_size, readonly > attribute can be a valid request for future Pygame release? I think > that this can hovewer be useful... > > Sure, storing the size passed in to the constructor somewhere in the C object and adding a way to get at it is fairly easy. However I don't see any point in adding it at the moment, cause it seems clearly insufficient to to solve the problem you want it for because you still need the filename/object argument to the constructor to be able to make another Font object with the same source at a different size, and storing the filename/object that represents the source of the font in the c object would be problematic for others (it would keep a lock on the ttf file if an file object were used as the source of the font, and keep file-like objects around in a way users might not expect) Moreover, I think exposing that original point size argument can be misleading - it implies it has some meaning to the metrics of the font, which in the world of ttf's, it really doesn't cause font designers can do whatever they want. I personally think you are best off solving this in the python world (as opposed to c world), and making your library the one that constructs Font objects from arguments passed in by clients, not one that accepts Font objects directly. or are there some other issues or difficulties that I'm missing?
