[Qgis-developer] Improving QGIS integration in cartographic workfows

[Nyall Dawson]

Hi Giovanni!

>
> As many of you will know the cartographic production workflow often requires
> post-production activities involving specific external software to refine,
> compose, prepare layouts for printing.

As you've probably guessed... this is something I'm quite passionate
about and would also like to see us improve. Like you said, we've got
really strong symbology and cartography support inside of qgis, but
not so great interoperability with programs outside of QGIS.

> I love QGIS styling capabilities, I think they're reaching production grade
> quality. I think the time is come to consider how the output could be
> enhanced to make QGIS part of a complex workflow.

One related request I frequently get is for support for CMYK workflows
within QGIS. And this is where the problem lies... we can't support
CMYK until Qt itself gains support for it. It's something we keep
bumping up against with this type of request and we're limited because
no-one on the QGIS project has links to the Qt project or can
influence their development decisions.

> Probably a more advanced PDF output would be the first step.
> One of the most important things would be the ability to export map layers
> as PDF layers/groups (tree model) to have it back when importing the PDF in
> external sw.

Unfortunately this is quite involved. At the moment QGIS is highly
tied into Qt's painter and printer framework. It's going to be very
difficult to change this and make a change like using another library
for exports. I think the most feasible approach would be to get the
changes we require implemented upstream in Qt itself. It's likely less
work, and also benefits other Qt projects too.

I'd also say that support for non-jpeg compressed images inside PDF
exports is critical. At the moment PDF is the only real choice for
export you have in QGIS (due to severe issues with SVG output (also a
Qt issue!) ) but unfortunately Qt forces jpg compressing on any
rasters included here. That's far from ideal for GIS or print
production work, and we need a way to keep these as lossless while
exporting PDFs.

> I think it is worth spending some time to investigate it and share ideas,
> and when the it will be matured maybe a funding campaign could be a way to
> give it the needed resources.
>
> What's your opinion on this topic?

We need to get alongside one of the Qt development crews (such as
KDAB) and discuss how to proceed with them. Paolo and I did this last
year to ask about CMYK support, and unfortunately they (KDAB) require
some payment up front to look into what's involved and how much it
would cost. We lost our sponsor at that stage and haven't yet been
able to pursue this any further.

I'm tempted that when the next round of QGIS grants comes up to apply
for a small grant for learning the Qt infrastructure, getting a feel
for the codebase and their contribution requirements, and getting a
patch to some upstream issue which affects us merged into Qt. I think
it's going to be critical moving forward with QGIS that we have a way
to influence and contribute to upstream so that we're no longer
restricted by limitations in the library.

Of course, there's still the issue that even if we get something fixed
upstream it could potentially be years before these fixes would be
available to QGIS end users... (hopefully snaps/flatpak/etc will help
here).

I would also strongly love to see us (QGIS users/developers) get SVG
export fixed upstream. The current state of SVG export in QGIS is
really embarrassing in my opinion :(

Nyall