[GRASS-dev] ps.map consolidation

[Jachym_Cepicky]

Hi,
I started to look into ps.map code and I found few issues, which
should be IMHO solved, so the code looks a bit nicer and the usage is
more consistent.

It would be great, if somebody more skilled would post some comments
to this topic, I will be very much thankful.

1) some instructions (raster, setcolor) do not need to end with "end"
keyword, where others do. this should be IMHO consolidated, so that
ALL instructions will need to end with "end" keyword. we should look
into configuration file of mapserver for inspiration

2) I think, file session.c can be removed. I did not quite understand,
what is this session management about, but it would make the code a
bit simplier and short test showed, it is working also without it (and
I found no other function, which wuold access functions from
session.c)

3) some units are map units by default, where some are percent, some
inches. It would be IMHO great, if the user would have allways to
specify, which units she would like to use (without enything, it would
be map units), example:

text 30% 100% SPEARFISH SOILS MAP
end

text 3cm 10cm SPEARFISH SOILS MAP
end

text 30000.0 20000.04 SPEARFISH SOILS MAP
end

text 1in 1.5in SPEARFISH SOILS MAP
end

currently, only some instructions are supporting %

4) placenemnt should be allways specified with "where" keyword
5) text or other value should be allways specified with "value" keyword:
  text 650000 7365000 SPEARFISH LAND COVER
  end
->
  text
           where 650000 7365000
           value SPEARFISH LAND COVER
  end

6) file (map) names should be allways specified with "name" keyword

example:

  vlines streams
  end
->
  vlines
            name streams
  end

this is all for now

what do you think?

thanks for your comments

jachym
--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

[mlennert]

On 01/03/07 18:43, Jáchym Čepický wrote:

Hi,
I started to look into ps.map code and I found few issues, which
should be IMHO solved, so the code looks a bit nicer and the usage is
more consistent.

It would be great, if somebody more skilled would post some comments
to this topic, I will be very much thankful.

No idea about 2), but for the rest:

+1

Moritz

1) some instructions (raster, setcolor) do not need to end with "end"
keyword, where others do. this should be IMHO consolidated, so that
ALL instructions will need to end with "end" keyword. we should look
into configuration file of mapserver for inspiration

2) I think, file session.c can be removed. I did not quite understand,
what is this session management about, but it would make the code a
bit simplier and short test showed, it is working also without it (and
I found no other function, which wuold access functions from
session.c)

3) some units are map units by default, where some are percent, some
inches. It would be IMHO great, if the user would have allways to
specify, which units she would like to use (without enything, it would
be map units), example:

text 30% 100% SPEARFISH SOILS MAP
end

text 3cm 10cm SPEARFISH SOILS MAP
end

text 30000.0 20000.04 SPEARFISH SOILS MAP
end

text 1in 1.5in SPEARFISH SOILS MAP
end

currently, only some instructions are supporting %

4) placenemnt should be allways specified with "where" keyword
5) text or other value should be allways specified with "value" keyword:
    text 650000 7365000 SPEARFISH LAND COVER
    end
->
    text
          where 650000 7365000
          value SPEARFISH LAND COVER
    end

6) file (map) names should be allways specified with "name" keyword

example:

    vlines streams
    end
->
    vlines
           name streams
    end

this is all for now

what do you think?

thanks for your comments

jachym

[Glynn_Clements1]

Je-Báchym Èepický wrote:e-A

I started to look into ps.map code and I found few issues, which
should be IMHO solved, so the code looks a bit nicer and the usage is
more consistent.

It would be great, if somebody more skilled would post some comments
to this topic, I will be very much thankful.

1) some instructions (raster, setcolor) do not need to end with "end"
keyword, where others do.

More precisely, instructions which have options need "end", those
which don't have options don't need "end".

this should be IMHO consolidated, so that
ALL instructions will need to end with "end" keyword.

While this may be a reasonable idea, it will break existing ps.map
scripts. The same goes for most of your other suggestions.

If you're going to abandon compatibility, you may as well go all the
way, rather than merely tinkering with the syntax and leaving the
semantics intact.

A better structure, IMHO, would be to execute commands as they are
read from the file, rather than simply storing data then generating
everything at the end. This would allow multiple items (maps etc) on a
page.

