[GRASS-dev] New OpenGL options to test for native Mac and Win NVIZ

Glynn Clements glynn at gclements.plus.com
Fri Jul 21 07:32:39 EDT 2006


William Kyngesburye wrote:

> > Yep. The stroke fonts can't be cross-compiled; the build process
> > compiles the font tools (splitfont and font_2_bin) then tries to run
> > them to compile the fonts. Obviously, this won't work if the font
> > tools were built for a different platform.
> 
> Can this be changed?  Maybe moderize the internal fonts to PostScript  
> or TrueType (probably difficult),

True-type fonts are already supported. Abandoning stroke fonts
altogether is probably feasible now that GRASS no longer supports
graphics terminals such as the 4105.

> or either pick an endian for all  
> platforms, or add an endian tag at the beginning of the font files  
> and the font routines would know how to read them?

The issue isn't just endianness; that could be fixed easily enough. 
The font files in the GRASS distribution are in a fundamentally
different format to what the display drivers expect.

Essentially, the source files consist of a single font split into four
text files (hersh.oc[1-4]) plus a collection of "maps" (*.hmp) which
define substets of the complete font, The drivers expect each font in
a separate, binary file.

> > What it should probably do is to install the tools, the raw font data,
> > and a script, so that the process can be completed after everything
> > has been installed on the target system.
> 
> The problem is that, while for now with a unix-style install of a  
> universal binary GRASS on Mac OS X I can have both processor versions  
> available and install the correct font files according to PPC or  
> Intel Mac (or as you suggest process the raw data at install), in the  
> future someone (ie Lorenzo) will want to make a self-contained, drag- 
> n-drop installable grass.app, where there would be no install  
> scripts.  A run-time startup script could work in a pinch to rename  
> the correct copy for grass to use, or process the raw files.

So long as the files in CVS are in a different format to what the
drivers require, some form of compilation will be necessary.

As "make -C lib/fonts" only takes ~100ms (on a P3/800), it wouldn't be
particularly onerous (in performance terms) to make the display driver
read the text format directly instead of the binary version.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list