[GRASS-dev] raster offset with cairo driver

GRASS GIS GRASS GIS developer
1

Hi,

I'm trying out the new Cairo driver. To make things easier I just added support for it to d.out.file: use the -c flag with a raster image format.

As AFAICT there is no user documentation, so I also added a small wiki page for it: http://grass.gdf-hannover.de/wiki/Cairo_driver

It is missing a display/drivers/cairo/description.html page, modeled after the equivalent PNG driver page.

There's a problem in that the raster data is being rendered offset vs. the vector data. For a window with the same aspect ratio as the region it seems to line up ok. Else, not.

e.g.
export GRASS_WIDTH=720
export GRASS_HEIGHT=585
d.mon x0
d.rast map=elevation.10m
d.vect map=streams width=1 color=blue
d.vect map=roads width=2

d.out.file -c sf_cairo format=png size=800,800

# even more dramatic
d.out.file -c sf_cairo1 format=png size=400,800
d.out.file -c sf_cairo3 format=png size=800,400

?
example: http://bambi.otago.ac.nz/hamish/grass/bugs/sf_cairo1.png

There's another problem with fonts- True/FreeType fonts gets scrambled.
This reminds me of a long ago bug in d.text.freetype, fixed in rev 1.42.
"use correct pitch for reading bitmap buffer & fix scrambled letters"
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/display/d.text.freetype/main.c

example: http://bambi.otago.ac.nz/hamish/grass/bugs/sf_cairo2.png
(d.* commands given on the above wiki page)

Hamish

2

Hamish wrote:

I'm trying out the new Cairo driver. To make things easier I just
added support for it to d.out.file: use the -c flag with a raster
image format.

As AFAICT there is no user documentation, so I also added a small wiki
page for it: http://grass.gdf-hannover.de/wiki/Cairo_driver

It is missing a display/drivers/cairo/description.html page, modeled
after the equivalent PNG driver page.

There's a problem in that the raster data is being rendered offset vs.
the vector data. For a window with the same aspect ratio as the region
it seems to line up ok. Else, not.

The code overlooks the fact that the top-left coordinates are
subjected to the scaling.

I should have a fix shortly.

There's another problem with fonts- True/FreeType fonts gets scrambled.
This reminds me of a long ago bug in d.text.freetype, fixed in rev 1.42.
"use correct pitch for reading bitmap buffer & fix scrambled letters"
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/display/d.text.freetype/main.c

example: http://bambi.otago.ac.nz/hamish/grass/bugs/sf_cairo2.png
(d.* commands given on the above wiki page)

I was looking into this; it appears that I forgot about it.

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

3

Glynn Clements wrote:

> I'm trying out the new Cairo driver. To make things easier I just
> added support for it to d.out.file: use the -c flag with a raster
> image format.
>
> As AFAICT there is no user documentation, so I also added a small wiki
> page for it: http://grass.gdf-hannover.de/wiki/Cairo_driver
>
> It is missing a display/drivers/cairo/description.html page, modeled
> after the equivalent PNG driver page.
>
>
> There's a problem in that the raster data is being rendered offset vs.
> the vector data. For a window with the same aspect ratio as the region
> it seems to line up ok. Else, not.

The code overlooks the fact that the top-left coordinates are
subjected to the scaling.

I should have a fix shortly.

Fixed in CVS.

> There's another problem with fonts- True/FreeType fonts gets scrambled.
> This reminds me of a long ago bug in d.text.freetype, fixed in rev 1.42.
> "use correct pitch for reading bitmap buffer & fix scrambled letters"
> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/display/d.text.freetype/main.c
>
> example: http://bambi.otago.ac.nz/hamish/grass/bugs/sf_cairo2.png
> (d.* commands given on the above wiki page)

I was looking into this; it appears that I forgot about it.

This appears to be a cairo bug. It doesn't appear to like using
surfaces whose strides aren't multiples of four as sources.

Dumping the surface to a PNG file with cairo_surface_write_to_png()
shows the correct data, but using the surface as a source for
cairo_mask_surface(), cairo_set_source_surface() etc produces garbled
output. This doesn't affect ARGB surfaces, which are always word
aligned.

I've added a workaround in CVS.

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

4

Hamish wrote:

Hi,

I'm trying out the new Cairo driver. To make things easier I just
added support for it to d.out.file: use the -c flag with a raster
image format.

Thanks, any testing is certainly appreciated! Having d.out support makes a lot of sense, too.

As AFAICT there is no user documentation, so I also added a small
wiki page for it: http://grass.gdf-hannover.de/wiki/Cairo_driver

