[GRASS-dev] Cairo monitor driver

GRASS GRASS developer
1

Hi!

My apologies if this has been done and/or discussed before, but a search of grass-dev came up empty.

Since the Cairo graphics library (http://www.cairographics.org, LGPL licensed) provides very high-quality graphics output in several vector and raster formats, I thought it would make sense to create a "pseudo" monitor driver for it (similar to the PNG and PS drivers). So I did. Cairo does all of the hard work, so it's really mostly simple "glue" code.

It seems stable, and is fairly complete in terms of features. I've used for most of my own work recently.

Benefits include:

* High quality antialiased output. See http://lars.ahlzen.com/cairograss/ for a few simple examples and a comparison with the PNG driver.

* Several output format options, both vector and bitmap. The driver currently supports PNG, PDF, PS and SVG. Output to X or Win32 windows might be possible in the future, since Cairo supports such formats as well.

Of course, such niceness comes at a price. It takes longer to draw complex vector data, compared to the PNG driver. However, I imagine that in most cases drawing is not the main bottleneck anyway.

Also, it obviously pulls in Cairo as an additional dependency. Cairo is probably found on most systems nowadays, though, since many other applications (including some mapping and GIS software) already use it.

Additionally, the fact that GRASS monitors (unfortunately) receive integer data (screen coordinates, line widths, etc) somewhat limits the effectiveness of the high-precision output from the CAIRO driver. For example, in the "Massachusetts Counties and roads" example, the antialiasing breaks down for certain lines because they are divided into smaller segments whose coordinates are rounded before they are drawn. Similarly, zooming in on vector output will also reveal this drawback.

My main question is: Does all of this seem useful to anyone else? I do realize that most of these things can be achieved in other ways, but I've personally found this driver to produce high quality output in a very convenient way. Feedback is appreciated!

I can of course post code too, if anyone would be interested in actually trying it.

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

2

On Saturday 13 October 2007 16:20, Lars Ahlzen wrote:

Hi!

My apologies if this has been done and/or discussed before, but a search
of grass-dev came up empty.

This has not... although other back-end drivers have been discussed... kind of
like how R can use a wide variety "output devices".

Since the Cairo graphics library (http://www.cairographics.org, LGPL
licensed) provides very high-quality graphics output in several vector
and raster formats, I thought it would make sense to create a "pseudo"
monitor driver for it (similar to the PNG and PS drivers). So I did.
Cairo does all of the hard work, so it's really mostly simple "glue" code.

Indeed. I have been using it for all of my R work lately. I don't know why
this hasn't come up before, but something like Cairo actually solves a lot of
the problems we are facing: high quality on-screen display, output to PDF...

This would also solve the translucency problem, as Cairo can deal with that
quite nicely.

It seems stable, and is fairly complete in terms of features. I've used
for most of my own work recently.

Yeah... seems to work quite well with R.

Benefits include:

* High quality antialiased output. See
http://lars.ahlzen.com/cairograss/ for a few simple examples and a
comparison with the PNG driver.

* Several output format options, both vector and bitmap. The driver
currently supports PNG, PDF, PS and SVG. Output to X or Win32 windows
might be possible in the future, since Cairo supports such formats as well.

Of course, such niceness comes at a price. It takes longer to draw
complex vector data, compared to the PNG driver. However, I imagine that
in most cases drawing is not the main bottleneck anyway.

For hard copy output like PDF this isn't a problem.

Also, it obviously pulls in Cairo as an additional dependency. Cairo is
probably found on most systems nowadays, though, since many other
applications (including some mapping and GIS software) already use it.

If it is an additional feature, then an additional dep. isn't always a bad
thing.

Additionally, the fact that GRASS monitors (unfortunately) receive
integer data (screen coordinates, line widths, etc) somewhat limits the
effectiveness of the high-precision output from the CAIRO driver. For
example, in the "Massachusetts Counties and roads" example, the
antialiasing breaks down for certain lines because they are divided into
smaller segments whose coordinates are rounded before they are drawn.
Similarly, zooming in on vector output will also reveal this drawback.

Perhaps that rounding can be toggled based on the output device...

My main question is: Does all of this seem useful to anyone else? I do
realize that most of these things can be achieved in other ways, but
I've personally found this driver to produce high quality output in a
very convenient way. Feedback is appreciated!

In the past I would approximate this type of output by rendering a PNG at 2x
size and then shrink it down with imagemagick. This would give me nice
looking lines, but not as nice as what Cairo does. It would also be nice to
have an output device which can deal with alpha transparency and PDF versions

= 1.3, which would allow translucency in PDF files.

I can of course post code too, if anyone would be interested in actually
trying it.

/ Lars

Posting the code would be great - which version of GRASS was this built
against?

I am not a developer, but since this is close to something that I would use on
a regular basis I can certainly test it out.

Cheers, and thanks for the innovative work!

Dylan

3

Dylan Beaudette wrote:

On Saturday 13 October 2007 16:20, Lars Ahlzen wrote:

I can of course post code too, if anyone would be interested in actually
trying it.

Posting the code would be great -

Hi Lars

You can submit it to code patches tracker [1]. It will be
stored there and a notification about the new ticket,
including your message, will be automatically sent to GRASS
dev ml.

[1]http://wald.intevation.org/tracker/?atid=205&group_id=21&func=browse

Maciek

4

Dylan Beaudette wrote:

> Since the Cairo graphics library (http://www.cairographics.org, LGPL
> licensed) provides very high-quality graphics output in several vector
> and raster formats, I thought it would make sense to create a "pseudo"
> monitor driver for it (similar to the PNG and PS drivers). So I did.
> Cairo does all of the hard work, so it's really mostly simple "glue" code.

Indeed. I have been using it for all of my R work lately. I don't know why
this hasn't come up before, but something like Cairo actually solves a lot of
the problems we are facing: high quality on-screen display, output to PDF...

This would also solve the translucency problem, as Cairo can deal with that
quite nicely.

The problem with translucency is that not all rendering systems
support it. The core X11 protocol doesn't, so you either need the
Render extension or to perform the rendering client-side. PostScript
doesn't support it, as most printers only have one bit per component.

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

5

Lars Ahlzen wrote:

My apologies if this has been done and/or discussed before, but a search
of grass-dev came up empty.

Since the Cairo graphics library (http://www.cairographics.org, LGPL
licensed) provides very high-quality graphics output in several vector
and raster formats, I thought it would make sense to create a "pseudo"
monitor driver for it (similar to the PNG and PS drivers). So I did.
Cairo does all of the hard work, so it's really mostly simple "glue" code.

It seems stable, and is fairly complete in terms of features. I've used
for most of my own work recently.

Benefits include:

* High quality antialiased output. See
http://lars.ahlzen.com/cairograss/ for a few simple examples and a
comparison with the PNG driver.

One thing to be careful of with anti-aliasing is tesselations. Issues
with Ghostscript's anti-aliasing option are a regular topic on the GMT
list.

* Several output format options, both vector and bitmap. The driver
currently supports PNG, PDF, PS and SVG. Output to X or Win32 windows
might be possible in the future, since Cairo supports such formats as well.

Of course, such niceness comes at a price. It takes longer to draw
complex vector data, compared to the PNG driver. However, I imagine that
in most cases drawing is not the main bottleneck anyway.

For d.vect, drawing usually is the bottleneck.

Also, it obviously pulls in Cairo as an additional dependency. Cairo is
probably found on most systems nowadays, though, since many other
applications (including some mapping and GIS software) already use it.

Additionally, the fact that GRASS monitors (unfortunately) receive
integer data (screen coordinates, line widths, etc) somewhat limits the
effectiveness of the high-precision output from the CAIRO driver. For
example, in the "Massachusetts Counties and roads" example, the
antialiasing breaks down for certain lines because they are divided into
smaller segments whose coordinates are rounded before they are drawn.
Similarly, zooming in on vector output will also reveal this drawback.

My main question is: Does all of this seem useful to anyone else? I do
realize that most of these things can be achieved in other ways, but
I've personally found this driver to produce high quality output in a
very convenient way. Feedback is appreciated!

The main thing to bear in mind is that the graphics system is going to
be completely re-written for 7.x.

If Cairo is available for both Windows and MacOSX (natively, i.e. not
requiring X11), and does an adequate job of PostScript generation
(embedding a pre-rendered image in a PostScript file doesn't count),
it could be a viable basis for the new graphics architecture.

I can of course post code too, if anyone would be interested in actually
trying it.

The code would certainly be useful.

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

6

Glynn Clements wrote:

Dylan Beaudette wrote:

Since the Cairo graphics library (http://www.cairographics.org, LGPL
licensed) provides very high-quality graphics output in several vector
and raster formats, I thought it would make sense to create a "pseudo"
monitor driver for it (similar to the PNG and PS drivers). So I did.
Cairo does all of the hard work, so it's really mostly simple "glue" code.

Indeed. I have been using it for all of my R work lately. I don't know why this hasn't come up before, but something like Cairo actually solves a lot of the problems we are facing: high quality on-screen display, output to PDF...

This would also solve the translucency problem, as Cairo can deal with that quite nicely.

The problem with translucency is that not all rendering systems
support it. The core X11 protocol doesn't, so you either need the
Render extension or to perform the rendering client-side.

I believe that Cairo does this client-side for X surfaces, so one wouldn't really need to worry about it.

PostScript doesn't support it, as most printers only have one bit per component.

True. Not much do do about this case (other than perhaps use PDF, and a printer driver that does the compositing in software before it's sent to the printer).

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

7

On Sun, 2007-10-14 at 19:36 +0100, Glynn Clements wrote:

The main thing to bear in mind is that the graphics system is going to
be completely re-written for 7.x.

Could your provide details? I've seen bits here and there, but it would
be nice to have a summary of planned changes in one place.

If Cairo is available for both Windows and MacOSX (natively, i.e. not
requiring X11), and does an adequate job of PostScript generation
(embedding a pre-rendered image in a PostScript file doesn't count),
it could be a viable basis for the new graphics architecture.

Yes, Cairo is available without X11. It comes with recent versions of
GTK, but is available as a completely separate standalone library.

From http://www.cairographics.org/download/ (Windows):

"You want "cairo-1.4.8.zip", the binary distribution at "libpng 1.2.8",
and "Zlib 1.2.3" (you can search on those strings to find them in the
page). That should be it. Just pop libcairo-2.dll, libpng13.dll and
zlib1.dll into your working directory or system PATH, and away you go!"

> I can of course post code too, if anyone would be interested in actually
> trying it.

The code would certainly be useful.

+1

--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

8

Glynn Clements wrote:

* High quality antialiased output. See http://lars.ahlzen.com/cairograss/ for a few simple examples and a comparison with the PNG driver.

One thing to be careful of with anti-aliasing is tesselations. Issues
with Ghostscript's anti-aliasing option are a regular topic on the GMT
list.

Good point.

I don't know how well this driver handles that. During my own use i haven't *noticed* any issues, but you or some one else might have good test cases to try once I post the code.

My main question is: Does all of this seem useful to anyone else? I do realize that most of these things can be achieved in other ways, but I've personally found this driver to produce high quality output in a very convenient way. Feedback is appreciated!

The main thing to bear in mind is that the graphics system is going to
be completely re-written for 7.x.

If that's the case (I actually wasn't aware; I haven't followed grass-dev for that long), I guess it isn't worth spending an enormous amount of effort on something like this. It may still be useful in the meantime, though.

If Cairo is available for both Windows and MacOSX (natively, i.e. not
requiring X11), and does an adequate job of PostScript generation
(embedding a pre-rendered image in a PostScript file doesn't count),
it could be a viable basis for the new graphics architecture.

It is native cross-platform. According to the docs, it even uses hardware acceleration where available.

And yes, it produces real, actual vector output (PS, PDF and supposedly SVG although I had some issues with that), not just a bitmap with a PS/PDF header. There are some PDF examples rendered with the CAIRO GRASS driver at http://lars.ahlzen.com/cairograss/

There are also (currently experimental) support for OpenGL output, which may be useful if one wanted the new graphics architecture to support nviz and realtime graphics.

For Mac there's Quartz in the works, too.

Btw, IMO Cairo would be an excellent candidate to base a new graphics/rendering system on.

I can of course post code too, if anyone would be interested in actually trying it.

The code would certainly be useful.

Will post. :slight_smile:

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

9

Lars Ahlzen wrote:

>>> Since the Cairo graphics library (http://www.cairographics.org, LGPL
>>> licensed) provides very high-quality graphics output in several vector
>>> and raster formats, I thought it would make sense to create a "pseudo"
>>> monitor driver for it (similar to the PNG and PS drivers). So I did.
>>> Cairo does all of the hard work, so it's really mostly simple "glue" code.
>> Indeed. I have been using it for all of my R work lately. I don't know why
>> this hasn't come up before, but something like Cairo actually solves a lot of
>> the problems we are facing: high quality on-screen display, output to PDF...
>>
>> This would also solve the translucency problem, as Cairo can deal with that
>> quite nicely.
>
> The problem with translucency is that not all rendering systems
> support it. The core X11 protocol doesn't, so you either need the
> Render extension or to perform the rendering client-side.

I believe that Cairo does this client-side for X surfaces, so one
wouldn't really need to worry about it.

Doing it client side can be a major performance hit. Apart from
anything else, all of the rendering has to be done in software; your
graphics hardware can't help.

OTOH, we're already taking that hit with gis.m/wxGRASS and the PNG
driver. It's less significant for simple visualisation, but it could
be a major issue for interactive editing of vector data.

> PostScript doesn't support it, as most printers only have one bit per component.

True. Not much do do about this case (other than perhaps use PDF, and a
printer driver that does the compositing in software before it's sent to
the printer).

Pre-rasterising is less than ideal, for two main reasons:

1. For networked setups, the amount of data involved starts to become
a major issue in terms of network bandwidth and disk usage,
particularly with 1200x1200 DPI printers being relatively common
nowadays.

2. The results are often less than ideal. Emulating intensity levels
through halftones has a cost in terms of spatial resolution. You get
better results if the halftoning is done on vector primitives (rather
than pre-rendered images), and if it's tailored to the actual printing
technology (for a laser printer, the transfer from the digital
framebuffer to an actual page is quite noisy, which is why the default
halftone resolution is usually substantially lower than the pixel
resolution).

You're a lot better off if you don't assume that you have a magic
bullet which will make anti-aliasing and alpha-blending work for
hardcopy as it does on video. IOW, explicitly allowing for hardcopy
devices rather than designing for video then trying to bang the
hardcopy peg into the video hole.

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

10

Brad Douglas wrote:

> The main thing to bear in mind is that the graphics system is going to
> be completely re-written for 7.x.

Could your provide details? I've seen bits here and there, but it would
be nice to have a summary of planned changes in one place.

Main points include:

1. Eliminating seperate driver processes. Having to extend the
protocol for each new operation has been a major drag on development.

2. Use of floating-point for all coordinates.

3. Common architecture for both video and hardcopy output. ps.map
should be redundant.

In retrospect, #1 means that we don't really need support for the
Windows/MacOSX GUI, just the ability to generate image files.

With X, we could take the shortcut of having d.* commands draw
directly into an existing window, but I don't know whether that's
possible on other platforms.

OTOH, it might be useful to be able to use the same functions for
self-contained GUI programs (e.g. vector digitising) as for d.*
commands.

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

11

Lars Ahlzen wrote:

>> * High quality antialiased output. See
>> http://lars.ahlzen.com/cairograss/ for a few simple examples and a
>> comparison with the PNG driver.
>
> One thing to be careful of with anti-aliasing is tesselations. Issues
> with Ghostscript's anti-aliasing option are a regular topic on the GMT
> list.

Good point.

I don't know how well this driver handles that. During my own use i
haven't *noticed* any issues, but you or some one else might have good
test cases to try once I post the code.

Take a map with many adjoining polygons, e.g. "soils" from spearfish,
then assign colours such that adjacent polygons have the same colour.
Anti-aliasing will produce visible lines between polygons.

It needs to be borne in mind that anti-aliasing edges is a "hack".
Sometimes it works, sometimes it doesn't. When it doesn't, you need to
to either use oversampling or to simply disable it.

> If Cairo is available for both Windows and MacOSX (natively, i.e. not
> requiring X11), and does an adequate job of PostScript generation
> (embedding a pre-rendered image in a PostScript file doesn't count),
> it could be a viable basis for the new graphics architecture.

It is native cross-platform. According to the docs, it even uses
hardware acceleration where available.

And yes, it produces real, actual vector output (PS, PDF and supposedly
SVG although I had some issues with that), not just a bitmap with a
PS/PDF header. There are some PDF examples rendered with the CAIRO GRASS
driver at http://lars.ahlzen.com/cairograss/

I've read up a bit about Cairo today. I note that it has a mechanism
to fall back to rasterisation for operations which can't be
implemented by vector targets (surfaces).

In some situations, that may be useful; in others, it will be a
nuisance. In particular, it doesn't mean that GRASS can just forget
about vector targets and leave it to Cairo.

One of the main areas where this is relevant is if we want translucent
layers. It's possible to simulate translucency in PostScript using
pattern fills, but you need to be careful when selecting the grid
(frequency, phase, orientation) or else you can get artifacts.

It gets complex if you want more than one translucent layer, as you
have to plan all of the layers in advance (i.e. when drawing the
intermediate layers, you have to allow for layers which will be drawn
on top).

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

12

Glynn Clements wrote:

Brad Douglas wrote:

> The main thing to bear in mind is that the graphics system is going to
> be completely re-written for 7.x.

Could your provide details? I've seen bits here and there, but it would
be nice to have a summary of planned changes in one place.

Main points include:
...

I have taken liberty to add them here:
http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection#Display

Markus
--
View this message in context: http://www.nabble.com/Cairo-monitor-driver-tf4620004.html#a13208582
Sent from the Grass - Dev mailing list archive at Nabble.com.

13

> The problem with translucency is that not all rendering systems
> support it. The core X11 protocol doesn't, so you either need the
> Render extension or to perform the rendering client-side.

Not quite replying to right part of the thread, but I thought it should be
mentioned that (AFAIR) translucency in PDF >=1.4 is limited to vector fills.

Doing it client side can be a major performance hit. Apart from
anything else, all of the rendering has to be done in software; your
graphics hardware can't help.

Even if we use the much faster PNG(PPM) driver for fast GUI rendering, it sure
would be nice to click a "quality mode" switch in the GUI to switch to the
Cairo driver to create presentation quality output. For hardcopies (or softcopy
raster output for presentation or web publication) quality is much more
important than speed. (up the point it takes all night to render) For the GUI
speed becomes the important factor, quality is reduced to a nice bonus.

Hamish

      ____________________________________________________________________________________
Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
http://autos.yahoo.com/index.html

14

Glynn Clements wrote:

One of the main areas where this is relevant is if we want translucent
layers. It's possible to simulate translucency in PostScript using
pattern fills, but you need to be careful when selecting the grid
(frequency, phase, orientation) or else you can get artifacts.

Older versions of Surfer (the commercial 3D surface rendering program) that I
have used do that for area fills- shades of grey are many dots of varying
density. The PS output is a massive file which takes a silly amount of time to
render in gv and is generally an all-around PITA to work with. (meant as an
anecdote, not as a condemnation of the approach)

Hamish

____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/

15

Hamish wrote:

Older versions of Surfer (the commercial 3D surface rendering program) that I
have used do that for area fills- shades of grey are many dots of varying
density. The PS output is a massive file which takes a silly amount of time
to render in gv and is generally an all-around PITA to work with. (meant as
an anecdote, not as a condemnation of the approach)

oh, and the aliasing problems are horrible when you resize.

Hamish

____________________________________________________________________________________
Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/

16

Hamish wrote:

> Doing it client side can be a major performance hit. Apart from
> anything else, all of the rendering has to be done in software; your
> graphics hardware can't help.

Even if we use the much faster PNG(PPM) driver for fast GUI rendering, it sure
would be nice to click a "quality mode" switch in the GUI to switch to the
Cairo driver to create presentation quality output. For hardcopies (or softcopy
raster output for presentation or web publication) quality is much more
important than speed. (up the point it takes all night to render) For the GUI
speed becomes the important factor, quality is reduced to a nice bonus.

For presentation quality, I'm not sure that Cairo offers anything that
you can't get with PostScript. Either way, anti-aliasing should be
done using oversampling rather than at the primitive level.

The main obstacles are architectural, i.e. the use of integer
coordinates, hard-coded sizes (including line widths), and text
rasterisation (I can fix the last one easily enough for the PS
driver).

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

17

Hamish wrote:

> One of the main areas where this is relevant is if we want translucent
> layers. It's possible to simulate translucency in PostScript using
> pattern fills, but you need to be careful when selecting the grid
> (frequency, phase, orientation) or else you can get artifacts.

Older versions of Surfer (the commercial 3D surface rendering program) that I
have used do that for area fills- shades of grey are many dots of varying
density. The PS output is a massive file which takes a silly amount of time to
render in gv and is generally an all-around PITA to work with. (meant as an
anecdote, not as a condemnation of the approach)

That's just Surfer generating bad PostScript; it's probably
"capturing" its rendering at a low level, resulting in vast numbers of
individual "dots" being stored in the stream.

Level 2 PostScript supports a pattern "colour space", which allows you
to use a pattern as the fill colour. However, this can't be used for
painting images (this may be related to the similar restriction for
PDF; it would be interesting to see the PostScript generated when
printing such a PDF).

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

18

Brad Douglas wrote:

I can of course post code too, if anyone would be interested in actually trying it.

The code would certainly be useful.

+1

The source is up! Sorry about the delay.

I do realize that this is not the ideal format. A patch against the current 6.3 CVS tree would probably have been better, but apparently CVS doesn't let you add files even to your local copy without write access to the repository... oh well..

Anyhow, the code along with brief build and usage instructions are available at:

http://lars.ahlzen.com/cairograss/

The makefiles are a bit of a hack and need to be fixed. Hopefully they'll work, though. And the code in general is, as previously mentioned, experimental. But it can always be cleaned up if it seems worthwhile.

Feel free to try it out, and let me know if (when?) you run into problems building or using it, or if you have any other feedback!

I don't know what the policy is for posting experimental code like this to the patch tracker, so given its current state I opted for not doing this. Let me know if I should.

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

19

Can you give some examples of the usage? (not the final product, but
the commands)

thanks

Carlos

On 10/15/07, Lars Ahlzen <lars@ahlzen.com> wrote:

Brad Douglas wrote:
>>> I can of course post code too, if anyone would be interested in actually
>>> trying it.
>> The code would certainly be useful.
>
> +1

The source is up! Sorry about the delay.

I do realize that this is not the ideal format. A patch against the
current 6.3 CVS tree would probably have been better, but apparently CVS
doesn't let you add files even to your local copy without write access
to the repository... oh well..

Anyhow, the code along with brief build and usage instructions are
available at:

http://lars.ahlzen.com/cairograss/

The makefiles are a bit of a hack and need to be fixed. Hopefully
they'll work, though. And the code in general is, as previously
mentioned, experimental. But it can always be cleaned up if it seems
worthwhile.

Feel free to try it out, and let me know if (when?) you run into
problems building or using it, or if you have any other feedback!

I don't know what the policy is for posting experimental code like this
to the patch tracker, so given its current state I opted for not doing
this. Let me know if I should.

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

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

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Visiting Researcher at Kingston University London - UK
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

Can't stop the signal.

20

Hi,
JFYI i have created a git repository of grass from the latest cvs version
to manage my grass code. Now i have a local copy
of the grass cvs (my own grass branch) using git and i’m able commit, update and diff
code and new files to my branch
without read or write access to the grass cvs repository. And this is really nice. :slight_smile:
And i’m able to commit the code later to cvs.

Using git you can even check in code without an internet access
having all the log data and history on your local disk.

The git repository is located here:
http://www-pool.math.tu-berlin.de/~soeren/grass/files/grass.git.tar.bz2
so everybody who is interested in using a nice SCM to manage there code
without access to the grass cvs can use it.

Here is an introduction from Linus into git (be aware, many of us are stupid and ugly in his eyes :wink: ):
http://www.youtube.com/watch?v=4XpnKHJAok8

This is a short introduction into git and cvs:
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
http://issaris.blogspot.com/2005/11/cvs-to-git-and-back.html
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html

I hope this helps a bit to manage local grass copies.
Best regards
Soeren

2007/10/15, Carlos Guâno Grohmann <carlos.grohmann@gmail.com>:

Can you give some examples of the usage? (not the final product, but
the commands)

thanks

Carlos

On 10/15/07, Lars Ahlzen <lars@ahlzen.com> wrote:

Brad Douglas wrote:

I can of course post code too, if anyone would be interested in actually
trying it.
The code would certainly be useful.

+1

The source is up! Sorry about the delay.

I do realize that this is not the ideal format. A patch against the
current 6.3 CVS tree would probably have been better, but apparently CVS
doesn’t let you add files even to your local copy without write access
to the repository… oh well…

Anyhow, the code along with brief build and usage instructions are
available at:

http://lars.ahlzen.com/cairograss/

The makefiles are a bit of a hack and need to be fixed. Hopefully
they’ll work, though. And the code in general is, as previously
mentioned, experimental. But it can always be cleaned up if it seems
worthwhile.

Feel free to try it out, and let me know if (when?) you run into
problems building or using it, or if you have any other feedback!

I don’t know what the policy is for posting experimental code like this
to the patch tracker, so given its current state I opted for not doing
this. Let me know if I should.

/ Lars

–
Lars Ahlzen
lars@ahlzen.com

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

–
±----------------------------------------------------------+
Carlos Henrique Grohmann - Guano
Visiting Researcher at Kingston University London - UK
Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
±----------------------------------------------------------+

“Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive.”
–The winning entry in a “What were HAL’s first words” contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

Can’t stop the signal.

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