Most of the commands should simply dump their parameters (or the GRASS
data to which they refer) to the output file, leaving as much of the
implementation as possible in PostScript. This would allow
customisation without needing to recompile anything.

--
Glynn Clements <glynn@gclements.plus.com>

[H_B]

Jáchym Èepický wrote:

I started to look into ps.map code and I found few issues, which
should be IMHO solved, so the code looks a bit nicer and the usage is
more consistent.

It would be great, if somebody more skilled would post some comments
to this topic, I will be very much thankful.

1) some instructions (raster, setcolor) do not need to end with "end"
keyword, where others do. this should be IMHO consolidated, so that
ALL instructions will need to end with "end" keyword. we should look
into configuration file of mapserver for inspiration

Glynn answered:

More precisely, instructions which have options need "end", those
which don't have options don't need "end".

The subinstruction code is never called (it doesn't exist), so the
"end" is never considered. It wouldn't be too hard to have main.c skip
over any extra "end"s in the control file, but that blurs the (obscure)
logic.

Jachym:

2) I think, file session.c can be removed. I did not quite understand,
what is this session management about, but it would make the code a
bit simplier and short test showed, it is working also without it (and
I found no other function, which wuold access functions from
session.c)

input() [input.c] calls add_to_session() [session.c] if PostScript level
is >0 (???). the reject() fn in session.c is called in a few places.
Perhaps this is all for storing input in a tmp file when entering
commands in interactive mode or when input is piped from stdin??
It's a case where some comments in the code would have been nice.

Looking way back to the GRASS 4.3 source code I see "session" is a
KEYword in cmd/main.c (it's in 5.4 as well), but commented out. So it's
probably a hold-over from p.map (where it isn't commented out), and
safely removed. It's not mentioned in the inter/ versions or help pages,
so I'm not sure if my guess for its purpose is correct. Regardless, rip
away!

3) some units are map units by default, where some are percent, some
inches. It would be IMHO great, if the user would have allways to
specify, which units she would like to use (without enything, it would
be map units), example:

..

currently, only some instructions are supporting %

Yes, this can be annoying. This is wish # 3335
  https://intevation.de/rt/webrt?serial_num=3335

For general purpose commands like placing text on the page I have tried
to add placement by all three modes where I could. (or at least allow
one of the comments/labels/text commands to get the job done using the
reference system needed)

There is another inconsistency in that some instructions refer to
location on the page (usually in inches; eg legend, mapinfo), while
other instructions refer to location in and around the map box (usually
in percent or map coordinates; eg rectangle, text). Percentages greater
or less than 0-100 are usually ok for placing text elsewhere on the page
than in the map box (eg 115% height).

So it is not random which commands have inches, and which have {percent
or map coordinates}, it just seems like that.

Presumably any GUI WYSIWYG tool could do all the units conversion math
for you when creating the instructions file. (short pain for the GUI
programmer, but then invisible)

4) placenemnt should be allways specified with "where" keyword

Careful, "where" is used for vector SQL queries too.

5) text or other value should be allways specified with "value"
keyword:
6) file (map) names should be allways specified with "name" keyword

These are something that should wait for a full rewrite.

Glynn:

While this may be a reasonable idea, it will break existing ps.map
scripts. The same goes for most of your other suggestions.

If you're going to abandon compatibility, you may as well go all the
way, rather than merely tinkering with the syntax and leaving the
semantics intact.

I agree. My plan was to have the new wxPython ps.map GUI worry about all
the oddities in the ps.map controls and leave ps.map as it is. It may
be odd, but it is fully functional and well tested and that is worth a
lot.

http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map

If you wish to reimplement ps.map, as Glynn says you are best to start
over from the beginning and call it ps/ps.something_else. It would be
a real pain to have to rewrite years of carefully constructed ps.map
templates. Straight GUI -> PostScript, skip C?

I understand that it is a pain for writing the GUI to have to deal with
the weird ways of ps.map, and I support adding missing % placement to
any instruction that currently only takes map coordinates (if any still
exist). I'm not so sure about mixing inches with percent (of page), even
though this is annonying. Then you mix percent of page vs percent of map
box, which is even more confusing.

Hamish

ps - I found a nice 10 minute Python tutorial [for programmers of other
languages] that covers the basics,
  http://grass.gdf-hannover.de/wiki/GRASS_and_Python#Programming