It is missing a disiplay/drivers/cairo/description.html page, modeled
after the equivalent PNG driver page.

I'd happily add a HTML user documentation page, similar to those of the other drivers. Where would I post it once it's done?

There's a problem in that the raster data is being rendered offset
vs. the vector data...

There's another problem with fonts- True/FreeType fonts gets
scrambled...

I see that Glynn already committed fixes to CVS for these problems (thanks Glynn!) which seem to work well.

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

5

Hamish wrote:

Hi,

I'm trying out the new Cairo driver....

It is missing a display/drivers/cairo/description.html page, modeled
after the equivalent PNG driver page.

I created a basic documentation page (attached). The examples on the wiki page made sense - I hope you don't mind me using them verbatim. :slight_smile:

Feel free to add to CVS.

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

(attachments)

description.html.bz2 (2.34 KB)

6

Hamish wrote:
> I'm trying out the new Cairo driver....
>
> It is missing a display/drivers/cairo/description.html page, modeled
> after the equivalent PNG driver page.

Lars:

I created a basic documentation page (attached). The examples on the
wiki page made sense - I hope you don't mind me using them verbatim. :slight_smile:

Feel free to add to CVS.

thanks, done.

still to be done is to add ./configure --with-cairo checks instead of "make
USE_CAIRO=1".

also d.out.file needs to be extended for SVG, Cairo's PS, etc. (I'll take care
of that)

Is GRASS_TRUECOLOR needed in the example?

Hamish

      ____________________________________________________________________________________
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/

7

Lars Ahlzen wrote:

> I'm trying out the new Cairo driver....
>
> It is missing a display/drivers/cairo/description.html page, modeled
> after the equivalent PNG driver page.

I created a basic documentation page (attached). The examples on the
wiki page made sense - I hope you don't mind me using them verbatim. :slight_smile:

Feel free to add to CVS.

Done.

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

8

Hamish wrote:

Is GRASS_TRUECOLOR needed in the example?

The cairo driver doesn't use that variable; cairo only supports true
colour.

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

9

Hamish wrote:

I'm trying out the new Cairo driver....

still to be done is to add ./configure --with-cairo checks instead of "make
USE_CAIRO=1".

Yes. Perhaps someone who is more comfortable with autotools and the GRASS build system than I could give this a shot?

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

10

Hi,

raster offset and fonts now look ok, good stuff guys.

I've updated the fancy example on the wiki page to show off the fancy compass:
http://grass.gdf-hannover.de/wiki/Cairo_driver#Examples

d.out.file now has added support for ps, svg, and pdf by way of the Cairo
driver.

but it doesn't work, I get output like this for the simple spearfish example:

