[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