[Glynn_Clements1]

Hamish wrote:

> 2) I think, file session.c can be removed. I did not quite understand,
> what is this session management about, but it would make the code a
> bit simplier and short test showed, it is working also without it (and
> I found no other function, which wuold access functions from
> session.c)

input() [input.c] calls add_to_session() [session.c] if PostScript level
is >0 (???).

The parameter name is "level", but it doesn't refer to the PostScript
language level.

--
Glynn Clements <glynn@gclements.plus.com>

[Jachym_Cepicky]

Thanks for the comments.

I was suggesting this changes to make live of GUI coder easier

another point: How to write GUI for ps.map, so it is usable for the
user. Several approaches are possible:

Drawing boxes for legend, measure, text and so on, so the user has at
least idea about where and how the object will be placed on the paper.

Another sollution would be, if we would copy the map display approach:
render separate layer for each map instruction in the temporary file
and put them together in the map display. User could than take a mouse
and position each object interactively.

We would need support of transparency for this... Does ps.map support
creation of transparent files?

Is the layer approach the one, we should use?

Jachym

2007/3/2, Hamish <hamish_nospam@yahoo.com>:

Jáchym Èepický wrote:
> I started to look into ps.map code and I found few issues, which
> should be IMHO solved, so the code looks a bit nicer and the usage is
> more consistent.
>
> It would be great, if somebody more skilled would post some comments
> to this topic, I will be very much thankful.
>
> 1) some instructions (raster, setcolor) do not need to end with "end"
> keyword, where others do. this should be IMHO consolidated, so that
> ALL instructions will need to end with "end" keyword. we should look
> into configuration file of mapserver for inspiration

Glynn answered:
> More precisely, instructions which have options need "end", those
> which don't have options don't need "end".

The subinstruction code is never called (it doesn't exist), so the
"end" is never considered. It wouldn't be too hard to have main.c skip
over any extra "end"s in the control file, but that blurs the (obscure)
logic.

Jachym:
> 2) I think, file session.c can be removed. I did not quite understand,
> what is this session management about, but it would make the code a
> bit simplier and short test showed, it is working also without it (and
> I found no other function, which wuold access functions from
> session.c)

input() [input.c] calls add_to_session() [session.c] if PostScript level
is >0 (???). the reject() fn in session.c is called in a few places.
Perhaps this is all for storing input in a tmp file when entering
commands in interactive mode or when input is piped from stdin??
It's a case where some comments in the code would have been nice.

Looking way back to the GRASS 4.3 source code I see "session" is a
KEYword in cmd/main.c (it's in 5.4 as well), but commented out. So it's
probably a hold-over from p.map (where it isn't commented out), and
safely removed. It's not mentioned in the inter/ versions or help pages,
so I'm not sure if my guess for its purpose is correct. Regardless, rip
away!

> 3) some units are map units by default, where some are percent, some
> inches. It would be IMHO great, if the user would have allways to
> specify, which units she would like to use (without enything, it would
> be map units), example:
..
> currently, only some instructions are supporting %

Yes, this can be annoying. This is wish # 3335
  https://intevation.de/rt/webrt?serial_num=3335

For general purpose commands like placing text on the page I have tried
to add placement by all three modes where I could. (or at least allow
one of the comments/labels/text commands to get the job done using the
reference system needed)

There is another inconsistency in that some instructions refer to
location on the page (usually in inches; eg legend, mapinfo), while
other instructions refer to location in and around the map box (usually
in percent or map coordinates; eg rectangle, text). Percentages greater
or less than 0-100 are usually ok for placing text elsewhere on the page
than in the map box (eg 115% height).

So it is not random which commands have inches, and which have {percent
or map coordinates}, it just seems like that.

Presumably any GUI WYSIWYG tool could do all the units conversion math
for you when creating the instructions file. (short pain for the GUI
programmer, but then invisible)

> 4) placenemnt should be allways specified with "where" keyword

Careful, "where" is used for vector SQL queries too.

> 5) text or other value should be allways specified with "value"
> keyword:
> 6) file (map) names should be allways specified with "name" keyword

These are something that should wait for a full rewrite.

Glynn:
> While this may be a reasonable idea, it will break existing ps.map
> scripts. The same goes for most of your other suggestions.
>
> If you're going to abandon compatibility, you may as well go all the
> way, rather than merely tinkering with the syntax and leaving the
> semantics intact.

