[GRASS5] dxf imports

GRASS GRASS developer
1

Folks,

I've been contemplating what needs to be done to integrate and improve
the
dxf import capabilities in GRASS. My major problem centers around
importing and displaying text.

The most well-developed GNU-licensed DXF import library I've found
(DIME)
apparently doesn't import text entities. Currently I use a fairly
simple
program to extract text entities from a dxf file and store them in a
paint
labels file. This process works very well if the paint labels are then
used in ps.map. It doesn't work well on the GRASS display; because
paint.labels doesn't understand text rotation, transparent backgrounds
and a number of other text features.

So I have a few short questions that y'all might be able to help with.

1) Are there other dxf import libraries that I'm overlooking?

2) Does GRASS have other text-display capabilities that I'm overlooking?

3) If the answer to 2) is no then is anyone maintaining/upgrading the
paint.labels package and do you expect that paint.labels (and its
cousins)
will be maintained in the future?

Help is appreciated.

Roger Miller
Lee Wilson and Associates

2

"Roger S. Miller" wrote:

The most well-developed GNU-licensed DXF import library I've found (DIME)
apparently doesn't import text entities. Currently I use a fairly simple
program to extract text entities from a dxf file and store them in a paint
labels file. This process works very well if the paint labels are then
used in ps.map. It doesn't work well on the GRASS display; because
paint.labels doesn't understand text rotation, transparent backgrounds
and a number of other text features.

I think Grass lacks a "d.text" function, and probably a better support
for fonts. the best would be a support for TrueType fonts, usable on
both Unix and Windows.

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

3

Michel Wurtz wrote:

> The most well-developed GNU-licensed DXF import library I've found (DIME)
> apparently doesn't import text entities. Currently I use a fairly simple
> program to extract text entities from a dxf file and store them in a paint
> labels file. This process works very well if the paint labels are then
> used in ps.map. It doesn't work well on the GRASS display; because
> paint.labels doesn't understand text rotation, transparent backgrounds
> and a number of other text features.

I think Grass lacks a "d.text" function, and probably a better support
for fonts. the best would be a support for TrueType fonts, usable on
both Unix and Windows.

Are there many (any?) free TrueType fonts available?

The existing font mechanism may be primitive, but it does provide a
high degree of portability. No additional fonts are required, and it
can be made to work on any device which can draw lines.

--
Glynn Clements <glynn.clements@virgin.net>

4

Roger S. Miller wrote:

I've been contemplating what needs to be done to integrate and improve the
dxf import capabilities in GRASS. My major problem centers around
importing and displaying text.

The most well-developed GNU-licensed DXF import library I've found (DIME)
apparently doesn't import text entities. Currently I use a fairly simple
program to extract text entities from a dxf file and store them in a paint
labels file. This process works very well if the paint labels are then
used in ps.map. It doesn't work well on the GRASS display; because
paint.labels doesn't understand text rotation, transparent backgrounds
and a number of other text features.

So I have a few short questions that y'all might be able to help with.

1) Are there other dxf import libraries that I'm overlooking?

2) Does GRASS have other text-display capabilities that I'm overlooking?

The display architecture has support for text rotation, but it has
been disabled in a number of places. Also, the functionality isn't
exposed by any user program (e.g. d.text).

If it would be useful, I can look into re-enabling the rotation
support, and exposing it, either with an option to d.text, or a
separate d.text.rotation program (the rotation persists between
clients).

3) If the answer to 2) is no then is anyone maintaining/upgrading the
paint.labels package and do you expect that paint.labels (and its
cousins) will be maintained in the future?

Is there any reason for maintaining the "paint" system? AFAICT, most
of its functionality is available via "ps.map", and Ghostscript
supports far more printers than the "paint" system.

--
Glynn Clements <glynn.clements@virgin.net>

5

On Tue, Dec 18, 2001 at 06:48:13PM +0000, Glynn Clements wrote:

