Release notes MR: https://invent.kde.org/websites/krita-org/-/merge_requests/80

Links need checking, yaml file needs to be updated too.

In T16862#298948, @dkazakov wrote:

A text shape can flow into multiple shapes, within SVG these are just linked, so both grouped and ungrouped is possible within SVG.

Then the design of the shapes being owned by the text shape may become a bit weird in some corner cases. E.g. we might end up with a configuration like that:

• shapeA
• groupShapeB
  • shapeC
  • shapeD
• textShapeE -> flows inside shapeA and shapeD
  
  As far as I can tell this configuration is not possible to implement within the current design.

In T16862#298100, @dkazakov wrote:

Btw, a new set of weird technical questions:

1. Can a text shape belong to multiple (ungrouped) vector shapes? Or they should always be grouped first?

I think technically speaking the clip-paths are also a situation where there might be shape-dependency, though that can be resolved quite easily. Beyond that it's stuff like patterns and markers, but there it is also a lot more self-evident that we should just resolve, as they're resources and therefore suitably contained.

Windows questions:

I don't recall QSqlQuery::prepare ever being discussed, so it's likely no one ever noticed. If you have an idea of how to cache it, give it a try?

So, std::bind is to me largely an incantation that happens within the PSD parsing code. What would we replace it with?

ok, so I'm a little too fried by text-layout to give an indepth comment, but I wanted to note that our transparency masks can handle vector shapes, because they're based on KisSelection (as are filter masks and filter layers), which can have either vector or(and?) raster based selection. Krita doesn't allow editing vector selections on transparency masks, but if you make a vector selection, then create a transparency mask, and then save and inspect the kra file, you will see that Krita will have stored an svg file for the transparency mask.

@knowzero : No clue. The problem is that we haven't had a post-5.0 meeting yet, and as far as I know only you and Alvin have read my report. I have literally no clue what is going to happen.

Ok, I've decided to write a report for everything I've learned. I hope we can use this as a basis for a proper meeting at some point:

Some updates on this:

Also the gamut mask controls are still missing, I don't really like the current way. There should be some way to choose the mask from the docker (has been requested a few times), I'm thinking of a popup/dropdown, and the angle control could be better integrated IMO.

Adding scott, as he was interested in this. Though, right now it seems like it's mostly about how to tackle the refactor.

If I am going to collect layout code links anyway:

Turns out Unicode's ICU also has a text-layout component that integrates with harfbuzz and is apparently used by firefox and libreoffice. (I might be wrong, and these two might only be using the bidi and text-segmentation components)
https://unicode-org.github.io/icu/userguide/layoutengine/paragraph.html
https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1ParagraphLayout.html

Web-platform tests for SVG:
https://github.com/web-platform-tests/wpt/tree/master/svg

https://www.w3.org/International/articles/ruby/markup
https://w3c.github.io/i18n-drafts/articles/ruby/styling.en.html

Discussion on using Harfbuzz in javascript:

Note that neither @rempt nor @dkazakov are available this week. However, given that both are a little preoccupied with getting Krita 5 ready, perhaps it would be most fruitful to currently have a discussion with artists and discuss what kind of setups and needs they have, before discussing tech...

Text layout discussion by Ralph Levien, has a lot of useful links:

Some interesting observations about unittests here.

Text rendering in Krita on a 72dpi document, with left the text shape, and right the text-shapes converted to paths.

Ah, I think what you're missing is that QRawFont can give QPainterPaths for glyphs (we use it in textOutline), and I suggest that we always go through that, and use those paths to paint with the KoShapeBackgrounds, instead of making QTextLayout do it, as that one does not know about our KoShapeBackgrounds. I also want to have it not happen in KoTextShape, because it doesn't know the fills and strokes and whatever of the textchunk. It makes more sense to me to have the textchunks, which do know this info to handle that.

resurrecting this old beast...

I think the proposed solution for handling shared tasks is probably the only real way. The gitlab equivalent is 'EPIC' issues, but those are premium only.

I'll put this on resolved for now, we can create new tasks for the rest :)

There's still quite a bit we can do, but yes, you can now browse an opds catalog and download the open-access items.

I am starting to get the feeling it's better to talk to artists about this. It's too focused on this edge case of everyone naming their unique resources with the exact same string.

Related: https://bugs.kde.org/show_bug.cgi?id=435610 , not super much though, just something to think about.

For the average user, I was thinking something like that but generating the UI widgets dynamically based on their ffmpeg capabilities. And then the advanced option can be like ffmpeg recorder.

So, we had a meeting. As far as I can tell, the following should happen:

Small update:

