[GRASS-user] Freetype fonts in gis.m

[Michael Barton]

They DO look MUCH better if you use d.font.freetype. And
v.label/d.paint.labels has become quite sophisticated. However, because they
are rasterized in the display, such text and decorations don't look as good
if you enlarge them. I'm quite happy with it for PowerPoint and
publications. 

However, I understood the (original) question to be about how to get high
quality cartographic output. For this, you really need postscript text,
decorations, and vectors--and GRASS doesn't do that yet except ps.map, and
for only labels and text in the gis.m.

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

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



> From: Hamish <hamish_nospam at yahoo.com>
> Date: Mon, 12 Jun 2006 16:06:44 +1200
> To: Glynn Clements <glynn at gclements.plus.com>
> Cc: <michael.barton at asu.edu>, <grassuser at grass.itc.it>
> Subject: Re: [GRASS-user] Freetype fonts in gis.m
> 
>> Michael Barton wrote:
>>> Currently, the only way to have them produce high-quality output is
>>> to render them in the GUI (e.g., as TclTk postscript objects). Could
>>> the relevant d.* commands (e.g., d.legend, d.text, d.label) be
>>> changed to optionally output postscript some something that would
>>> scale and display well? Or does this need to be done in the GUI?
> 
> I think this is could be interpreted incorrectly - this only pertains to
> good looking fonts in the new GUI window.
> 
> d.font.freetype + d.legend etc look great on the display monitor -as
> rendered-. Grid lines, legends, arrows, barscale decorations all have
> the same problem wrt rescaling. Hint: Run a narrow blur filter on the
> graphic before resizing and it looks better.
> 
> For hardcopy output ps.map fonts look very nice too.
> 
> The GUI is very nice, but you do not have to use it to get nice results.
> 
> 
> 
> Glynn Clements wrote:
>> Ideally, we need to:
>> 
>> a) make a distinction between setting the font in a persistent manner
>> (for d.font[.freetype]) and setting the font internally for a single
>> client (e.g. "d.vect ... font=...", or the .F operator in d.text).
>> 
>> b) modify modules which use R_text() to accept font= and charset=
>> options to eliminate the need for d.font[.freetype] (which doesn't
>> work well with command layers).
> 
> Adding FONT or FTFONT to GISRC and having d.font[.freetype] modify that
> via g.gisenv or equiv. is a good idea. Hacking in font= etc into
> G_parser()* is a huge pain when you have multiple commands that draw
> text and/or use d.redraw. I don't want to have to retype that for every
> command, and I do want a consistent font between different decorations.
> Just adding font= for the first d.* command is non-intuitive.
> 
> * adding font= to every module that uses R_text() is just too ugly
> 
> 
> 
> Hamish