Roger S. Miller wrote:

> I've been contemplating what needs to be done to integrate and improve the
> dxf import capabilities in GRASS. My major problem centers around
> importing and displaying text.
>
> The most well-developed GNU-licensed DXF import library I've found (DIME)
> apparently doesn't import text entities. Currently I use a fairly simple
> program to extract text entities from a dxf file and store them in a paint
> labels file. This process works very well if the paint labels are then
> used in ps.map. It doesn't work well on the GRASS display; because
> paint.labels doesn't understand text rotation, transparent backgrounds
> and a number of other text features.
>
> So I have a few short questions that y'all might be able to help with.
>
> 1) Are there other dxf import libraries that I'm overlooking?
>
> 2) Does GRASS have other text-display capabilities that I'm overlooking?

The display architecture has support for text rotation, but it has
been disabled in a number of places. Also, the functionality isn't
exposed by any user program (e.g. d.text).

If it would be useful, I can look into re-enabling the rotation
support, and exposing it, either with an option to d.text, or a
separate d.text.rotation program (the rotation persists between
clients).

When enabled, it may become possible to print text labels along
vector lines (useful for contours on d.vect.labels). However,
that may be a non-trivial task.

> 3) If the answer to 2) is no then is anyone maintaining/upgrading the
> paint.labels package and do you expect that paint.labels (and its
> cousins) will be maintained in the future?

Is there any reason for maintaining the "paint" system? AFAICT, most
of its functionality is available via "ps.map", and Ghostscript
supports far more printers than the "paint" system.

The only usage I know is the (oldish) GRASSLinks. However, there
is a license conflict in GRASSLinks (see other mailing list).
Anyone using the paint driver? [MapServer does a nice job, when
libgrass from Frank Warmerdam also supports vector and sites data,
there is no reason to think about GRASSLinks].

Markus

6

The following book just published may be of interest to many of you.

Spatial Databases with application to GIS by Philippe Rigaux,
Michel Scholl and Agnès Voisard published by Morgan Kaufmann,
ISBN 1-55860-588-6.

It treats heavily of vector GIS.

It is a recommandation of one of my collegues.

Yours.

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

7

On Tue, 18 Dec 2001, Robert [iso-8859-1] Lagacé wrote:

The following book just published may be of interest to many of you.

Spatial Databases with application to GIS by Philippe Rigaux,
Michel Scholl and Agnès Voisard published by Morgan Kaufmann,
ISBN 1-55860-588-6.

  I bought a copy a couple of months ago and I'm about 2/3 of the way
through it. An excellent book.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
                         http://www.appl-ecosys.com

8

Glynn Clements wrote:

> The display architecture has support for text rotation, but it has
> been disabled in a number of places. Also, the functionality isn't
> exposed by any user program (e.g. d.text).
>
> If it would be useful, I can look into re-enabling the rotation
> support, and exposing it, either with an option to d.text, or a
> separate d.text.rotation program (the rotation persists between
> clients).

To which Markus replied...

When enabled, it may become possible to print text labels along
vector lines (useful for contours on d.vect.labels). However,
that may be a non-trivial task.

I don't know that setting one rotation for all text in a display (as
Glynn seems to be describing) is generally useful. The text entity in
dxf files specifies a rotation (0 by default) for each instance. That
can be done with paint labels files and ps.map. In the only graphics
systems I've worked with (OS/2 -- similar to old Windows NT) it was very
easy to rotate text and I'm surprised that it's apparently so difficult
to do for GRASS.

> > 3) If the answer to 2) is no then is anyone maintaining/upgrading the
> > paint.labels package and do you expect that paint.labels (and its
> > cousins) will be maintained in the future?
>
> Is there any reason for maintaining the "paint" system? AFAICT, most
> of its functionality is available via "ps.map", and Ghostscript
> supports far more printers than the "paint" system.

