[GRASS5] Re: [NVIZ] Code for PPM dumps

GRASS GRASS developer
1

Hi Bob,

many thanks for your patches. I have applied them to CVS
(hope it's o.k. for all developers). The PPM format is
more common than the SGI image format. Probably a selection
window on image format would be perfect.

On Sun, Sep 24, 2000 at 10:51:04PM -0300, Bob Covill wrote:

Hello,

I am attatching to this e-mail the code I have added to NVIZ to dump
images to a PPM format. I have written out the installation steps, so
hopefully it is not to complicated.

The first two files that should be incorporated are "Gmakefile" and
"gsd_img_ppm.c". These two files should be copied to
"$GISBASE/src/libes/ogsf". The "gsd_img_ppm.c" is a modified version of
the routine to dump RGB files. It creates a new library routine entitled
"G_write_ppm".

Here your Gmakefile does not fit any more to the current Gmakefile as
file name conflicts on Windows had to be fixed earlier this summer. I
have adjusted it, it compiles o.k. now.

Note the image dump routine is byte order sensitive. The file
"gsd_img_ppm.c" is currently set for a big-endian machine (eg. SUN). To
build the library on a small-endian (linux) machine comment out lines 34
to 36, and uncomment lines 38 to 40. There is a note in the code where
this needs to be done. After copying the new files execute gmake5 to
rebuild the ogsf library.

Here I have inserted a #ifdef statement.

#ifdef SUN
/*big endian*/
  ...
else
/*little endian*/
  ...
#endif

I think something with config.h to detect little/big endian would be
better than hard-code the platform names here. Feel free to modify it.

The next two files; "anim_support.c" and "init_commands.c" should be
copied to $GISBASE/src.contrib/GMSL/NVIZ2.2/src. These files will
overwrite existing files. These files utilize the above PPM lib routine
and create an NVIZ command entitled "Nwrite_ppm". This is the command
that will be called from the nviz scripts. After adding the above two
files, execute gmake5 to rebuild the NVIZ2.2 executable to incororate
the new command.

After completing the above, three TCL scripts can be modified to execute
the new dumping routine. The scripts are; "nviz2.2_script",
"panel_animation.tcl", and "panel_kanimator.tcl". I have also attached
these three scripts. They can be placed in
$GISBASE/src.contrib/GMSL/NVIZ2.2/scripts.

With the above changes execute gmake5 from
$GISBASE/src.contrib/GMSL/NVIZ2.2 to install the updated scripts in the
proper location.

Images should now be dumped to a *.ppm format.

Yes, working o.k. on Linux (no bad magic number problems!).

If there are any problems or questions let me know. I have built and
used the routines on both a Sun Sparc and Linux.
--
Bob Covill

Tekmap Consulting
P.O. Box 2016
Fall River, N.S.
B2T 1K6
Canada

E-Mail: bcovill@tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498

Many thanks, Bob. Your contribution will become part of the next GRASS 5
release.

Kind regards

Markus Neteler

--
Dipl.-Geogr. Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Markus,

the big endian/little endian part of the code will give problems, as not
only sun machines are big-endian. There are more general solutions, have
a look at tifflib. There must be other code within grass where this
problem is solved, but i have currently no time to search. I don't know
exactly if a config-solution or a solution within the code is better,

cu,

Andreas

Markus Neteler wrote:

Hi Bob,

many thanks for your patches. I have applied them to CVS
(hope it's o.k. for all developers). The PPM format is
more common than the SGI image format. Probably a selection
window on image format would be perfect.

On Sun, Sep 24, 2000 at 10:51:04PM -0300, Bob Covill wrote:
> Hello,
>
> I am attatching to this e-mail the code I have added to NVIZ to dump
> images to a PPM format. I have written out the installation steps, so
> hopefully it is not to complicated.
>
> The first two files that should be incorporated are "Gmakefile" and
> "gsd_img_ppm.c". These two files should be copied to
> "$GISBASE/src/libes/ogsf". The "gsd_img_ppm.c" is a modified version of
> the routine to dump RGB files. It creates a new library routine entitled
> "G_write_ppm".
Here your Gmakefile does not fit any more to the current Gmakefile as
file name conflicts on Windows had to be fixed earlier this summer. I
have adjusted it, it compiles o.k. now.

> Note the image dump routine is byte order sensitive. The file
> "gsd_img_ppm.c" is currently set for a big-endian machine (eg. SUN). To
> build the library on a small-endian (linux) machine comment out lines 34
> to 36, and uncomment lines 38 to 40. There is a note in the code where
> this needs to be done. After copying the new files execute gmake5 to
> rebuild the ogsf library.

Here I have inserted a #ifdef statement.

#ifdef SUN
/*big endian*/
  ...
else
/*little endian*/
  ...
#endif

I think something with config.h to detect little/big endian would be
better than hard-code the platform names here. Feel free to modify it.

> The next two files; "anim_support.c" and "init_commands.c" should be
> copied to $GISBASE/src.contrib/GMSL/NVIZ2.2/src. These files will
> overwrite existing files. These files utilize the above PPM lib routine
> and create an NVIZ command entitled "Nwrite_ppm". This is the command
> that will be called from the nviz scripts. After adding the above two
> files, execute gmake5 to rebuild the NVIZ2.2 executable to incororate
> the new command.
>
> After completing the above, three TCL scripts can be modified to execute
> the new dumping routine. The scripts are; "nviz2.2_script",
> "panel_animation.tcl", and "panel_kanimator.tcl". I have also attached
> these three scripts. They can be placed in
> $GISBASE/src.contrib/GMSL/NVIZ2.2/scripts.
>
> With the above changes execute gmake5 from
> $GISBASE/src.contrib/GMSL/NVIZ2.2 to install the updated scripts in the
> proper location.
>
> Images should now be dumped to a *.ppm format.
Yes, working o.k. on Linux (no bad magic number problems!).

> If there are any problems or questions let me know. I have built and
> used the routines on both a Sun Sparc and Linux.
> --
> Bob Covill
>
> Tekmap Consulting
> P.O. Box 2016
> Fall River, N.S.
> B2T 1K6
> Canada
>
> E-Mail: bcovill@tekmap.ns.ca
> Phone: 902-860-1496
> Fax: 902-860-1498
>

Many thanks, Bob. Your contribution will become part of the next GRASS 5
release.

Kind regards

Markus Neteler

--
Dipl.-Geogr. Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984

----------------------------------------
If you want to unsubscribe from NVIZlist
mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe nvizlist'

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

On Tue, Sep 26, 2000 at 12:56:48PM +0200, Andreas Lange wrote:

Markus,

the big endian/little endian part of the code will give problems, as not
only sun machines are big-endian. There are more general solutions, have
a look at tifflib. There must be other code within grass where this
problem is solved, but i have currently no time to search. I don't know
exactly if a config-solution or a solution within the code is better,

cu,

Hi Andreas,
you are right. Here is the extracted test from libtiff:

CheckForBigEndian()
{
    echo 'main() { int one = 1; char* cp = (char*)&one; exit(*cp!=0); }'>t.c
    capture cat t.c
    runMake t "t:; ${CCOMPILER} ${ENVOPTS} t.c" && ./a.out
}

if CheckForBigEndian; then
        echo "#define HOST_BIGENDIAN 1"
        Note "... using big-endian byte order for your $CPU cpu"
    else
        echo "#define HOST_BIGENDIAN 0"
        Note "... using little-endian byte order for your $CPU cpu"
fi

It should be written to config.h.

Does anyone know how to implement this test into current "configure"?

Thanks

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

Hi all,

now the endian problem is fixed.

On Wed, Sep 27, 2000 at 04:16:44PM +0100, Markus Neteler wrote:

On Tue, Sep 26, 2000 at 12:56:48PM +0200, Andreas Lange wrote:
> Markus,
>
> the big endian/little endian part of the code will give problems, as not
> only sun machines are big-endian. There are more general solutions, have
> a look at tifflib. There must be other code within grass where this
> problem is solved, but i have currently no time to search. I don't know
> exactly if a config-solution or a solution within the code is better,

I have searched the code and found a test in
./src.contrib/GMSL/NVIZ2.2/TOGL/apps/image.c

    union {
        int testWord;
        char testByte[4];
    } endianTest;
    int swapFlag;

    endianTest.testWord = 1;
    if (endianTest.testByte[0] == 1) {
        swapFlag = 1;
    } else {
        swapFlag = 0;
    }

    if (swapFlag) {
     dothis; /*true: little endian */
    }
    else {
     dothat; /* big endian */
    }

It is implemented now in
src/libes/ogsf/gsd_img_ppm.c

Please report any problems.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

Hi again,

it is planned to generate all man/ and cat/ pages from
HTML (html/html/) and to remove the man+cat section from
CVS. There is a script "g.html2man" slightly doing this
job. But the quality is still poor as it does not
detect <p> (but <P>) and other tags. The script is
here:

src/scripts/contrib/g.html2man/g.html2man

written in PERL. Frank Warmerdam and me would be glad
if a PERL wizard could look at it and correct such bugs
(and probably implement missing standard tags).

Or: If you know a better script, we can even replace the
existing.

This should be an issue for GRASS 5 stable as it prevents
us from extra conversion work (to generate the MAN files).

Thanks for listening

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

Markus Neteler wrote:

Hi again,

it is planned to generate all man/ and cat/ pages from
HTML (html/html/) and to remove the man+cat section from
CVS. There is a script "g.html2man" slightly doing this
job. But the quality is still poor as it does not
detect <p> (but <P>) and other tags. The script is
here:

src/scripts/contrib/g.html2man/g.html2man

written in PERL. Frank Warmerdam and me would be glad
if a PERL wizard could look at it and correct such bugs
(and probably implement missing standard tags).

I won't claim to be a Perl guru :), but I'll take a look at it by next
week.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

Justin Hickey wrote:

Markus Neteler wrote:
>
> Hi again,
>
> it is planned to generate all man/ and cat/ pages from
> HTML (html/html/) and to remove the man+cat section from
> CVS. There is a script "g.html2man" slightly doing this
> job. But the quality is still poor as it does not
> detect <p> (but <P>) and other tags. The script is
> here:
>
> src/scripts/contrib/g.html2man/g.html2man
>
> written in PERL. Frank Warmerdam and me would be glad
> if a PERL wizard could look at it and correct such bugs
> (and probably implement missing standard tags).

I won't claim to be a Perl guru :), but I'll take a look at it by next
week.

Actually, I just took a quick look and it doesn't seem too difficult to
understand. Markus, if you want, we can take this off list and if you
are willing to tell me the problems you have, I can fix the script. For
example, fixing the <p> problem is a simple change. But I would like to
fix all known problems before committing the fixes to the CVS tree. What
do you think?

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

On Thu, Sep 28, 2000 at 09:56:56AM +0700, Justin Hickey wrote:

Justin Hickey wrote:
>
> Markus Neteler wrote:
> >
> > Hi again,
> >
> > it is planned to generate all man/ and cat/ pages from
> > HTML (html/html/) and to remove the man+cat section from
> > CVS. There is a script "g.html2man" slightly doing this
> > job. But the quality is still poor as it does not
> > detect <p> (but <P>) and other tags. The script is
> > here:
> >
> > src/scripts/contrib/g.html2man/g.html2man
> >
> > written in PERL. Frank Warmerdam and me would be glad
> > if a PERL wizard could look at it and correct such bugs
> > (and probably implement missing standard tags).
>
> I won't claim to be a Perl guru :), but I'll take a look at it by next
> week.

Actually, I just took a quick look and it doesn't seem too difficult to
understand. Markus, if you want, we can take this off list and if you
are willing to tell me the problems you have, I can fix the script. For
example, fixing the <p> problem is a simple change. But I would like to
fix all known problems before committing the fixes to the CVS tree. What
do you think?

Justin, that's really great (you are taking care already of so many
things!).
We can continue off-list to reduce traffic. Just to give you an idea:
All the html/html/ stuff shall be converted properly... I have implemented
once &nbsp; tag, but for me it is very time consuming (as not being PERL
experienced). Therefore I was asking.

What's missing:
- small letter/caps letter support (as we can't force the HTML authors
   to use caps letters): probably a simple upper case conversion for tags
   would help
- support of still unknown tags:
     - table support (Frank Warmerdam, could you send your wish to Justin?)
     - better <pre></pre> support
     - <br> should not be treated as <p>
     - other developers: further ideas?

I will have to convert some complex pages to see what's missing.

Yours

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

Might I humbly suggest using something like SGML/XML rather than HTML.
There are already free implementations for doing this kind of thing.

DocBook comes to mind since it was designed for software documentation.
It probably has a lot more than is needed, but lots of tools already
exist.

--
/bin/sh ~/.signature:
Command not found

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

Hello all

"Eric G . Miller" wrote:

Might I humbly suggest using something like SGML/XML rather than HTML.
There are already free implementations for doing this kind of thing.

DocBook comes to mind since it was designed for software
documentation. It probably has a lot more than is needed, but lots of
tools already exist.

Perhaps this is the way to go with the documentation. Looking at the
DocBook site they have tools to generate man and HTML pages as well as
an SGML/XML editing mode for emacs. Having the documentation in a single
source that can be used to generate several different presentation
formats is definitely a plus. But I think we should probably stick with
HTML for 5.0 stable since changing all the documentation to DocBook may
be too big a job. We can schedule it for 5.1 instead.

Anyway, just my 2 cents worth

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

Hi Justin, all

as you might have seen I have activated the html2man procedure.
Seems to work rather good, but it is very sloooow...

Here something still missing in g.html2man:
      - table support
      - better <pre></pre> support
      - <br> should not be treated as <p>

Developers, does anyone know the MAN "tags" (or how you call this)
for above HTML tags? Then Justin could implement it as he offered.
I am not familiar with MAN, sorry.

Thanks in advance

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'