$ cat spearfish.ps
%!PS-Adobe-3.0
%%Creator: cairo (http://cairographics.org)
%%CreationDate: Tue Nov 27 17:12:30 2007
%%Pages: 0
%%BoundingBox: 0 0 800 800
%%DocumentData: Clean7Bit
%%LanguageLevel: 2
%%EndComments
%%BeginProlog
/C{curveto}bind def
/F{fill}bind def
/G{setgray}bind def
/L{lineto}bind def
/M{moveto}bind def
/P{closepath}bind def
/R{setrgbcolor}bind def
/S{show}bind def
%%EndProlog
% _cairo_ps_surface_emit_font_subsets
%%Trailer
%%EOF

$ cat spearfish.svg
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg&quot;
xmlns:xlink="http://www.w3.org/1999/xlink&quot; width="800pt" height="800pt"
viewBox="0 0 800 800" version="1.1">
<defs>
<clipPath id="clip0">
  <rect width="800" height="800"/>
</clipPath>
</defs>
<g id="surface0" clip-path="url(#clip0)">
</g>
</svg>

$ cat spearfish.pdf
%PDF-1.4
%µí®û
%PDF-1.4
%µí®û
1 0 obj
<< /Type /Pages
   /Kids
   /Count 0
   /Resources <<
      /Font <<
      >>
   >>

endobj
2 0 obj
<< /Creator (cairographics.org)
   /Producer (cairographics.org)

endobj
3 0 obj
<< /Type /Catalog
   /Pages 1 0 R

endobj
xref
0 4
0000000000 65535 f
0000000017 00000 n
0000000133 00000 n
0000000221 00000 n
trailer
<< /Size 4
   /Root 3 0 R
   /Info 2 0 R

startxref
278
%%EOF

also, is it possible for the Cairo driver in PS and PDF modes to respect
GRASS_LANDSCAPE and GRASS_PAPER like the GRASS PS driver?

thanks,
Hamish

      ____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

11

Hamish wrote:

raster offset and fonts now look ok, good stuff guys.

I've updated the fancy example on the wiki page to show off the fancy compass:
http://grass.gdf-hannover.de/wiki/Cairo_driver#Examples

d.out.file now has added support for ps, svg, and pdf by way of the Cairo
driver.

but it doesn't work, I get output like this for the simple spearfish example:

[snip]

It works for me. Where "works" means "renders everything then dumps
the resulting raster image to a 14MiB PostScript file".

Well, that rules out using cairo for the core of the 7.x graphics
architecture.

also, is it possible for the Cairo driver in PS and PDF modes to respect
GRASS_LANDSCAPE and GRASS_PAPER like the GRASS PS driver?

That shouldn't be hard.

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

12

On Monday 26 November 2007, Glynn Clements wrote:

Hamish wrote:
> raster offset and fonts now look ok, good stuff guys.
>
> I've updated the fancy example on the wiki page to show off the fancy
> compass: http://grass.gdf-hannover.de/wiki/Cairo_driver#Examples
>
>
> d.out.file now has added support for ps, svg, and pdf by way of the Cairo
> driver.
>
> but it doesn't work, I get output like this for the simple spearfish
> example:

[snip]

It works for me. Where "works" means "renders everything then dumps
the resulting raster image to a 14MiB PostScript file".

... thats strange.. it wrote out a 2mb file using the "complicated example",
listed at the bottom of the wiki page on Cairo...

Dylan

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

13

Dylan Beaudette wrote:

> > raster offset and fonts now look ok, good stuff guys.
> >
> > I've updated the fancy example on the wiki page to show off the fancy
> > compass: http://grass.gdf-hannover.de/wiki/Cairo_driver#Examples
> >
> >
> > d.out.file now has added support for ps, svg, and pdf by way of the Cairo
> > driver.
> >
> > but it doesn't work, I get output like this for the simple spearfish
> > example:
>
> [snip]
>
> It works for me. Where "works" means "renders everything then dumps
> the resulting raster image to a 14MiB PostScript file".

... thats strange.. it wrote out a 2mb file using the "complicated example",
listed at the bottom of the wiki page on Cairo...

If I try it, the resulting PostScript file is 26MiB.

Does your PostScript file contain identifiable vector data, or is it
just one big base85-encoded raster?

Which version of cairo are you using?

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

14

On Tuesday 27 November 2007, Glynn Clements wrote:

Dylan Beaudette wrote:
> > > raster offset and fonts now look ok, good stuff guys.
> > >
> > > I've updated the fancy example on the wiki page to show off the fancy
> > > compass: http://grass.gdf-hannover.de/wiki/Cairo_driver#Examples
> > >
> > >
> > > d.out.file now has added support for ps, svg, and pdf by way of the
> > > Cairo driver.
> > >
> > > but it doesn't work, I get output like this for the simple spearfish
> > > example:
> >
> > [snip]
> >
> > It works for me. Where "works" means "renders everything then dumps
> > the resulting raster image to a 14MiB PostScript file".
>
> ... thats strange.. it wrote out a 2mb file using the "complicated
> example", listed at the bottom of the wiki page on Cairo...

If I try it, the resulting PostScript file is 26MiB.

Does your PostScript file contain identifiable vector data, or is it
just one big base85-encoded raster?

Which version of cairo are you using?

Ack -- looks like i didn't exactly reproduce Hamish's example.

oops!

Dylan

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

15

Glynn Clements wrote:

Hamish wrote:

raster offset and fonts now look ok, good stuff guys.

I've updated the fancy example on the wiki page to show off the fancy compass:
http://grass.gdf-hannover.de/wiki/Cairo_driver#Examples

d.out.file now has added support for ps, svg, and pdf by way of the Cairo
driver.

but it doesn't work, I get output like this for the simple spearfish example:

[snip]

It works for me. Where "works" means "renders everything then dumps
the resulting raster image to a 14MiB PostScript file".

Cairo does have an unfortunate tendency to sometimes render to raster and embed that into the requested format, presumably as some kind of "last resort" when it (or the selected format) doesn't support some drawing operation.

I haven't done enough testing to figure out exactly when this happens or what triggers it.

Well, that rules out using cairo for the core of the 7.x graphics
architecture.

Perhaps. Then again,

* Depending on what the options are, it might be a lot easier to find those cases where Cairo goes into "raster rendering" mode and work around them or otherwise prevent them from happening. While this is not explicitly mentioned in the Cairo documentation (AFAIK), the Cairo developers (or the source) might be able to provide more insight.

* While Cairo is fairly mature today, I'm sure it will improve further before GRASS 7 is out. Some, or all, of these problems might even be gone by then. Especially if these issues are actually mentioned as a problem to the Cairo devs... :slight_smile:

Granted, is hard to predict what will happen in the future, but at this point, I wouldn't entirely dismiss Cairo as an option.

Of course, that's just my two cents...

/ Lars

--
Lars Ahlzen
lars@ahlzen.com

16

Lars Ahlzen wrote:

>> raster offset and fonts now look ok, good stuff guys.
>>
>> I've updated the fancy example on the wiki page to show off the fancy compass:
>> http://grass.gdf-hannover.de/wiki/Cairo_driver#Examples
>>
>>
>> d.out.file now has added support for ps, svg, and pdf by way of the Cairo
>> driver.
>>
>> but it doesn't work, I get output like this for the simple spearfish example:
>
> [snip]
>
> It works for me. Where "works" means "renders everything then dumps
> the resulting raster image to a 14MiB PostScript file".

Cairo does have an unfortunate tendency to sometimes render to raster
and embed that into the requested format, presumably as some kind of
"last resort" when it (or the selected format) doesn't support some
drawing operation.

I haven't done enough testing to figure out exactly when this happens or
what triggers it.

Found it. GRASS_TRANSPARENT=TRUE causes the raster fallback. Not
really surprising when you think about it.

> Well, that rules out using cairo for the core of the 7.x graphics
> architecture.

Perhaps. Then again,

After having done several tests without ever getting it to produce
vector (i.e. not pre-rendered) output, I had concluded that the
PostScript backend was "faking it".

Removing the GRASS_TRANSPARENT=TRUE from my environment results in
genuine vector output, at least if you only use vector output

However, the output of d.rast is pre-rendered (the output is much
larger than it should be), and any following d.vect commands are also
pre-rendered.

Also, the PostScript which it generates for rasters is suboptimal to
say the least. It stores the raster data as a string and decodes it
from there, rather than streaming from currentfile. This is likely to
present a problem for printing large rasters; unlike desktop systems,
printers typically don't have gigabytes of RAM.

So, it's still not able to obsolete the PS driver. Initially, this
isn't likely to be a problem; cairo's drawing model is close enough to
PostScript that it would be feasible to maintain both drivers in the
short term.

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

17

So, it's still not able to obsolete the PS driver. Initially, this
isn't likely to be a problem; cairo's drawing model is close enough to
PostScript that it would be feasible to maintain both drivers in the
short term.

I had expected from the current Tcl/wxPy work that the PNG driver would be the
mainstay of the GRASS 7 desktop GUI rendering. Do I detect a hint that the PS
driver may be challenging it for that role? (with some ps2ppm magic) Or what
about the choice of Cairo vs. the PNG driver for ppm-backed GUI display
windows?
It is kind of cool to think that they may be somewhat interchangable for GUI
rendering.

Hamish

      ____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs

18

Hamish wrote:

> So, it's still not able to obsolete the PS driver. Initially, this
> isn't likely to be a problem; cairo's drawing model is close enough to
> PostScript that it would be feasible to maintain both drivers in the
> short term.

I had expected from the current Tcl/wxPy work that the PNG driver would be the
mainstay of the GRASS 7 desktop GUI rendering. Do I detect a hint that the PS
driver may be challenging it for that role?

Yes. The original intention was that libraster would generate
PostScript, which would be rendered with Ghostscript for raster
output.

(with some ps2ppm magic) Or what
about the choice of Cairo vs. the PNG driver for ppm-backed GUI display
windows?
It is kind of cool to think that they may be somewhat interchangable for GUI
rendering.

The idea was to avoid having to maintain multiple drivers along with a
mechanism to dispatch R_* calls to the appropriate driver. All calls
would produce PostScript, and the only thing that would need to be
"dispatched" is the output stream.

There isn't any point maintaining both the cairo and PNG drivers.
cairo does everything the PNG driver does, and does a better job of
it.

If cairo could generate decent PostScript, then mapping R_* functions
to cairo functions would achieve the same result but would be quicker
for generating raster output.

Unfortunately, cairo seems too ready to fall-back to rasterising
everything, and doesn't do a particularly good job of handling raster
output (it requires that the entire raster can fit into the
interpreter's VM; not a problem when running Ghostscript on a PC, but
a significant problem for printers).

The main issue is ensuring that the fall-backs can be prevented. The
raster issue can be solved by splitting rasters into strips.

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