[GRASS-dev] Fonts (to be continued)

[tlaronde at polynum.com]

Hello,

Just to follow on from a previous mail about the Hershey's fonts, here
are some indications that might be of some value for your own reflection
about the subject.

The context
-----------

I needed, for a job about electrical network, needing to take as input
maps created with CAD, with singular points defined with oriented 
symbols, to produce a topologically correct map, and to complete
attributes with distinct fields, several being related to the symbol,
for example used by the client to display them correctly oriented (the
result has to be in ESRI's SHAPE).

Since all the informations come from maps built by entities unaware of
topology, and since everything coming from the field is in DXF files,
I needed the information about these symbols.
Furthermore, displaying a group name (category) with a Point was already
available, but it is far more easy and user friendly to display a symbol
in place of a name in v.digit(1).

So I needed:

- to recover the informations about the symbols in the BLOCKS section,
	work on v.in.dxf was needeD

- to display the symbols was one thing. But maps have to be produced
afterwards so keeping a description with the maximal precision of the
symbols, even if the display version is more approximate, was required;

- to have something that directly, or indirectly will be usable with
PostScript, since hardcopy is only PS in KerGIS.

Drawing facilities in GRASS/KerGIS
----------------------------------

The abstraction library for drawing in KerGIS is the DRAWLIB that was
the legacy RASTERLIB (it still is in GPL GRASS).

The legacy name was a misnommer. First, because raster is one important
module of GRASS (with vector and sites). Secondly because rasterizing is
the final stage before mapping an image on a raster view (whether a
display or a memory array). But The DRAWLIB does not rasterize. The 
drivers _may_ if needed.

Indeed, in KerGIS, the xdriver does not rasterize the vectorial data,
since XLIB has functions for that. 

Furthermore, many years ago, existed plotters that were vectorial
printers. One could have made a DRAWLIB driver to record displacements to
feed such a plotter.

The DRAWLIB has already everything to scale, rotate glyphes
(surprisingly, in the xdriver---that I have heavily reworked---the
original code for rotation was here but unused, the angle being
systematically reset to 0).

So the natural way to go was to create a font for the symbols.

The Hershey's fonts
-------------------

The Hershey's fonts are quite a complete set, with latin, cyrillic,
greek and asian glyphes.

These fonts are vectorial (but only polylines).

Contrary to some now established practices, the Hershey's fonts are put
in a small number of files, melting different styles.

Furthermore, some informations (like the nominal size etc) are put in
the documentation but are not encoded directly in the files describing
the fonts.

>From an historical point of view, the Hershey's fonts were undoubtly
great for plotters (for reasons stated above: plotters were vectorial
devices, not raster ones).

The files describing the glyphes are in a format best understood by
reading carefully what does the program that reads them (the files were
probably done with vi(1) if one takes into account the accrobatics about
maximum line widths).

The glyphes have a number (an order). Putting a glyph in an order that
matches some encoding is the role of the *.hmp files, that extract
glyphes with their Hershey's number to rearrange them according to the
encoding specified by the *.hmp (this encoding being ASCII with the
legacy hmp files).

If one wants another encoding, he creates other *.hmp files.

NOTE: in fact, I have already extended the syntax of the *.hmp. The goal
being to be able to create a virtual font, that is to compose glyphes,
leading to, for example, accented letters. At the moment, I have only
extended the *.hmp to give the full latin1, but without diacritics ( é
maps to e, È maps to E etc.)

ADVANTAGES:

First, we have (once the hmp is extended) our own set of fonts, which is
absolutely great.
Secondly, vectorial fonts are good for readability on displays, since
they scale naturally.

PROBLEMS:

With the actual state, it is difficult to create a WYSIWYG for
hardcopy since, at least, the Hershey's fonts are not translated in a 
font type recognized by PostScript. So, arrangement of the texts on
screen will not lead to exact result on hardcopy, since the paramaters 
of the fonts used (probably standard PostScript ones in ps files)
will be significantly different. 

SOLUTIONS:

The symbols are aside: they are better vectorial since they will scale
right and since a careful choice of the language of description (I have
chosen a subset of MetaPOST, which is a descendant of METAFONT) can
accommodate both a fast rendering (rectify version with no curves), and
an accurate printing (since this is the postscript version that is used,
where the symbol is algebraically described).

For the fonts, a wide range of possibilities exist, the problem being
the time needed to implement them.
One of them is to use METAFONT/TeX, in the "prepare hardcopy mode" to
create images of the text (leading to the use of the full power of TeX,
including mathematics) and display these images (background being
transparent) in the graphical interface just to verify or adjust the
result (since T1 exist for TeX, for normal text it will be possible
to use the standard PostScript fonts).

My solution for the moment
--------------------------

I have redone v.in.dxf(1) to use lex(1) and yacc(1) (Autodesk has
published now all the versions of the DXF formats; using lex(1) and
yacc(1) was a bit of a challenge to enforce the discover of rules that
the specifications do not make clear, to say the least) so that I'm able
to accept every version, print information about what is in there
(version, layers, number of elements by layers, extents etc.) and have
information about what I do not recognize (this version will not go in
the next public version of KerGIS due in the following weeks).

I treat the BLOCKS section to create a font with the symbols found
there. The descriptions are kept as a MetaPOST description, and a
reasonable resolution rectified version is created for display (the
binary font is only polylines; so I rectify arcs, bulges and circles;
curves will be added later---since I did not need them for at the moment).

Nothing had to be changed for displaying the symbols, rotated and scaled
(so that, indeed, they are "true ground size") except that the drawing 
of characters hardcoded the value for the baseline (these values have to
go in the font itself and should be initialized when loading a font). It
is reset for now to 0 and I still reflect about the extension of the
font binary format to put everything needed in it, while keeping its
present general construction---that is simple and efficient.

I also plan to convert the Hershey's descriptions in METAFONT so that I
can publish a document with all the glyphes rendered by TeX, and the
explanations about the historical format, the hmp (`virtual files') and
the new formats.
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C