This would indeed be great to have; even a page selector when importing a multi-page document would be an improvement (the Adobe Illustrator version I've use had that; IIRC it would just leave all other pages of the document alone).

You should also test with PDF documents; in my experience Karbon 3.1 works well enough with them.

Ported to use pageapp classes.

...

A lot of code was duplicated between pageapp and karbon
and has been removed from karbon:

Shouldn't that be a separate change - or does multi-page support come automatically with this change?

In D19216#417288, @rjvbb wrote:

This would indeed be great to have; even a page selector when importing a multi-page document would be an improvement (the Adobe Illustrator version I've use had that; IIRC it would just leave all other pages of the document alone).

You should also test with PDF documents; in my experience Karbon 3.1 works well enough with them.

Yes, pdf docs work, it is almost 100% handled by poppler.

...

A lot of code was duplicated between pageapp and karbon
and has been removed from karbon:

Shouldn't that be a separate change - or does multi-page support come automatically with this change?

Well, my initial thought, but there was going to be quite a few intermidiate solutions mainly because
the KoPACanvas cannot be subclassed, so I decided to do everything in one go.

Canvas color:
I don't quite see what it is for. You can set a background color for the canvas but it is only for the views, it is not printed.

A custom canvas colour feature doesn't strike me as odd, nor that it isn't printed (printing it WITHOUT setting a dedicated option would seem wrong to me).

What about when you use an inversed theme, isn't a custom canvas colour required then if you want to see your black line art on a light (white) canvas?

In D19216#417502, @rjvbb wrote:

Canvas color:
I don't quite see what it is for. You can set a background color for the canvas but it is only for the views, it is not printed.

A custom canvas colour feature doesn't strike me as odd, nor that it isn't printed (printing it WITHOUT setting a dedicated option would seem wrong to me).

What about when you use an inversed theme, isn't a custom canvas colour required then if you want to see your black line art on a light (white) canvas?

No, the canvas is part of the document and must never be themed. The canvas background is as much part of your drawing as any line you put on it.

totally agree about not theme'ing canvas

Also a general agreement to do the page app thing as long as it's also supported in svg

odg is hardly that much of a reason - it even seems like odf is moving away from odg as much as possible

No, the canvas is part of the document and must never be themed. The canvas background is as much part of your drawing as any line you put on it.

This hasn't been sitting right with me and I finally realised why.

That statement is true when you work with a real canvas and draw/paint/whatever directly onto that. If you take a grid paper the grid will become part of your art, but does Karbon print the grid which you can have it show (except possibly via an option)?

In drawing applications, the canvas is NOT part of your art, but simulates the canvas you'll be printing on. It's a backdrop layer that sits behind/below the lowest layer you can draw on. If you plan to print on a coloured piece of paper, or one with a canvassy texture, you'll probably want to adapt your virtual canvas so you can incorporate the physical canvas properties into your design. But you don't want that virtual canvas to print as that would be a waste of toner at best...

That's not to say that the virtual canvas should not be exportable at all: you'd want to be able to include it when generating a PDF (SVG, JPG, etc) format version for use in on-screen only presentations. Of course you could just add a backdrop layer in that case.

I'm not aware that Karbon has the equivalent of a slide/page design feature where you can define how each page will look. That could look be used to be achieve what I describe here but in Karbon that layer should probably not be printed by default (just like it isn't in presentation apps, IIRC).

In D19216#421654, @rjvbb wrote:

No, the canvas is part of the document and must never be themed. The canvas background is as much part of your drawing as any line you put on it.

This hasn't been sitting right with me and I finally realised why.

That statement is true when you work with a real canvas and draw/paint/whatever directly onto that. If you take a grid paper the grid will become part of your art, but does Karbon print the grid which you can have it show (except possibly via an option)?

In drawing applications, the canvas is NOT part of your art, but simulates the canvas you'll be printing on. It's a backdrop layer that sits behind/below the lowest layer you can draw on. If you plan to print on a coloured piece of paper, or one with a canvassy texture, you'll probably want to adapt your virtual canvas so you can incorporate the physical canvas properties into your design. But you don't want that virtual canvas to print as that would be a waste of toner at best...

That is actual a valid point, although in say Krita with transparent pixels a checkerboard is shown.
That said it might make more sense for this "testing background" to be part of the document and not a general setting - if the use case is as you say then the testing background would also be different for different projects

That's not to say that the virtual canvas should not be exportable at all: you'd want to be able to include it when generating a PDF (SVG, JPG, etc) format version for use in on-screen only presentations. Of course you could just add a backdrop layer in that case.

I'm not aware that Karbon has the equivalent of a slide/page design feature where you can define how each page will look. That could look be used to be achieve what I describe here but in Karbon that layer should probably not be printed by default (just like it isn't in presentation apps, IIRC).

That is actual a valid point, although in say Krita with transparent pixels a checkerboard is shown.

Heh, I've had the opportunity to work closely with professional infographists so I picked up a thing or two about using applications like Illustrator and InDesign :)

How to indicate a transparent area of an object is yet another subject, with a related but not identical purpose.

That said it might make more sense for this "testing background" to be part of the document and not a general setting - if the use case is as you say then the testing background would also be different for different projects

True. I was reacting to *re*moving a setting completely, not to moving it to a more appropriate context.

In D19216#421689, @rjvbb wrote:

That is actual a valid point, although in say Krita with transparent pixels a checkerboard is shown.

Heh, I've had the opportunity to work closely with professional infographists so I picked up a thing or two about using applications like Illustrator and InDesign :)

How to indicate a transparent area of an object is yet another subject, with a related but not identical purpose.

That said it might make more sense for this "testing background" to be part of the document and not a general setting - if the use case is as you say then the testing background would also be different for different projects

True. I was reacting to *re*moving a setting completely, not to moving it to a more appropriate context.

Ok, after another rethink...
It starts to make sence if karbon is used not as an odg editor but as an svg editor.
Let's say you create an icon that should be shown on certain background color(s), it would be a help if you could check your design aginst those colors.
In his case you are not concerned with wysiwyg or printing as you would be with an odg document.