Krita To Kickstart New Text And Vector Tools

Alexandre Prokoudine 10. May, 2016
13 Comments

Krita Foundation announced their third Kickstarter project to fund development of new text and vector tools. With the proposed features, the team aims to improve the user experience for, among others, comic book and webcomic artists.

Essentially, the team will ditch the Text tool inherited from Calligra Suite and create an easier-to-use UI for managing text and its styling, improve RTL and complex scripts support (think CJK, Devanagari), add text on path editing, non-destructive bending and distortion of text items etc.

Additionally, they will completely switch to SVG as an internal storage format for vector graphics and improve usability of related editing tools.

There are also 24 stretch goals: from composition guides to reference image docker improvements to LUT baking. In all likeliness we are going to see at least some of the stretch goals done: it was the case for both past Kickstarter campaigns, and after the first two days this new campaign is already ca. 30% funded.

As usual, LGW asked project leader Boudewijn Rempt some technical questions about the development plans within the campaign.

Given the focus on text and vector tools, how many bits of Calligra Suite does Krita still share with the original project?

There is nothing shared anymore: the libraries that we used to share have been forked, so Calligra and Krita have separate and, by now, very different versions of those libraries. That was a really tough decision, but in the end we all realized that office and art applications are just too different.

So, we'll probably drop all the OpenDocument loading and saving code in favor of SVG, with just an OpenDocument to SVG converter for compatibility with old KRA files.

We'll implement a completely new text tool and drop the old text tools and its libraries. As for the vector tools, we'll keep most of that code, since it is already half-ported to SVG, but we'll rework the tools to work better in the context of Krita.

For import/export, only SVG. And the functionality we want to implement first is what's really important for artists: it must support the main thing, the raster art. So, things like vector based speech balloons for comics, or decorative borders for trading cards or some kinds of effects. Boolean ops on paths are really import for comic book frames, for instance.

Regarding text direction flow and OpenType features: how much do Qt and Harfbuzz provide for Krita already, and how much (and what exactly) do you need to write from scratch?

Qt's text layout is a bit limited, it doesn't do top-to-bottom for Japanese, for instance. So likely we'll have to write our own layout engine, but we'll be using harfbuzz for the glyph shaper.

Do you think it's faster/easier to write and maintain your own engine than to patch Qt?

Well, they serve different purposes: Qt's layout engine is general purpose and mostly meant for things like the text editor widget or QML labels. We want things like automatic semi-random font substitution that places glyps from different fonts so we can have a better imitation of hand-lettered text, for instance. How far we'll be able to this is a bit of an adventure!

Some specifics of the proposed implementation make it look like you would slightly extend SVG. Is that correct?

Well, first we'll look at what SVG2 proposes and see if that's enough, then we'll check what Inkscape is doing, and if we still need more flexibility, we'll start working on extending SVG with our own namespace.

For vectors, I don't think that will be necessary, but it might be necessary for text. If the kickstarter gets funded, I suspect I'll be mailing Tavmjong Bah a lot!

Stretch goals cover all aspects of Krita: composition, game art, deep painting, general workflow improvements. How did you compile the list?

This January, we had a sprint in Deventer with some developers and some artists (Dmitry, me, beelzy, wolthera), where we went through all the wish bugs and feature requests and classified them. That gave us a big list of wishes of stretch goal size. Then later on, Timothée, Wolthera, Irina, and me sat down and compiled a list that felt balanced: some things that almost made it last years, some new things, bigger things, smaller things, something for every user.

One of the stretch goals is audio import for animation sequences. How far are you willing to go there? Just the basics, or do you see things like lipsync happen in the future?

Just the basics: we discussed this with the animators in our community, and lipsyncing just isn't that much of a priority for them. It's more having the music and the movement next to each other.

But that suggests multiple audio objects on the timeline, or would it be just a single track preprocessed in something like Ardour?

Im sorry if my choice of words was harsh (english is not my native language).

I feel it stagnated for my professional needs (graphic designer in press environment). The roadmap states that an improved CMYK support is planed for 0.94.

Since the release of the current stable version (0.91) 14 months have passed without 0.92 comming, so I can expect 0.94 (and CMYK) to come in around 3 years (could be more).

I like Inkscape, and I will love to be able to do my real life work with it, but sadly I cant without proper press workflow (CMYK PDFs, Bleed, Crop marks, Spot inks, etc). Not all designers work for web (fortunately).

For this reason Im looking for alternatives on linux, but there is a lack of choices in this kind of software. My only hope is SK1, but it far from complete.

For now Inkscape has some extensions to draw crop marks (and bleed marks), and you can convert your RGB PDF in CMYK PDF with gostscript (command line, but you just have to use a script).
Otherwise you can draw in Inkscape, and do the layout in Scribus.

Im aware of the available workarounds, I have been strugling with this for years.

Sadly none of those workarounds are productive, conversion from RGB to CMYK (using Ghostscript) can be very unreliable and can lead to unexpected results (rich blacks vs 100k, Spot colors, etc) there is no detailed control over the conversión.

Regarding Scribus as a step from Inkscape to the press, there are some special issues, Scribus SVG support is not compatible with Inkscape ones (even art size is different!), which makes you rasterize and convert many thing in your artwork before being able to use it in Scribus.

Yes, with a lot of patience you could work like that, but is not productive.

I also miss the CMYK in opensource tools. For a long time I used Inkscape, Gimp / Krita and Scribus to finalize arts for printing. But really the line of work just getting too long.

I created it in Inkscape, rasterizava the most complex parts and left some in vector (which depended on accurate CMYK colors). After opening the rasterized part in Krita and converted to CMYK. SVG matter for Scribus and was replacing the original image with the converted. Interestingly, Scribus already imported SVG with CMYK values, but remember that some were not accurate and had to be fixed.

It would be great if we could create and close the file in the same software. SK1 is following this path, but is not yet so advanced. It would also have to wonder if the issue in Inkscape is the software or SVG format, but that part I do not quite understand.

However, Krita is a software that must be respected and that I use to this day.