[GRASS5] grass font

[Radim Blazek]

On Fri 15. June 2001 17:07, Glynn Clements wrote:
> There are three basic types of fonts: stroked, outline and bitmap.
>
> GRASS fonts are stroked fonts; these correspond to the way in which
> you write with a pen on paper.
>
> PostScript and TrueType fonts are (usually) outline fonts; you could
> convert these to stroked fonts, but the end result would be "hollow"
> characters. 

Even hollow characters would be help at his time for those who use ps.map
because editing by d.labels would be possible. 

> You can display a font on any platform, if you can obtain the font
> definition; the main issue here is copyright. Otherwise, you have to
> limit yourself to fonts which you know will exist on any platform;
> unfortunately this probably limits you to Helvetica, Times and
> Courier. Users of languages which use encodings other than ISO-8859-1
> are out of luck; many systems won't have any fonts for non-European
> languages.

I don't think this is a problem. If user need to work in more languages 
he/she must install appropriate fonts. I found following fonts on my RH7.1 CD:

intlfonts-Asian-1.2-1 intlfonts-Ethiopic-1.2-1 intlfonts-Chinese.BIG-1.2-1
intlfonts-Chinese.X-1.2-1 intlfonts-Chinese-1.2-1 intlfonts-Japanese.BIG-1.2-1
intlfonts-Japanese.X-1.2-1 intlfonts-Japanese-1.2-1 intlfonts-Korean.X-1.2-1
intlfonts-Misc-1.2-1 intlfonts-TrueType-1.2-1 intlfonts-Type1-1.2-1
kon2-fonts-0.3.9b-6 ttfonts-1.0-3 XFree86-cyrillic-fonts-4.0.3-5
XFree86-ISO8859-2-Type1-fonts-4.0.3-5  XFree86-ISO8859-2-100dpi-fonts-4.0.3-5
XFree86-ISO8859-7-Type1-fonts-1.0-9 XFree86-ISO8859-7-100dpi-fonts-1.0-9
XFree86-ISO8859-7-75dpi-fonts-1.0-9 XFree86-ISO8859-9-100dpi-fonts-2.1.2-16
XFree86-ISO8859-9-75dpi-fonts-2.1.2-16 XFree86-jpfonts-2.0-12
XFree86-KOI8-R-100dpi-fonts-1.0-6 XFree86-KOI8-R-75dpi-fonts-1.0-6

> Font handling will be a major factor in determining any new display
> architecture.
>
> At present, potential architectures can be split into two categories:
>
> 1. Generate PostScript; all drivers (apart from one for a PostScript
> printer) would use ghostscript to do most of the work.
>
> 2. Do everything ourselves.
>
> Option 1 saves us a lot of work, but also imposes some restrictions.
> Option 2 is much more work (to do it right), but doesn't impose any
> restrictions.
>
> One of the advantages of using PostScript is that it provides a lot of
> desirable features "for free", e.g. affine transformations and
> (decent) text rendering. However, internationalisation issues may
> determine whether its text rendering is suitable; if it isn't, and we
> have to implement our own text renderer, this eliminates one of the
> biggest advantages of using it.

This is probably more general question if we need WYSIWYG or not.
I think that editing in WYSIWYG must be possible for creating final
outputs for printing. However I was thinking about using some sort of
WYSIWYM it may not be used in GIS because processing may not
be done automaticaly like in TeX. 

But editing in WYSIWYG is needed only for some tasks (labeling, legends, ...)
and for other tasks it is not desired (digitize, view/query on screen, ...). 
In my case, it would be about 80% NONWYSIWYG and 20% WYSIWYG.

If wysiwyg is not needed, wysiwyg system would be terribly slow (I think).
Remember that GIS is quite different from usual applications like text 
processing. In GIS we need to display very quickly thousands of lines and
texts (usually at least more than 10 000). We should have full control over
whole proces from source of data to calling XDrawText() or similar function.

Create our own system for WYSIWYG would be huge work (and never true
WYSIWYG), in cases it is required, we should use ghostscript.

So my conclusion is that 2 modes should be possible:
1. nonwysiwyg for common work, speed optimised 
2. wysiwyg for map finishing, slow, based on ghostscript


Radim