See https://github.com/diagrams/diagrams-core/blob/master/src/Diagrams/Core/Types.hs#L834 for the MultiBackend class.

Generating multiple pages can be done by calling

http://hackage.haskell.org/packages/archive/cairo/0.12.3.1/doc/html/Graphics-Rendering-Cairo.html#v:showPage

which is a binding to

http://www.cairographics.org/manual/cairo-cairo-surface-t.html#cairo-surface-show-page

Multiple pages are supported for PDF, PS, and SVG. Not sure what should be done if the user calls renderDias but requests an output type that doesn't support it (PNG). Perhaps just exit with an error.

(Imported from http://code.google.com/p/diagrams/issues/detail?id=16. Original issue from [email protected] on April 2, 2011, 06:07:57 PM UTC)

See the #diagrams IRC logs from 1 April 2011 for some ideas on what could be done here.

I’m using Diagrams.Backend.Cairo.Cmdline.mainWith, passing an Animation B R2. Running the resulting program creates many frames. Running it with -l creates only the first one.

This is diagrams 1.2.

(Imported from http://code.google.com/p/diagrams/issues/detail?id=11. Original issue from [email protected] on December 27, 2010, 11:00:13 PM UTC)

The examples in the example/ directory of the Cairo repository ought to be converted to make use of the new command-line utility. In fact, it might make sense to put all the examples together in ONE big file, which will generate a command-line program that allows for any example to be selected.

After updating to the latest version of vector-space, I get the following build error:

Building diagrams-cairo-0.5.0.2...
Preprocessing library diagrams-cairo-0.5.0.2...
[1 of 5] Compiling Diagrams.Backend.Cairo.Internal ( src/Diagrams/Backend/Cairo/Internal.hs, dist/build/Diagrams/Backend/Cairo/Internal.o )
[2 of 5] Compiling Diagrams.Backend.Cairo.Text ( src/Diagrams/Backend/Cairo/Text.hs, dist/build/Diagrams/Backend/Cairo/Text.o )

src/Diagrams/Backend/Cairo/Text.hs:145:53:
    Couldn't match expected type `Point v0' with actual type `R2'
    In the return type of a call of `textSize'
    In the second argument of `(^+^)', namely `(textSize te)'
    In the second argument of `fromCorners', namely
      `(origin .+^ bearing te ^+^ (textSize te))'

src/Diagrams/Backend/Cairo/Text.hs:146:25:
    Couldn't match type `V b0' with `R2'
    Expected type: Envelope R2
      Actual type: Envelope (V b0)
    In the return type of a call of `getEnvelope'
    In the first argument of `setEnvelope', namely `(getEnvelope box)'

Hi,
could you please relax the upper version bound of diagrams-cairo-1.4 for the base library from base (>=4.2 && <4.10) to base (>=4.2 && <4.11) maybe with a revision on hackage. I tested building with the relaxed constraint on archlinux with GHC-8.2.1 and it worked flawlessly. Thanks for your work on diagrams!
Best wishes
Florian

Confirmed to build with optparse-applicative 0.16.1.0 and base 4.14.1.0.

See the failing test fill-line at http://projects.haskell.org/diagrams/backend-tests/all-index.html . The agreed-upon semantics for diagrams is that only loops are filled whereas lines are not. Unfortunately, most rendering backends fill even non-closed paths if any fill is set. To fix this will require some preprocessing of paths to separate out the lines and loops into two separate paths (this part can and should be implemented as a utility in diagrams-lib), and then drawing the lines with no fill set.

{-# LANGUAGE NoMonomorphismRestriction #-}

import Diagrams.Prelude
import Diagrams.Backend.Cairo.CmdLine

import Data.Array

phi :: Double
phi = (1+sqrt 5)/2

hkite = triangle 1 # scaleY ((sqrt (phi**2 - 0.25))*2/sqrt 3) # alignBR # fc lightblue # lw thin
hdart = triangle 1 # scaleY ((sqrt (1/phi**2 - 0.25))*2/sqrt 3) # alignBL # fc yellow # lw thin

tiling :: Array (Int, Int) (Diagram Cairo R2)
tiling = listArray ((0, 0), (1, 10)) [penrose t n | t <- [0..1], n <- [0..10]]
penrose t 0 = if t == 0 then hdart else hkite
penrose 0 n = (tiling ! (1, n-1) # scaleX (-1) # alignBL # rotate (-108 @@ deg) # scale (1/phi**2) <>
               tiling ! (0, n-1) # rotate (-144 @@ deg) # scale (1/phi)) # alignBL
penrose 1 n = (tiling ! (0, n-1) # alignBL # rotate (108 @@ deg) <>
               tiling ! (1, n-1) # scaleX (-1) # rotate (144 @@ deg) # scale (1/phi) <>
               tiling ! (1, n-1) # rotate (108 @@ deg) # scale (1/phi)) # alignBR

main = mainWith $ map (\s -> (tiling ! (0, s), 60 :: Int )) [0..8]

I use yellow and light blue colors in this code but in the actual gif yellow gets replaced with some kind of brown (besides the very first frame). Other colors, like red or orange work as intended.
This problem appears with diagrams-cairo-1.2.

(Imported from http://code.google.com/p/diagrams/issues/detail?id=72. Original issue from [email protected] on March 11, 2012, 03:02:50 PM UTC)

What steps will reproduce the problem?

1. Write a diagrams program and compile it.
2. Render it to a PDF.
3. Try to open it in Preview

What is the expected output? What do you see instead?
Expected: Preview opens it
Actual: Preview complains: "It may be damaged or use a file format that Preview doesn’t recognize."

What version of the product are you using? On what operating system?
diagrams-0.5
ghc-7.0.4
OS X Lion
Preview 5.5.1

Please provide any additional information below.
Attached is the diagrams program I used.

I see master already builds on GHC 8.6. Could this be released?

I've created diagrams-gi-cairo, a fork of the diagrams-cairo repository to work with haskell-gi instead of gtk2hs. As you might expect, the actual code changes are quite minor, mostly it's wrangling packages and modules.

It seems to work with the one diagram I tried.

Please accept ownership of the project. Think of this as a PR for the addition of an entire repository.

• Copy the repository into the diagrams team
• Review the changes I've made
• Adjust the documentation, etc.
• Probably, put back the version bounds in the .cabal file
• Make a release to Hackage

Consider the following code:

main = do
  txt <- textLineBoundedIO (mempty # fontSize 1) "Washington"
  defaultMain $ (txt <> boundingRect txt) # centerXY # pad 1.1

Here's the output I get:

As you can see, the envelope extends too far to the right. (Just to clarify, I believe the envelope is correct vertically, given the intended semantics of textLineBoundedIO.)

I thought it might have something to do with proportional-width fonts, so I tried the same program but with "Washington" replaced by "iiiiiiiiii". That made the program crash with

user error (invalid matrix (not invertible))

and I'm not sure exactly where that's coming from. Perhaps the envelope has zero width...

At the moment, the base dependency version of diagrams-cairo from https://hackage.haskell.org/package/ shows:

base (>=4.2 && <4.20),

However, after downloading the actual file from https://hackage.haskell.org/package/diagrams-cairo-1.4.2.1/diagrams-cairo-1.4.2.1.tar.gz and extract the diagrams-cairo.cabal, it shows

Build-depends: base >= 4.2 && < 4.19,

This causes diagrams-cairo to fail to compile on the latest ghc-9.8.1 version.

(Imported from http://code.google.com/p/diagrams/issues/detail?id=42. Original issue from [email protected] on August 30, 2011, 02:41:43 PM UTC)

What steps will reproduce the problem?

1. compile "main = defaultMain $ cat (1,0) (replicate 500 $ cat (0,1) (replicate 500 $ image "any.png" 205 205))"
2. ./main -ofoo.pdf -w3000 -h3000

Should result in a long wait and foo.pdf with plenty of images. Instead gobbles up all memory in the system.

What version of the product are you using? On what operating system?*

diagrams-cairo-0.3
diagrams-core-0.3
diagrams-lib-0.3

src/Diagrams/Backend/Cairo/Internal.hs:189:10:
    Couldn't match type `GHC.Generics.Rep (Options Cairo R2)'
                   with `GHC.Generics.M1
                           t0
                           t1
                           (GHC.Generics.M1
                              t2
                              t3
                              ((GHC.Generics.M1 t4 t5 (GHC.Generics.K1 t6 [Char])
                                GHC.Generics.:*: GHC.Generics.M1
                                                   t7 t8 (GHC.Generics.K1 t9 SizeSpec2D))
                               GHC.Generics.:*: (GHC.Generics.M1
                                                   t10 t11 (GHC.Generics.K1 t12 OutputType)
                                                 GHC.Generics.:*: GHC.Generics.M1
                                                                    t13
                                                                    t14
                                                                    (GHC.Generics.K1 t15 Bool))))'
    arising from a use of `hashable-1.2.1.0:Data.Hashable.Class.$gdmhashWithSalt'
    In the expression:
      (hashable-1.2.1.0:Data.Hashable.Class.$gdmhashWithSalt)
    In an equation for `hashWithSalt':
        hashWithSalt
          = (hashable-1.2.1.0:Data.Hashable.Class.$gdmhashWithSalt)
    In the instance declaration for `Hashable (Options Cairo R2)'
Failed to install diagrams-cairo-1.0.1

Full build log from Stackage available at: https://gist.github.com/snoyberg/8683484

(Imported from http://code.google.com/p/diagrams/issues/detail?id=54. Original issue from [email protected] on September 10, 2011, 01:25:42 AM UTC)

Currently, if you use an Image primitive and specify a file name that does not exist, the generated program simply crashes with the error

user error (file not found)

Instead, it ought to print a warning and use an empty diagram in place of the image.

I'v written a small gtk based program for doing simple vector stuff like graham scan. Since animations are still experimental I went with generating a gif via gifMain. However, that of course conflicts with the gtk gui concept. I'd like to somehow access one of the lower level functions so that I can generate a gif from within my gtk gui. gifRender looks like the right function to do so if I am not mistaken.

import Diagrams.Backend.Cairo.CmdLine
import Diagrams.Prelude

main :: IO ()
main = defaultMain dia

dia :: Diagram B R2
dia = triangle 1   # fc green # rotateBy (1/5)
   <> square   1.2 # fc white # lw 0

If you use this code with a width of 400 and produce a png, there's a small black line next to the rightmost vertex that should not be there. That also happens with different rotations, but only with that vertex (see this gif).

I tried it with the Cairo and the SVG backend; with the SVG backend, it looked fine.

The cairo backend yields <<loop>> when I try to run the following program:

{-# LANGUAGE NoMonomorphismRestriction #-}

import Diagrams.Prelude
import Diagrams.Backend.Cairo.CmdLine

import Control.Arrow
import Data.List

import Diagrams.TwoD.Layout.Tree hiding (leaf)
import Data.Tree

cunit :: String -> Tree String
cunit x = Node (x ++ ".o") [ Node (x ++ ".c") [] ]

t :: Tree String
t = Node "prog.exe"
    [ cunit "foo"
    , cunit "bar"
    , cunit "baz"
    ]

dia :: Diagram B
dia = lw thin
    . frame 0.5
    . renderTree (\t -> text t # fc (pickColor t) # fontSizeL 0.8 <> roundedRect 6 2 0.5 # fc white) (~~)
    . (fmap . second) reflectY
    . symmLayout' (with & slWidth  .~ const (-3,3)
                        & slHeight .~ const (-1,1)
                        & slHSep   .~ 2
                        & slVSep   .~ 2
                  )
    $ t    -- $

pickColor t
  | "c" `isSuffixOf` t = blue
  | "o" `isSuffixOf` t = green
  | otherwise          = red

main = defaultMain dia

When I am not working frantically on a talk I will try to come up with a stripped-down version. This example renders fine with the SVG backend.

(Imported from http://code.google.com/p/diagrams/issues/detail?id=47. Original issue from [email protected] on September 6, 2011, 04:38:48 PM UTC)

The diagarms-cairo Haddocks are quite minimal and ought to be improved.

(Imported from http://code.google.com/p/diagrams/issues/detail?id=63. Original issue from [email protected] on January 22, 2012, 05:10:33 PM UTC)

Compiling diagrams-cairo under GHC 7.2.1 or later currently gives this warning:

src/Diagrams/Backend/Cairo/Internal.hs:41:1:
Warning: In the use of `try'
(imported from System.IO.Error):
Deprecated: "Please use the new exceptions variant, Control.Exception.try"

Someone should look into this and figure out the Right Way (tm) to update to something non-deprecated (while being sure to preserve support for GHC 7.0.x, and even 6.12.x if possible).

It seems that

t <- textLineBoundedIO (mempty # fontSizeL 20) (Text mempty BoxbasealignedText "Hello World")

results in the envelope of t being computed at size 12 (px/pt/?), as witnessed by the discrepancy between the size of the text and its envelope by rendering

(t # showEnvelope)

versus

(t # fontSize (local 12) # showEnvelope)

Sifting through the documentation of diagrams-core reveals that FontSize is a measured attribute, which cannot simply be extracted via getAttr, resulting in textLineBoundedIO getting Nothing, and surely , fmap getFontSize (getAttr (mempty # fontSizeL 12)) == Nothing. I'm not sure what would be a good fix to this, as we cannot reasonably know what to pass to pango at this point, as the proper font size to select depends on the size the text eventually ends up at when rendered. Or if it is safe as long as the font size measure is Local?

Additionally, the fontSize attribute in the style argument to textLineBoundedIO is simply thrown away by the current implementation. I would expect it to be retained in the resulting Diagram.

(Imported from http://code.google.com/p/diagrams/issues/detail?id=25. Original issue from [email protected] on April 19, 2011, 02:53:51 PM UTC)

See attached file, which defines a path just by stroking the trail (1,0); but no output is generated (expected output would be a black line extending horizontally across the entire output image). By playing around with line width etc. it seems what is happening is that the 1-unit line is not getting resized to match the final 100-unit image. Note that uncommenting the rotation causes the line to get resized properly.

Most probably some sort of issue with UDTree...

I have a very strange issue with XQuartz on OS X (Mavericks).

I can render stuff like text "foo" just fine, but text "f" crashes with

Assertion failed: (!scaled_font->cache_frozen), function _cairo_scaled_glyph_page_destroy,
file cairo-scaled-font.c, line 459.

I traced this down to being an issue with what C.textExtents returns. If I patch the code so that it never calls textExtents on a string of length 1, it works fine.

Code used to debug: https://gist.github.com/jonashaag/8761779

-- Original code when given string of length 1
TextExtents {textExtentsXbearing = 0.0, textExtentsYbearing = -1.0, textExtentsWidth = 1.0,
textExtentsHeight = 1.0, textExtentsXadvance = 1.0, textExtentsYadvance = 0.0}

-- Patched code when given string of length 1, simply makes it a string of length 2
TextExtents {textExtentsXbearing = 0.0, textExtentsYbearing = -1.0, textExtentsWidth = 2.0,
textExtentsHeight = 1.0, textExtentsXadvance = 2.0, textExtentsYadvance = 0.0}

I'm not sure if this is a bug in the Diagrams Cairo backend or some other problem with XQuartz, Cairo, ... you name it. I'm happy for any pointers :)

(Imported from http://code.google.com/p/diagrams/issues/detail?id=71. Original issue from [email protected] on March 11, 2012, 04:37:49 AM UTC)

What steps will reproduce the problem?

1. Create a Haskell file importing Diagrams.Backend.Cairo (or a sub-module thereof)
2. Attempt to compile the file.
3. Wait till your patience runs out.

What is the expected output? What do you see instead?

I expect GHC to finish linking.

What version of the product are you using? On what operating system?
diagrams-0.5, diagrams-cairo-0.5.0.1, ghc-7.0.4
OS X Lion

Please provide any additional information below.

Importing Graphics.Rendering.Cairo does not cause this problem.

(Imported from http://code.google.com/p/diagrams/issues/detail?id=10. Original issue from [email protected] on December 27, 2010, 10:55:06 PM UTC)

D.Backend.Cairo.CmdLine contains the beginnings of a utility to make nice command-line-driven diagram generation programs. There are a number of ways it could be improved, including an option to list all the available diagrams, better error messages, and so on.

It seems that master can be built now with GHC 8.8 despite CI issues. Could you please release it?

(Imported from http://code.google.com/p/diagrams/issues/detail?id=13. Original issue from [email protected] on March 27, 2011, 03:49:12 PM UTC)

What steps will reproduce the problem?

1. Compile + run examples/gray.hs in the cairo repo. Should get a nice gray-code circle.
2. Now change the color by inserting "lc red" right before "lw 1.05", recompile and re-run.
3. Instead of a red gray-code circle you just get a giant red blob.

Marked Component-Cairo since it's showing up in a Cairo test file, but I'm not sure whether it's actually a problem in the Cairo backend or somewhere else...

Could we get a new release on Hackage? The latest Hackage version doesn't allow base 4.8, and so doesn't work with GHC 7.10.

This field is missing in the documentation of CairoOptions.

Instead of calling C.setSourceSurface (https://github.com/diagrams/diagrams-cairo/blob/master/src/Diagrams/Backend/Cairo/Internal.hs#L292) we ought to use withPatternForSurface to create a Pattern first, then apply patternSetFilter to set the Filter (http://hackage.haskell.org/packages/archive/cairo/0.12.4/doc/html/Graphics-Rendering-Cairo.html#t:Filter) to something other than the default. (Is there a best choice or should we make it configurable somehow? Perhaps an attribute?) Then finally we can call setSource with the pattern.

import Diagrams.Prelude
import Diagrams.Backend.Cairo.CmdLine

main :: IO ()
main = defaultMain dia

dia :: Diagram B R2
dia = (s1 ||| s1) <> s2
  where s1 = square 1 # lw 0 # fc white
        s2 = square 2 # lw 0 # fc crimson

Looks fine with width 100:

But there is a dark line between the squares with width 99:

Tested on Ubuntu 13.04, Cairo 1.12.14

The Travis build appears to currently be broken. (I noticed this while failing to install diagrams-cairo using GHC 7.10.1.)

(Imported from http://code.google.com/p/diagrams/issues/detail?id=36. Original issue from [email protected] on June 15, 2011, 03:17:52 PM UTC)

It appears that there is a serious bug in Cairo that prevents text from showing on Windows when showing text is proceeded by a call to transform the current transform matrix. moveTo, rotate, and scale calls all appear to work as expected.

Different versions of Cairo behave differently:

• Version 1.8.10 (gtk 2.20 all-in-one bundle) as described above.
• Version 1.10.2 (gtk 2.22 all-in-one bundle) fails with error:
  user error (invalid matrix (not invertible))
  This is the error CAIRO_STATUS_INVALID_MATRIX. The reason for this
  difference appears to be related to this change.
• Version 1.11.3 (Current head built locally). This build did not use freetype and that may explain the differences. Text did show, but when using a matrix transformation, it was clipped strangely ("hello world" was missing the 'h').

While this is not an issue with Diagrams directly I'm documenting here to keep track of things. The following code reproduces the issue:

import qualified Graphics.Rendering.Cairo as C
import qualified Graphics.Rendering.Cairo.Matrix as CM

main = C.withPSSurface "t.ps" 500 500 surfaceF
  where
    surfaceF s = C.renderWith s r'
    r' = do
      C.moveTo 100 100
      -- C.transform $ CM.Matrix 1.0 0.0 0.0 1.0 0.0 100.0 -- no text.
      -- C.transform $ CM.Matrix 1.0 0.0 0.0 1.0 0.0 0.0   -- works.
      C.translate 0.0 100.0 -- works
      C.showText "hello world"

Profiling this example diagram shows that the cairo backend spends most of the rendering time in color conversion code (colour:Data.Colour.*). I believe that this is the cause of some major sadness in our world.

-- Test.hs
import Control.Monad
import System.Environment
import Diagrams.Prelude
import Diagrams.Backend.Cairo
import Diagrams.Example.Logo

drawing = logo ||| logo ||| logo === logo

main = do
  [times] <- getArgs
  replicateM_ (read times) $ renderCairo "/dev/null" (Dims 1000 1000) drawing

Example invocation: ./Test +RTS -prof -RTS 20

Profiling results (first file is with only the interesting parts included): https://gist.github.com/jonashaag/8965334

Note that this report assumes diagrams version 1.0.x

(Imported from http://code.google.com/p/diagrams/issues/detail?id=14. Original issue from [email protected] on March 30, 2011, 08:54:05 PM UTC)

For example, currently black is used for drawing lines ... unless you set a fill color, in which case that color is used for drawing lines too! Not sure exactly what to do, but in general it should be a bit smarter about what to do when certain attributes are missing.

(Imported from http://code.google.com/p/diagrams/issues/detail?id=27. Original issue from [email protected] on May 2, 2011, 10:30:12 PM UTC)

When only the width or only the height is specified, the other should be computed based on the aspect ratio of the diagram, instead of using a default value of 100 as is currently done.

When I try to build with 7.6 there are errors due to directory now using time instead of old-time. This is in the build loop code which should probably be moved to some backend unspecific module building with diagrams-builder.

If one attempts to render an output with a height or width of zero, currently one simply gets an error like user error (error while writing to output stream). For example, given Test.hs containing

import           Diagrams.Backend.Cairo.CmdLine
import           Diagrams.Prelude

main = defaultMain (hrule 1)

we obtain the following:

$ ghc --make Test && ./Test -w 100 -o Test.png
[1 of 1] Compiling Main             ( Test.hs, Test.o )
Linking Test ...
Test: user error (error while writing to output stream)

Note that we only specify a width on the command line; if we specify an explicit height it works fine.

We should at the very least generate a nice error message; or perhaps we could replace a height of 0 by the width, and vice versa.

Currently blocked on (at least) hashtables. See commercialhaskell/stackage#2194 , http://hackage.haskell.org/package/hashtables .

(Imported from http://code.google.com/p/diagrams/issues/detail?id=78. Original issue from [email protected] on April 5, 2012, 02:09:03 AM UTC)

Consider the following code:

{-# LANGUAGE NoMonomorphismRestriction #-}

import Diagrams.Prelude
import Diagrams.Backend.Cairo.CmdLine

import Data.Colour

t1 = text "H" # fcA (black withOpacity 0.5) <> square 1 # lw 0

t2 = text "H" # opacity 0.5 <> square 1 # lw 0

main = defaultMain (t1 ||| t2)

I would expect both H's to be grey, but only the one on the left is. The way the cairo backend handles setting the fill and stroke colors is sort of a hack, and it looks like it's coming around to bite us here.

This should involve all the backends. There is a lot of redundancy in backend command line support that should be factored out into a separate package. Additionally there are use cases (such as GHCJS) that would just as well not have command line support so there should be a cabal flag to make it optional (or perhaps some abstraction that would make it useful in that setting).

ghc 7.6.1, diagrams-*-0.6, cairo-0.12.4, cairo lib 1.12.8 the following code generates a blank PDF on Arch Linux (only for PDF output, PS or PNG works perfectly and draws a quarter circle in the upper left corner)

import Diagrams.Prelude
import Diagrams.Backend.Cairo
import Diagrams.Backend.Cairo.Internal

p :: Picture
p = circle 100 # fc black

renderTest =
fst $ renderDia Cairo (CairoOptions "test.pdf" (Width 550) PDF True) p