Ok, so I did do some small UI fixes past week, and updated the documentation.
We’re now at the end of phase 2: Rich text editing!
BEFORE WE TALK ABOUT TESTING, LET ME BE ABSOLUTELY CLEAR THAT BEFORE TESTING YOU NEED TO BACK UP YOUR RESOURCES FOLDER, IN PARTICULAR THE RESOURCE CACHE!
Now, this is a little more complex than last time. Because there’s two builds to test. The first build is the nightly. The second is the build from MR 2470. I will explain later in a bit more detail what the difference is. First, let me summarize the work that has been done during phase 2:
Phase 2 Summary
The majority of the Phase 2 work was getting everything in the new Text Properties Docker to work. This is a separate docker from the text tool, because you can also edit texts with the shape selection tool. The buttons in the text tool options will not do anything when editing text, they are, as their description says, for creating new texts only. I will overhaul the text tool options at a later date to make this clearer.
(Similarly, if you have made texts previously with the rich text editor, using Krita 5.2 or older, the editing will not work as expected. There’s an MR with converter functions for these waiting, but it got stuck on UI disagreements)
The text properties use CSS, and thus, CSS inheritance. This means that you can set a property on the paragraph, and any styled text within that paragraph will inherit those values unless they are explicitly overridden. This is a feature I am required to support as a number of SVG/CSS features (notably, relative font units) require inheritance to function correctly.
The shape selection tool will only edit paragraph properties, the text tool can edit both. When properties are set on the current selection, the revert buttons becomes enabled, and will show multiple arrows when the property is mixed over the selection. The revert buttons are organized so you can easily see which properties are being set.
Currently the text properties docker will only show properties that are set or inherited, with the exception of Font Size, Font Family, Font Style and Text Align. You can add properties with the “add property” drop down at the bottom. From early feedback it became clear that list of mentioned properties should be visible by default, as well that some people wanted to always see all properties. To that end, you can configure property visibility with the configure button next to the add property button. You can set the default behaviour to “Always Show” if you prefer all properties to be shown, and configure in detail when which property shows. This is all because the text properties docker has a lot of properties, and this should keep things focused and easy to experiment with.
Finally, there’s style presets. These allow you to store your favourite styles, and eventually I want to make it possible to create texts on basis of a preset. You can create a style preset based on current settings, and double click existing presets to apply its settings over the current settings.
The build differences
As said before there’s two builds to test. The nightlies and MR 2470. The difference in these two is how the split between paragraph and character is handled, and how you set either. (Some small fixes were done today (12th sept), so it might be good to wait a little till the nightlies for those are done.
Krita Next
- Shape Select Tool edits paragraph properties on all selected text shapes.
- Text tool edits paragraph properties when there’s no selection.
- Text tool edits character properties when there is a selection.
- The Direction property is disabled in the character properties when there’s no selection and invertedly enabled in the paragraph properties.
- Upsides:
- There’s only one set of widgets, in theory, which makes style presets a little more straightforward.
- Downsides:
- I really don’t like how we’re handling direction.
- It is very different from how, say, LibreOffice handles text properties.
MR 2470
The main difference here is that paragraph properties will show all properties for the paragraph (including fontsize, etc), while character will only show properties on the character.
- Shape Select Tool edits paragraph properties on all selected text shapes. Character properties are disabled.
- Text tool can edit either depending on which tab you’re in. If there’s no selection, the character properties will be edited on a word, similar to LibreOffice.
- When setting the fill and stroke color with any of the color selectors, no selection means setting it on the paragraph, while any selection sets it on that selection.
- Style presets will be set on the character when there’s a selection only, on the paragraph otherwise.
- Upsides:
- It should be clearer now how the inheritance thing works.
- Direction property is less convoluted.
- It is nicer for style presets to be able to combine, say, an alignment, font size, render settings and indentation into one preset.
- Downsides:
- The character properties are disabled when shape selection tool is used. This might be very unclear, and I worry it is going to cause frustration.
- Similarly, there’s no way for us to magically determine whether paragraph or character tab should be visible. Should we have some kind of auto switch here when there’s a selection, or just leave it alone?
Documentation
I have updated docs here: text tool, text properties docker, font families resource, style presets.
I also did, over the past year, write introduction posts about a given set of features:
What I need to know
You can comment on anything in the builds, but if you need a little bit more focus, here’s a list of things I’m looking for answers to:
- Which of the two builds do you prefer?
- What should be done when all text is selected with the text tool? Right now it just tries to select the lowest nodes and edit those, but that can have different meanings depending on the text. Should it keep this behaviour? Should it only edit paragraph properties are remove any overridden properties in the selection?
- Should we have any default style presets? If so, what kind?
- Style Preset right now adds its properties on top of existing properties. Should it wholesale replace existing properties? Or should there be a special button for that?
- The order of the properties is currently hard-coded, and was initially vaguely based on preference, but now got muddled up. What order should the properties be in, or rather, which properties do you want to always see at the top?
While you guys test, I will try to work on Text-in-Shape UX. Similarly, once we’re done with the testing phase I will enabled translation string retrieval for QML. I’d been avoiding it to ensure that the translators wouldn’t be translating on shifting sands too much.
As noted previously, we can load all fancy features, but we cannot save all of them (only simple text saving is possible), because PSD requires a certain kind of positioning data before it accepts the advanced text data, and I need to sit down and figure out what exact positioning data it needs. Similarly, Krita and PS have fundamentally different text layouts, so I also cannot guarantee text being 100% the same. Krita will ask if you want to load text as a text object or as a paintlayer for this precise reason.