The only usage I know is the (oldish) GRASSLinks. However, there
is a license conflict in GRASSLinks (see other mailing list).
Anyone using the paint driver? [MapServer does a nice job, when
libgrass from Frank Warmerdam also supports vector and sites data,
there is no reason to think about GRASSLinks].

The only practical use I know of for the paint system is the use of the
paint labels files in ps.map. I need the capability provided by the
paint labels files, but I would prefer it if the files themselves could
be moved to a different location in the data base.

Roger Miller
Lee Wilson and Associates

9

Roger S. Miller wrote:

> > The display architecture has support for text rotation, but it has
> > been disabled in a number of places. Also, the functionality isn't
> > exposed by any user program (e.g. d.text).
> >
> > If it would be useful, I can look into re-enabling the rotation
> > support, and exposing it, either with an option to d.text, or a
> > separate d.text.rotation program (the rotation persists between
> > clients).

To which Markus replied...

> When enabled, it may become possible to print text labels along
> vector lines (useful for contours on d.vect.labels). However,
> that may be a non-trivial task.

I don't know that setting one rotation for all text in a display (as
Glynn seems to be describing) is generally useful. The text entity in
dxf files specifies a rotation (0 by default) for each instance.

Well, R_text_rotation() would (if it were fully implemented) affect
subsequent drawing commands. A DXF importer would presumably set the
rotation for each text entity.

I'll re-enable the text rotation code. Even if it doesn't work
correctly in the general case, it won't affect anything for the case
where the rotation is zero (the method of disabling was to replace the
return values from sin() and cos() with 0 and 1 respectively).

--
Glynn Clements <glynn.clements@virgin.net>

10

On Tue, 18 Dec 2001 18:48:04 +0000, Glynn Clements <glynn.clements@virgin.net> wrote:

> I think Grass lacks a "d.text" function, and probably a better support
> for fonts. the best would be a support for TrueType fonts, usable on
> both Unix and Windows.

Are there many (any?) free TrueType fonts available?

Yes/No. Depends on the use of free. You can download basic TrueType
fonts from MicroSoft, and there are lots of crappy free fonts the
can be downloaded and used at no cost. There's also a few fonts
out of the OpenOffice/StarOffice package that are now available
separately. Distribution of a lot of "free" fonts is often restricted...

The existing font mechanism may be primitive, but it does provide a
high degree of portability. No additional fonts are required, and it
can be made to work on any device which can draw lines.

Yes, but those fonts aren't very pretty either. Also, who even understands
the binary format used in GRASS? I've looked at that code that converts
the original fonts to something, but I've no idea what...

I'd propose supporting X bitmapped, PostScript, and TrueType fonts.
The rasterizers already exist and it'd open up a lot of possibilities.

BTW: I have a partly completed set of Cartographic Map Symbols as
a PostScript font. It'd be nice to be able to use such things for
display and PostScript map output.

--
Eric G. Miller <egm2@jps.net>

11

Eric G. Miller wrote:

> > I think Grass lacks a "d.text" function, and probably a better support
> > for fonts. the best would be a support for TrueType fonts, usable on
> > both Unix and Windows.
>
> Are there many (any?) free TrueType fonts available?

Yes/No. Depends on the use of free. You can download basic TrueType
fonts from MicroSoft, and there are lots of crappy free fonts the
can be downloaded and used at no cost. There's also a few fonts
out of the OpenOffice/StarOffice package that are now available
separately. Distribution of a lot of "free" fonts is often restricted...

A reasonable definition of free might be "could be distributed with
GRASS". I think that there should be a minimum set which can be
included in the distribution (ideally including one for Greek) so that
scripts and examples don't need to be modified for the user's system.

There's also the issue that the font's licensing terms may be
propagated into any image or hardcopy which contains that font,
affecting the terms under which the user can licence their output.