I agree. My plan was to have the new wxPython ps.map GUI worry about all
the oddities in the ps.map controls and leave ps.map as it is. It may
be odd, but it is fully functional and well tested and that is worth a
lot.

http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map

If you wish to reimplement ps.map, as Glynn says you are best to start
over from the beginning and call it ps/ps.something_else. It would be
a real pain to have to rewrite years of carefully constructed ps.map
templates. Straight GUI -> PostScript, skip C?

I understand that it is a pain for writing the GUI to have to deal with
the weird ways of ps.map, and I support adding missing % placement to
any instruction that currently only takes map coordinates (if any still
exist). I'm not so sure about mixing inches with percent (of page), even
though this is annonying. Then you mix percent of page vs percent of map
box, which is even more confusing.

Hamish

ps - I found a nice 10 minute Python tutorial [for programmers of other
languages] that covers the basics,
  http://grass.gdf-hannover.de/wiki/GRASS_and_Python#Programming

--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

[Glynn_Clements1]

Je-Báchym Èepický wrote:e-A

another point: How to write GUI for ps.map, so it is usable for the
user. Several approaches are possible:

Drawing boxes for legend, measure, text and so on, so the user has at
least idea about where and how the object will be placed on the paper.

Another sollution would be, if we would copy the map display approach:
render separate layer for each map instruction in the temporary file
and put them together in the map display. User could than take a mouse
and position each object interactively.

We would need support of transparency for this... Does ps.map support
creation of transparent files?

ps.map creates PostScript files. If you use Ghostscript's "pngalpha"
driver, the resulting PNG file will have a transparent background. But
then you would need to convert the PNG files to PPM/PGM (that's all
that g.pnmcomp understands), and you would need to manually
re-composite those files whenever the relative position changes.

Personally, I don't see the point in a ps.map GUI; this task is better
suited to general-purpose DTP software.

--
Glynn Clements <glynn@gclements.plus.com>

[Roger_Miller1]

I have a rudimentary GUI for ps.map written as a TCL/TK script. It works by reading the content of the monitor and using that content to construct a basic input file for ps.map. The GUI (which, as I said is pretty rudimentary) allows the user to view and edit instructions in the input file, to insert elements like eps files and to use options like line styles that aren't supported on the GRASS monitor. It uses xpdf a previewer. xpdf is fairly fast and has a remote server mode that allows the user to update the preview without restarting the viewer. It is distributed under the GNU public license by Glyph and Cog, LLC ; http://www.foolabs.com/xpdf/home.html

The grass developers may not want to introduce a dependency on xpdf, but I encourage you to do something to give ps.map a friendlier front end. The benefit is tremendous. Having even a simple interactive ability to develop better graphics within the grass environment improved the quality of my products and decreased the time necessary to produce them.

Roger Miller

Glynn Clements writes:

Je-B�chym �epick� wrote:e-A

another point: How to write GUI for ps.map, so it is usable for the
user. Several approaches are possible:

Drawing boxes for legend, measure, text and so on, so the user has at
least idea about where and how the object will be placed on the paper.

Another sollution would be, if we would copy the map display approach:
render separate layer for each map instruction in the temporary file
and put them together in the map display. User could than take a mouse
and position each object interactively.

We would need support of transparency for this... Does ps.map support
creation of transparent files?

ps.map creates PostScript files. If you use Ghostscript's "pngalpha"
driver, the resulting PNG file will have a transparent background. But
then you would need to convert the PNG files to PPM/PGM (that's all
that g.pnmcomp understands), and you would need to manually
re-composite those files whenever the relative position changes.

Personally, I don't see the point in a ps.map GUI; this task is better
suited to general-purpose DTP software.

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

[mlennert]

On Fri, March 2, 2007 23:25, roger@spinn.net wrote:

I have a rudimentary GUI for ps.map written as a TCL/TK script. It works
by
reading the content of the monitor and using that content to construct a
basic input file for ps.map. The GUI (which, as I said is pretty
rudimentary) allows the user to view and edit instructions in the input
file, to insert elements like eps files and to use options like line
styles
that aren't supported on the GRASS monitor. It uses xpdf a previewer.
xpdf
is fairly fast and has a remote server mode that allows the user to update
the preview without restarting the viewer. It is distributed under the
GNU
public license by Glyph and Cog, LLC ;
http://www.foolabs.com/xpdf/home.html

