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

[Glynn Clements]

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>