> The existing font mechanism may be primitive, but it does provide a
> high degree of portability. No additional fonts are required, and it
> can be made to work on any device which can draw lines.

Yes, but those fonts aren't very pretty either.

As vectors, they're likely to be significantly less ugly than a
bitmapped font when scaled.

Also, who even understands
the binary format used in GRASS? I've looked at that code that converts
the original fonts to something, but I've no idea what...

The binary format is trivial. The file starts with an array containing
the offset of each character's definition. Each character is a 32-bit
integer count followed two arrays of <count> bytes; the first is the X
coordinates, the second is the Y coordinates.

I'd propose supporting X bitmapped, PostScript, and TrueType fonts.
The rasterizers already exist and it'd open up a lot of possibilities.

BTW: I have a partly completed set of Cartographic Map Symbols as
a PostScript font. It'd be nice to be able to use such things for
display and PostScript map output.

Well, PostScript remains a strong candidate for a future display
architecture. It also solves the availability issue; high-res fonts
come with the printer, low-res fonts are free (from X11).

However, that's for the future. In the meantime, I'd like to avoid
users being forced to choose between buying fonts or having to put up
with scaled bitmaps.

--
Glynn Clements <glynn.clements@virgin.net>

12

On Wed, 19 Dec 2001 04:40:51 +0000, Glynn Clements <glynn.clements@virgin.net> wrote:

Eric G. Miller wrote:

[snip]

> > Are there many (any?) free TrueType fonts available?
>
> Yes/No. Depends on the use of free. You can download basic TrueType
> fonts from MicroSoft, and there are lots of crappy free fonts the
> can be downloaded and used at no cost. There's also a few fonts
> out of the OpenOffice/StarOffice package that are now available
> separately. Distribution of a lot of "free" fonts is often restricted...

A reasonable definition of free might be "could be distributed with
GRASS". I think that there should be a minimum set which can be
included in the distribution (ideally including one for Greek) so that
scripts and examples don't need to be modified for the user's system.

Ahh, well for most "text" purposes, I don't think GRASS should want
to worry about distributing fonts (unless we create our own). BTW,
I see a package for a free truetype font that supposedly includes
a Greek set (ahh, but no extended Greek, mean anything to you?).

There's also the issue that the font's licensing terms may be
propagated into any image or hardcopy which contains that font,
affecting the terms under which the user can licence their output.

I've had to deal with this issue, so I know what you're talking about.
I haven't encountered a problem with hardcopy, but things like PDF or
PostScript where the font is embedded...

> > The existing font mechanism may be primitive, but it does provide a
> > high degree of portability. No additional fonts are required, and it
> > can be made to work on any device which can draw lines.
>
> Yes, but those fonts aren't very pretty either.

As vectors, they're likely to be significantly less ugly than a
bitmapped font when scaled.

Point taken.

> Also, who even understands
> the binary format used in GRASS? I've looked at that code that converts
> the original fonts to something, but I've no idea what...

The binary format is trivial. The file starts with an array containing
the offset of each character's definition. Each character is a 32-bit
integer count followed two arrays of <count> bytes; the first is the X
coordinates, the second is the Y coordinates.

Ahh, should've looked at the code that reads those files...

> I'd propose supporting X bitmapped, PostScript, and TrueType fonts.
> The rasterizers already exist and it'd open up a lot of possibilities.
>
> BTW: I have a partly completed set of Cartographic Map Symbols as
> a PostScript font. It'd be nice to be able to use such things for
> display and PostScript map output.

Well, PostScript remains a strong candidate for a future display
architecture. It also solves the availability issue; high-res fonts
come with the printer, low-res fonts are free (from X11).

However, that's for the future. In the meantime, I'd like to avoid
users being forced to choose between buying fonts or having to put up
with scaled bitmaps.

Well, I wouldn't propose anything drastic at this point. I thought we
were trying get to a "finish" line for 5.0...

--
Eric G. Miller <egm2@jps.net>