namespace for Qt port?

[mpsuzuki]

I've written Qt4 port before, and now testing to use the source for Qt5 port.

Should I use different namespaces for Qt4 port and Qt5 port, like SVGNative::Qt4SvgRenderer and SVGNative::Qt5SvgRenderer? In my understanding, linking both of Qt4 and Qt5 to single library or binary is not recommended usage (I think it's almost impossible). So, even if I separate Qt4 and Qt5 into different namespaces, libSVGNativeViewer cannot be built well. There might be some plugin technique to link Qt4 only or Qt5 only in run-time. But I'm afraid it's overkilling.

I would propose SVGNative::QtSvgRenderer style naming, but if anybody prefers the versioned namespaces (even if the single version is available), please let me know.

[dirkschulze]

@mpsuzuki Are the rendering APIs in Qt4 and Qt5 incompatible? Kind of hard to imagine that they reinvented drawing :P If possible, absackt the code to be as independent of Qt versions as possible. If needed we could either create 2 separate ports or compiler flags for the differences.

[twardoch]

There is Qt's own QtSvg module (that only does SVG Tiny):

https://github.com/qt/qtsvg/tree/dev/src/svg

https://doc.qt.io/qt-5/qsvgrenderer.html

I wonder if you could create a QtNativeSvg renderer is such a way that it would be easy to adapt to those who have been been using QtSvg)

[twardoch]

Ps. Qt5 was released 2012 and a lot of code has been adapted. Qt4 is old. I think it would be best to target Qt5, and treat Qt4 as "legacy".

[mpsuzuki]

Sorry for long delayed response!

@mpsuzuki Are the rendering APIs in Qt4 and Qt5 incompatible? Kind of hard to imagine that they reinvented drawing :P If possible, absackt the code to be as independent of Qt versions as possible. If needed we could either create 2 separate ports or compiler flags for the differences.

I did small experiment to reuse my codebase for Qt4 to Qt5, and I found no significant troubles. I think there is no big change in the side of the drawing API in Qt.

However, in the development of the Qt library, the application linked to QtN shared library cannot run with Qt(N+1) shared library. The developer have to relink their applications with Qt(N+1) libraries. And, it is almost impossible to have an application linking both of QtN and Qt(N+1) libraries.

For example, Poppler PDF rendering library has always one or two Qt frontends for each Qt major versions: Qt3 frontend (deprecated, removed from latest source tree), Qt4 frontend (deprecated, removed from latest source tree) and Qt5 frontend. Can I take such strategy?

[mpsuzuki]

@twardoch, Thank you for comment!

Ps. Qt5 was released 2012 and a lot of code has been adapted. Qt4 is old. I think it would be best to target Qt5, and treat Qt4 as "legacy".

Yes, I understand. Could you expect when Qt6 would come? It would come soon? If Qt5 would be deprecated soon, I want to postpone the incorporation of Qt port into official tree.

I wonder if you could create a QtNativeSvg renderer is such a way that it would be easy to adapt to those who have been been using QtSvg)

Sorry, my main interest in SVG Native Viewer is the provision of the unified interface with multiple backends, so writing Qt-specific frontend is not in my high priority. If we can amuse QtSvg users, what would happen? I think SVG Native is yet another subset of SVG spec, so, having QtSvgNative is not so much exciting news of QtSvg users (e.g. SVG Native removes animation feature, although SVG Tiny supports it). How do you think?

[twardoch]

According to the Qt roadmap for 2020 ( https://www.qt.io/blog/2019/08/07/technical-vision-qt-6 ), Qt does plan to release Qt 6 at the end of this year or early 2021. However, they don't plan major API breaks with Qt 5. They want to remove deprecated functionality, and they focus on new hardware-backed rendering via Vulkan, and much 3D stuff. It’s most likely that they'll keep the QWidgets (C++-driven GUI app development) intact, and also the current Qt 5 QML environment (though that's a bit more in flux, it's kind of like their WPF/XAML ;) ).

But either way it goes, I think that the adoption rate of Qt6 vs. Qt5 will be small.

I understand the unified API, and you're right.

I'm personally rather interested in the Adobe SVG Native viewer that has Qt 5 support. In 2013, I pitched the idea of bringing SVG to OpenType, and was part of the initial "SVG in OpenType" W3C working group, along with Sairus, Jonathan Kew and others. I’ve been also part of the standardization efforts of both SVG and variable fonts in the OpenType spec.

My day work is at FontLab, and our FontLab 7 (previously VI) is the first GUI font editor that supports the creation of all color font formats supported by OpenType. And FontLab 7 is a QWidget, Qt5 app that ships on macOS and Windows.

Currently, we use the QPainter drawing provided by QtSvg to render the SVGs that users import into the app, and, well, the results are terrible. The SVG Tiny support in QtSvg is just very limited on top of the very limited scope of SVG Tiny.

I know that Sairus has worked on SVG Native following his work on SVG in OpenType. My understanding is that the plan is to ultimately align the custom-specified subset of SVG that is currently defined in the OpenType SVG table with SVG Native, so SVG Native actually becomes the normative profile of SVG used in OpenType+SVG fonts.

So I’d love to adopt the Adobe SVG Native viewer as the default SVG renderer for SVG glyphs inside FontLab. This would be logical, because ultimately, it would be WYSIWYG — the SVG glyphs rendered via Adobe SVG Native viewer inside FontLab would be a close approximation of what the end-users of the fonts would get in apps that use SVG Native and OpenType+SVG fonts.

So the sooner SVGNV gets a Qt5-conpatible QPainter API, the sooner people can make OpenType+SVG fonts that will actually work, and that cause more rather than less headache for all of us who have worked on bringing sensible color glyphs to typography these past six years.

Also, when you deploy your Qt5 solution, this might actually positively influence the Qt people in their decision-making regarding SVG. Perhaps they might incorporate SVGNV-based rendering of OpenType+SVG fonts, or even work on incorporating SVGNV as a replacement or alternative renderer for their QtSvg module. I think this might be a win for everyone, and I think this is more likely to happen before they actually set their Qt6 plans in stone.

(Btw, I also know that there has been some interest in using the SVG Native Viewer in FreeType for rendering SVG glyphs.)

At FontLab, we’d happily take a look at options to integrate SVGNV into our QPainter-based glyph rendering as early as possible. I can be reached at [email protected]

Many thanks for your efforts!

Best,
Adam

[twardoch]

Ps. I don't know enough to address your specific namespace question.