Would you be willing to publish your script on the GRASS add-ons wiki
(http://grass.gdf-hannover.de/wiki/GRASS_AddOns) ?

Moritz

The grass developers may not want to introduce a dependency on xpdf, but I
encourage you to do something to give ps.map a friendlier front end. The
benefit is tremendous. Having even a simple interactive ability to
develop
better graphics within the grass environment improved the quality of my
products and decreased the time necessary to produce them.

Roger Miller

Glynn Clements writes:

Je-B�chym �epick� wrote:e-A

another point: How to write GUI for ps.map, so it is usable for the
user. Several approaches are possible:

Drawing boxes for legend, measure, text and so on, so the user has at
least idea about where and how the object will be placed on the paper.

Another sollution would be, if we would copy the map display approach:
render separate layer for each map instruction in the temporary file
and put them together in the map display. User could than take a mouse
and position each object interactively.

We would need support of transparency for this... Does ps.map support
creation of transparent files?

ps.map creates PostScript files. If you use Ghostscript's "pngalpha"
driver, the resulting PNG file will have a transparent background. But
then you would need to convert the PNG files to PPM/PGM (that's all
that g.pnmcomp understands), and you would need to manually
re-composite those files whenever the relative position changes.

Personally, I don't see the point in a ps.map GUI; this task is better
suited to general-purpose DTP software.

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

[cmbarton]

In order to better create backgrounds in v.digit from the GUI, I added a new
global variable, named "commandlist" to the TclTk code. Commandlist stores a
TclTk list of the commands needed to create the current display. It is
updated every time the display is updated. Thinking about it, I may need to
index it by display, like many other variables.

However, this could be used for a variety of other uses, including being
parsed to create a ps.map command file.

Michael

On 3/2/07 3:25 PM, "roger@spinn.net" <roger@spinn.net> wrote:

I have a rudimentary GUI for ps.map written as a TCL/TK script. It works by
reading the content of the monitor and using that content to construct a
basic input file for ps.map. The GUI (which, as I said is pretty
rudimentary) allows the user to view and edit instructions in the input
file, to insert elements like eps files and to use options like line styles
that aren't supported on the GRASS monitor. It uses xpdf a previewer. xpdf
is fairly fast and has a remote server mode that allows the user to update
the preview without restarting the viewer. It is distributed under the GNU
public license by Glyph and Cog, LLC ; http://www.foolabs.com/xpdf/home.html

The grass developers may not want to introduce a dependency on xpdf, but I
encourage you to do something to give ps.map a friendlier front end. The
benefit is tremendous. Having even a simple interactive ability to develop
better graphics within the grass environment improved the quality of my
products and decreased the time necessary to produce them.

Roger Miller

Glynn Clements writes:

Je-B�chym �epick� wrote:e-A

another point: How to write GUI for ps.map, so it is usable for the
user. Several approaches are possible:

Drawing boxes for legend, measure, text and so on, so the user has at
least idea about where and how the object will be placed on the paper.

Another sollution would be, if we would copy the map display approach:
render separate layer for each map instruction in the temporary file
and put them together in the map display. User could than take a mouse
and position each object interactively.

We would need support of transparency for this... Does ps.map support
creation of transparent files?

ps.map creates PostScript files. If you use Ghostscript's "pngalpha"
driver, the resulting PNG file will have a transparent background. But
then you would need to convert the PNG files to PPM/PGM (that's all
that g.pnmcomp understands), and you would need to manually
re-composite those files whenever the relative position changes.

Personally, I don't see the point in a ps.map GUI; this task is better
suited to general-purpose DTP software.

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

[H_B]

Jáchym Èepický wrote:

I was suggesting this changes to make live of GUI coder easier

I know, and feel your pain.

another point: How to write GUI for ps.map, so it is usable for the
user. Several approaches are possible:

Drawing boxes for legend, measure, text and so on, so the user has at
least idea about where and how the object will be placed on the paper.

Another sollution would be, if we would copy the map display approach:
render separate layer for each map instruction in the temporary file
and put them together in the map display. User could than take a mouse
and position each object interactively.

some ideas here:
http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map

My idea was to combine both ways, sort of like how QGIS is organized.
blank preview page on the right side of the GUI (portrait or landscape)
with solid black border for map box and colored dashed lines for the
different text/legend boxes. To begin with have those drawn from map
control placement settings, but in future you could drag those around
to update the instructions settings (adjust box of currently selected
instruction for overlap-proofing). In the far-future you would see low
res preview instead of just rectangles.

On the left 1/4 of the GUI would be an expandable map control
tree with a few permanent entries (paper, scale, maploc).
They might start with a "default" tick box selected [which would skip
the instruction on output])

