[GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text

[Huidae Cho]

Removing the font_hold variable from lib/driver affects the behaviour of
freetype fonts.  All modules with font= option still assume "romans" as
default font and it keeps the user from using freetype fonts with them.

d.font font=luximr
d.vect map=vector_map

will use "romans" not "luximr". Maybe we need to use GRASS_FT_*
GRASS_FONT varibles to let d.* modules know the default font the user
wants.

Adding R_get_font_list() would be great. Its code can be simply cut and
pasted from d.font.

Huidae

On Fri, Sep 01, 2006 at 08:45:05PM +0100, Glynn Clements wrote:
> 
> Huidae Cho wrote:
> 
> > > > > > >> Is there any reason why those features can't be added to d.text?
> > > > > > 
> > > > > > > No, it's simply because nobody did it.  Hopefully, I'll sometime.
> > > > > > 
> > > > > > Would that let us drop d.text.freetype then?
> > > > > 
> > > > > Yes. And I'm thinking about merging d.font and d.font.freetype, if
> > > > > feasible.
> > > > 
> > > > I'd like to propose merging freetype and stroke fonts, so that
> > > > R_font() is used for both, with the type being detected automatically. 
> > > > This would allow the use of FreeType fonts in all modules.
> > > 
> > > By which, I didn't mean "go ahead and do it without discussing it with
> > > anyone, including the person who has done 95% of the recent work on
> > > the display architecture and will probably be doing a similar
> > > proportion of future work in that area".
> > > 
> > > Patch reverted. Again.
> > > 
> > > The right place to have done this would be lib/driver/Font.c.
> > > 
> > > lib/raster is supposed to be the bare minimum needed to dispatch R_*
> > > calls to either the local or remote driver. All of the actual
> > > functionality is supposed to go into either lib/driver or the
> > > individual drivers (lib/pngdriver or display/drivers/XDRIVER).
> > > 
> > > I'm currently testing the corresponding changes to lib/driver.
> > 
> > Glynn, I see.  Lessons learned.  I didn't mean to bother you with this.
> > Maybe, I forgot you have a better insight in the overall architecture of
> > the raster library.  I've reverted the changes that I made recently.
> 
> I've now made corresponding changes to lib/driver/Font.c.
> 
> COM_Font_get (which is where R_font() always ends up, one way or
> another) accepts either names or full paths. For full paths, if the
> path begins with $GISBASE/fonts, it's treated as a stroke font,
> otherwise a FreeType font (it's unlikely that anyone will have any
> suitable stroke fonts which aren't part of GRASS).
> 
> COM_Font_freetype_release() is now a no-op. Unless some reason is
> found why that needs to remain (and which isn't essentially a bug
> elsewhere), it (and its corresponding infrastructure) can be removed.
> 
> Once the merged R_font() has had sufficient testing, R_font_freetype()
> and its infrastructure can also be removed.
> 
> I've also re-instated the updated behaviour of d.font, so that it will
> accept either type of font for both font= and path=. I also fixed a
> bug (missing NUL-terminator; memory returned from G_{malloc,realloc}
> isn't guaranteed to be zeroed).
> 
> > One thing that I want to suggest is to replace freetypecap with
> > something better.  Keeping the font alias functionality is important for
> > portable scripting because each system has different directory structure
> > for TrueType fonts.
> 
> Agreed.
> 
> > But because of this, freetypecap is also different
> > from system to system, which is annoying.  One option could be
> > to auto-generate freetypecap.
> 
> Easier said than done. There isn't any automatic way to figure out
> where fonts live. The X server just uses the FontPath settings from
> xorg.conf (formerly XF86Config); on my system (Gentoo), they're in
> /usr/share/fonts (although there is a symlink from /usr/lib/X11/fonts
> to ../../share/fonts).
> 
> Currently, the freetypecap file is still coming from the
> display/d.text.freetype directory, although it can be moved to
> lib/driver if necessary.
> 
> > While looking into lib/raster, I found something strange.
> > select_font(), *_font_freetype(), *_charset(), and
> > *_font_freetype_release() return 1 on success while the others return 0.
> > Is this intended?
> 
> Sort of, probably. By which, I mean that there was probably some
> rationale for the original behaviour.
> 
> In the past, I've just preserved the behaviour whenever I have updated
> anything. Although almost nothing actually tests the status of most
> R_* functions, actually checking for any exceptions is too much work
> for too little gain.
> 
> However, I did make one change in this area (to a function not used
> outside of lib/driver): font_is_freetype() now returns 1/0, so that
> "if (font_is_freetype(...)) ..." behaves as it reads. Generally
> speaking, functions which are explicitly intended to test some
> property should return 1/0.
> 
> It's success/failure status returns which are ambiguous.
> 
> Programs return 0 for success, non-zero for failure, although the
> shell reflects this in the way that "if", "||", "&&" etc are handled
> (i.e. a zero exit code represents "true").
> 
> System calls normally return negative values for failure, as calls
> which also return useful information (descriptor, PID, etc) normally
> return non-negative values (descriptors, UIDs, PIDs etc are never
> negative, although some can be zero).
> 
> graphics.h defines OK as 0, with positive values used for errors.
> 
> Most graphics operations don't actually return any status. The only
> R_* functions whose return value actually reflects a status code from
> the driver are:
> 
> 	R_open_driver
> 
> 	R_color_table_float
> 	R_color_table_fixed
> 
> 	R_font
> 	R_font_freetype
> 	R_charset
> 	R_font_freetype_release
> 
> [R_screen_* return a value, not status (they can't fail), while
> R_get_num_colors and R_get_location_with_* store the values via
> pointers which are passed as arguments.]
> 
> Of the above, R_open_driver is probably the only case where programs
> generally bother to check the value.
> 
> Actually, there's no "probably"; I've just checked, and everything
> which uses one of the above font/colour-table functions ignores the
> return code.
> 
> Also, only two programs (d.text.freetype and i.class) use
> R_color_table_fixed. As nothing uses R_color_table_float (d.colormode
> isn't present in 6.x), and the driver starts in fixed mode, both of
> those functions are redundant.
> 
> In that case:
> 
> 1. I intend to remove the status returns from all R_* functions except
> for R_open_driver.
> 
> 2. Unless someone objects, I also intend to remove R_color_table_* and
> their associated infrastructure, including all of the driver code
> related to floating colour mode. That will remove a significant chunk
> of the complexity of the display architecture, and make it
> significantly easier to understand.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>