Concerning the opengl depth test stuff, there's some mention of it in the qt6 docs: https://doc.qt.io/qt-6/qquickgraphicsconfiguration.html
That class doesn't exist in 5, the only mention I can find is that the depth buffers got to be reset: https://doc.qt.io/qt-5/qquickwindow.html#resetOpenGLState

Going to resolve this now, considering it's merged. For a next itteration, we should just make a new task.

So, I managed to port the small color selector to qml:

Yes, but while thinking through the docker stuff, I just realized. We need ANGLE to not go nuts when handling the HDR functionality of our current canvas. I mean, that part is fragile anyway, but that was several months of work...

So... if we would want to port, then the filters, settings, new image dialog, impex-dialogs and other things we keep in separate windows can be done first, but dockers will all need to be ported in one go?

Just gonna plonk this gpl3 official qtreeview.qml here: https://code.qt.io/cgit/qt-extensions/qttreeview.git/tree/src/TreeView.qml

In T14170#251037, @lucretia wrote:

Utilising Vulkan would make for a more performant implementation as well as being able to utilise threading in the rendering, unlike OpenGL which is single threaded.

This is also starting to sound like we should just get someone to just sit down and write a test program within a week (just basically a window with the aforementioned combos of qtquickwidgets, regular widget, opengl or qrhi widgets, etc) and just see what that uses on the different platforms? I think it might prove time saving?

I've heard that Vulkan has a bit of initial setup

We seemed to have removed Karbon's gradients: https://invent.kde.org/graphics/krita/-/commit/91c359e1977a8c5ff5c6f5be1c5bd618baafc5f2

Ok, so with the stop gradients icc-color merged, and with the HDR gradients patch merged, Krita can now do StopGradients in all the colorspaces it supports, including unbounded color gradients (So rec2020 12.0, 0.5, 0.5 is now possible).

Documented KPL (which was on my todo forever as well...)

In T14093#249262, @rempt wrote:

Could we just ignore the parts of the standards with weird colorspaces and refuse to load gradients that use those?

Inkscape's way of handling lab and xyz is rather strange :/

Considering it's online, we could get a few krita users to demo krita if necessary ;) (pinging @rempt, too )

• made sure that colorspaces get converted properly
• disabled the 16bit grayscale usecase as I can't seem to get it to load
• cleanup up the importer for high bit depths.
• made sure we load alpha properly.
• did a poc of loading nclx... except libheif still doesn't hand me color profile info and no movement on that bug is done.

@shubhamx, I've already given you instructions, if you continue like this I will consider you a spammer.

Please come to the irc, Krita on freenode.

Didn't do much today, as most of my day was taken up by the multithreading seminar. I did however find that there's plenty of avif test-images on the avif repository: https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles

Keep in mind this is an open source project, you don't have to do everything at once, and you definitely don't have to do anything on your own. Start with the parts that you can figure out yourself, and if there's parts you don't understand... there's no shame in telling other people 'hey, this needs to be done by someone else'. For example, we let the people familiar with macs handle building mac deps.

Having played a bit today, it'd be great if...

• enabled avif support for the encoder/export.
• allowed for saving of grayscale 8bit images.
• allowed for saving of 16bit rgba images.
• allowed for saving the color profile.

OK, we've got...

I am not stuck, I just got too preoccupied with other Krita tasks like release notes and the like, and I take the center of the week off (because I work in the weekends).

Yeah, and I think this is a case of the file format(s) being too new (they're basically the same format with h264/5 replaced by av1). I asked what was the best practice with the NCLX profile, and the libheif maintainer was like 'well, it's not necessary', while the original ticket that requested NCLX alongside ICC for avif did so because that would improve the quality of the YCrCb conversion a lot.

Put a branch over here: https://invent.kde.org/graphics/krita/-/commits/wolthera/libheif-1-9-1-update

Because of the new system the Tool Options docker could now be changed to better reflect temporary tool invocations.
Either by stacking another set of options widgets above or below the previous tool, or by simply showing the options widgets for the active tool.

This could be a good way to also, for example, make the alternative transform tool options (so beyond the free transform) more discoverable.

Yes, I can! I will give @scottpetrovic access when he gets home from work and can log in.

I did just now :3

So, this page is, after I looked it over, basically the same as this one: https://krita.org/en/about/krita-foundation/ Only less bank info, because that is what the whole devfund thing does for us. It might be an idea to copy that page over for a start, and then to see if there's notable issues with it.

substitutes the triangle + ring from HSV

Well, the thing about using a library is that it should handle most of the color space tag stuff for us if that is what is necessary to conform to the spec. The only thing I am concerned about is whether most of the contrast in the image is in the 0-1 range (a hdr image needing a floating point space) or the contrast is all over the place (16bit integer image).

those transfer characteristics are proly part of understanding the nlcx space description, and gimp just converts those to an icc profile.