[-] paper
    type _____A4_[V]
             letter
             custom
                ...
[ungreyed for custom]
    units ___inch_[V]
        Page Size
    height ______
    width _______
      Margin Size
    top _________
    bottom ______
    left ________
    right _______
[+] scale
[+] maploc

then icons along the top for: (keep it simple, ~8 is enough)

# rast
# vects (areas, lines, points)
# grids
# scalebar
# mapinfo
# text labels

When you click on an icon, a new "[+] raster map" gets added to
the list, then as above. Right-click to select remove instruction.
Some of those (rast, grid) need logic so you can only add them once.
Then in a main window pulldown menu have all the mapping instructions,
including the lesser used ones.

Save As... would take the current tree settings and write a ps.map
instructions file.

In the top-left "File" menu have (greyed-out in prototype) Load command
file, then these (working in prototype) output menu entries:
* Save instructions file, Save As... [a ps.map file]
* Save as PostScript file [run ps.map]
* Save as PDF File (pstopdf? ps2pdf? GNU Ghostscript?)
     [run ps.map, work on PostScript tmp file]
* Print [run ps.map, lpr PostScript tmp file]

And of course a Help menu with "g.manual ps.gui", "g.manual ps.map",
"About GUI", "About ps.map", "About GRASS".

how does that sound?

Hamish

[Jachym_Cepicky]

hi,

some ideas here:
http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map

My idea was to combine both ways, sort of like how QGIS is organized.
blank preview page on the right side of the GUI (portrait or landscape)
with solid black border for map box and colored dashed lines for the
different text/legend boxes. To begin with have those drawn from map
control placement settings, but in future you could drag those around
to update the instructions settings (adjust box of currently selected
instruction for overlap-proofing). In the far-future you would see low
res preview instead of just rectangles.

I see the problem in "guessing" the box sizes. e.g. you can place the
legend box somewhere on the paper, but you can not tell, how wide and
height the box will be. That is, why I was proposing to find a
sollution, that each object of the map would be stored in separate
layer, so it could be regenerated ones the user changes some
properity.

I did something, what you are proposing allready, some months ago:
http://wwwold.fle.czu.cz/~jachym/img/grass/gpsmap-0.1.2.png but as I
said, it was hard to determine the box dimensions..

I like the rest, you are writing, nice concept. Only the list of
layers should be taken from current map display

jachym

On the left 1/4 of the GUI would be an expandable map control
tree with a few permanent entries (paper, scale, maploc).
They might start with a "default" tick box selected [which would skip
the instruction on output])

[-] paper
    type _____A4_[V]
             letter
             custom
                ...
[ungreyed for custom]
    units ___inch_[V]
        Page Size
    height ______
    width _______
      Margin Size
    top _________
    bottom ______
    left ________
    right _______
[+] scale
[+] maploc

then icons along the top for: (keep it simple, ~8 is enough)

# rast
# vects (areas, lines, points)
# grids
# scalebar
# mapinfo
# text labels

When you click on an icon, a new "[+] raster map" gets added to
the list, then as above. Right-click to select remove instruction.
Some of those (rast, grid) need logic so you can only add them once.
Then in a main window pulldown menu have all the mapping instructions,
including the lesser used ones.

Save As... would take the current tree settings and write a ps.map
instructions file.

In the top-left "File" menu have (greyed-out in prototype) Load command
file, then these (working in prototype) output menu entries:
* Save instructions file, Save As... [a ps.map file]
* Save as PostScript file [run ps.map]
* Save as PDF File (pstopdf? ps2pdf? GNU Ghostscript?)
     [run ps.map, work on PostScript tmp file]
* Print [run ps.map, lpr PostScript tmp file]

