[GRASS-dev] iconv a required dependency for using Freetype?

[Michael Barton]

Actually, I am trying to avoid having to do any more than I need to, to the
TclTk GUI so that I can focus my time on the wxPython development.

Interactive selection of display fonts seemed an important enough function
to add for a relatively small investment in time. But I'm mostly trying to
fix problems and leave new features to wxPython.

So it's more a matter of having to rebuild the widgets from a fairly easy
file selection dialog to a little more complicated listbox. But if this is
what is needed to avoid future breakage, I can try to do this.

Michael


On 5/7/07 10:58 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> On Mon, 7 May 2007, Michael Barton wrote:
> 
>> Then I'm not going to worry about implementing a different way of selecting
>> fonts that uses freetypecap in the TclTk GUI at the moment. It is working OK
>> now, so I'll leave well enough alone until this gets sorted out further.
> 
> If we remove the ability to set a Freetype-compatible font through the
> GRASS_FONT env var by specifying it's full filename, then it will no
> longer work though. Just thinking - I don't see any reason why the font
> selection dialog can not just take the list of font options from
> "d.font -l" and present this list in a drop down selection box to the
> user. It includes the stroke fonts and the Truetype etc. fonts available
> in freetypecap (or wherever they will be listed in the future), all in one
> list.
> 
> I was thinking perhaps you didn't want to have to rely on users having
> updated their freetypecap file with fonts on the system, and that is why
> you've offered the possiblity of choosing Freetype-compatible fonts
> directly from the directory most of them are typically stored in on the
> platform gis.m is running on? That would seem to be no longer relevant now
> that the freetypecap file (and in future, its replacement) are
> automatically generated to contain the fonts available on the system, i.e.
> the list from "d.font -l" is now more reliable as an indicator of all
> possible font choices - and simplifies things too as it doesn't need a
> separate choice/browsing mode for stroke and freetype fonts.
> 
> In that sense, using the d.font -l output directly will be I suppose more
> future-proof (I'm thinking of the new Python GUI too) than parsing
> freetypecap directly.
> 
> Paul
> 

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton