Boundless recording surfaces do not currently work with svgs

[hustf]

This is included as a comment in /test/test-snapshot.jl

# It seems that the svg device called by Cairo fails to find
# a size reference from unbounded recording surfaces. Botched up svgs
# include "-1.#QNAN", or very long strings. This occurs with and
# without 'Pro api' text on the drawing.
# However, it seems that if an svg has previously been rendered from a surface
# with bounds, the svg renderer works normally with unbounded surfaces.

If somehow Cairo.jl could be provided with the size reference it seems to need for svg drawings, a boundless recording surface could be provided by default. This could be quite useful for scripting if combined with get-extents. Scripting users could get instant results displayed without boilerplate.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[hustf]

Keeping this alive...

With Luxor release 2.11.0, we have recording surfaces and snapshots. There's now more motivation to start the groundwork for boundless surfaces in Cairo.

I'm dreaming of using Luxor as an engineering sketch tool, where you naturally work along a roll of paper which extends as your argument grows down the page. Or to the side, if you work that way. And with gridded paper, if you're that kind of person.

For short stubs, Luxor already works great for this. But if we put in the necessary pull request to Cairo.jl, Luxor can form the core part of such a tool, along with Latexify, Plots, and a zoom / move around viewer like MiniFB. The live viewer could be supported by an async loop.

[cormullion]

Cool! I'll add a label so that this stays open.

[oheil]

Is there an example for what this is about? For me it's not clear what is meant with "boundless surfaces". What is here to be expected to work, what doesn't work? Any code examples?

[hustf]

Just to let you know I saw the comment, and will provide an example at first opportunity. I also need a little time to remember the details here.

[hustf]

I made an example repo with the kind of scripting workflow I'm describing. issue150.jl contains
some functions documented with examples.

include("issue150.jl")

Paste from ?snap:

    Drawing(NaN, NaN, :rec)
    reset_INK_EXTENTS() # Not necessary in a fresh session
    background("deepskyblue2")
    setcolor("gold2")
    circle(O, 100, :fill) |> encompass
    setcolor("white")
    setfont("Sans", 100)
    settext("☼", O + (-34, 50); markup=true)
    snap("The sun")
    setline(10)
    ellipse(O, O + (550, 150), 1200, :stroke) |> encompass
    snap("A planetary orbit")
    setline(20)
    ellipse(O, O + (-550, 5500), 7000, :stroke) |> encompass
    snap() do
        setcolor("black")
        circle(O, 3, :fill)
        setcolor("darkgreen")
        settext("Comet's orbit", O + (-100, -120))
        settext("Origin of \nthis overlay", O; markup=true, valign="bottom")
    end

Each snap outputs a .png (works well) and an .svg (not so well) file (and shows the png in editor).

I'm including the last two here:

[hustf]

As per oheil's questions: A boundless recording surface is created with Drawing(NaN, NaN, :rec).

If the pull request linked above is merged into Cairo.jl, we won't need to keep track of where we are drawing on the boundless surface. In the example above, we keep track of extents with encompass(..).

The linked example works thanks to the amazing thread safety PRs from oheil.

[oheil]

Thanks for these examples and explanations, I will have a look when I have some spare time...

[oheil]

I checked and think part of it is a original Cairo problem. For SVG setting a background color is realized as a <rect ...>. It seems that Cairo ignores the cropping box coordinates for the background <rect..>. See:

using Luxor, Colors
d=Drawing(NaN, NaN, :rec)
background("deepskyblue2")
snapshot(;fname="test.svg",cb=BoundingBox(Point(-50,-50),Point(300,300)))

results in:

<svg ... viewBox="0 0 350 350" ... >
...
<rect x="0" y="0" width="16777215" height="16777215" .../>
...
<use ... transform="matrix(1,0,0,1,50,50)"/>

The transformation results in an effective <rect ...> of:

<rect x="50" y="50" width="16777215+50" height="16777215+50" .../>

In the example Cairo should create a svg <rect ...> of:

<rect x="-50" y="-50" width="16777215" height="16777215" .../>

Setting width and height to these arbitrary large values is questionable too. Why not just setting them to the size of the viewBox (350,350)? I don't know enough of Cairo to open a good bug report there.

[oheil]

As setting the background with function backgound is realized in cairo (for svg) by just drawing a large rectangle, how about doing the same but already in Luxor.jl, e.g.:

function background(col::Colors.Colorant)
    gsave()
    setcolor(col)
    #paint()
    rect(-16777215/2,-16777215/2,16777215,16777215;action=:fill)
    r, g, b, a = get_current_redvalue(), get_current_greenvalue(), get_current_bluevalue(), get_current_alpha()
    grestore()
    return (r, g, b, a)
end

Perhaps there must be a check if current Drawing has no bounding box, I didn't implemented it, so just thinking about.
What do you think, would this be a workaround?
As far as I can think (which is not so far) this would solve/workaround all examples above.

[hustf]

That is certainly a solution for some cases. About which, see 2).

Potential disadvantages would be felt on the rendering side, hence not necessarily our problem. The svg specification might be called bloated when it comes to scales and coordinate systems, so we shouldn't be surprised if various browsers and applications do their own simplifications.

The large values should probably be from typemin and typemax, with UInt16 or whatever Cairo uses.

I believe we might need a test for the type of drawing as well? This is applicable to svg of course. But what about recording surfaces? Much of the point of recording surfaces is that we can produce bitmaps initially, but output a vector drawing in the end. Would this great big rectangle lead to the bitmap rendererer allocating 16777215² pixels somewhere?

Summary: Test to see if it works?