And of course a Help menu with "g.manual ps.gui", "g.manual ps.map",
"About GUI", "About ps.map", "About GRASS".

how does that sound?

Hamish

--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

[Thierry_Laronde]

Hello,

On Mon, Mar 05, 2007 at 02:36:48PM +0100, Jachym Cepicky wrote:

hi,

>
>some ideas here:
>http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map
>
>
>My idea was to combine both ways, sort of like how QGIS is organized.
>blank preview page on the right side of the GUI (portrait or landscape)
>with solid black border for map box and colored dashed lines for the
>different text/legend boxes. To begin with have those drawn from map
>control placement settings, but in future you could drag those around
>to update the instructions settings (adjust box of currently selected
>instruction for overlap-proofing). In the far-future you would see low
>res preview instead of just rectangles.

I see the problem in "guessing" the box sizes. e.g. you can place the
legend box somewhere on the paper, but you can not tell, how wide and
height the box will be. That is, why I was proposing to find a
sollution, that each object of the map would be stored in separate
layer, so it could be regenerated ones the user changes some
properity.

Please see the message I sent named: Fonts (to be continued).

Indeed, the problem is that the rendering (the kerning) done in
PostScript exceeds the limited implementation of the rendering text
engine in DRAWLIB (RASTERLIB in GPL GRASS).

Actually, for example in TeX, when TeX composes a page, it does not deal
with the glyphes (the actual drawing of the glyphes) but only with the
metric file to know how to compose the bounding boxes. Only the driver
put the drawing in the boxes to simplify.

One "easy" solution would be to use MetaPOST to compose the label (but
in a dedicated mode; it would be too heavy---and useless---for
digitizing use) (using Adobe's T1 fonts in TeX), and to retrieve the
bounding box information from the EPS file generated:

1) Generated a MetaPOST script from the label specification ;

2) Generate the EPS files with MetaPOST;

3) Retrieve the information about the bounding boxes and put this
information in the label description (extending the format of the label
files)

then use this extra information to draw the bounding boxes.

Another trick: create a glyph in the legacy font format with an unit box
(1 x 1). Extend the command for the scale to allow separate X and Y
scaling. Then use the text commands to draw (display) the glyph of the
bounding box with correct X and Y scale, and angle.

You're done.

For the curious and the courageaous, plugging to some extent TeX in
GRASS/KerGIS would lead to something that has simply no equivalent in
the GIS world.

Caveats: first step would probably be to translate WEB TeX and METAFONT
to CWEB (Pascal to C) to allow more easy development of drivers. Pascal
is definitively not my cup of tea.
DRAWLIB to allow
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

[H_B]

Jachym Cepicky wrote:

> some ideas here:
> http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map
>
> My idea was to combine both ways, sort of like how QGIS is
> organized. blank preview page on the right side of the GUI (portrait
> or landscape) with solid black border for map box and colored dashed
> lines for the different text/legend boxes. To begin with have those
> drawn from map control placement settings, but in future you could
> drag those around to update the instructions settings (adjust box of
> currently selected instruction for overlap-proofing). In the
> far-future you would see low res preview instead of just rectangles.

I see the problem in "guessing" the box sizes. e.g. you can place the
legend box somewhere on the paper, but you can not tell, how wide and
height the box will be. That is, why I was proposing to find a
sollution, that each object of the map would be stored in separate
layer, so it could be regenerated ones the user changes some
properity.

You don't have to guess the box sizes at all. The only tricky part is to
recreate the scale-> map size calculation, which isn't so hard to do.
(I was doing this by hand in the last month while fixing bugs #3096 and
5454)

for things like legend box, we know the page size in inches, and the x,y
offset in inches, and the height/width in inches (and can look up the
defaults), so no guessing there either.

some more work is needed for e.g. the scalebar which is places by its
center not its top left corner.

so just a bunch of 1-2-3-4 work, not guess work.

?

I did something, what you are proposing allready, some months ago:
http://wwwold.fle.czu.cz/~jachym/img/grass/gpsmap-0.1.2.png but as I
said, it was hard to determine the box dimensions..

ah yes, exactly. so not so much my idea at all.

I like the rest, you are writing, nice concept. Only the list of
layers should be taken from current map display

I think that could be added in a future prototype, along with loading of
a prior ps.map instructions file. It is nice, but not specifically
needed to run the program.

Hamish