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 _______________________________________________ Qgis-developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
