Ho! I did not expect you’d try to build the branch! (We now have gitlab building appimages, so technically you can actually try to select the ‘linux build’ in the build artifacts after ‘merge request pipeline succeeded’, though it can be slow to download due lack of fancy mirror-network)
After all those are merged, plus two other ones I still need to finish, I’d like to do a user-testing cycle to get out the main papercuts.
In the meantime, there were some misunderstandings surrounding the text-on-path and text-in-shape features, so we’re going to discuss how to handle those (the text shape can handle them, we’re just not sure how to go about editing them) after the 5.2 release. There was also some profiling done today, and we have identified some places where the rendering of the text could be faster, but I’m not sure yet when we’ll tackle that.
Just a note on hyphenation: I agree that it should be a very low priority. I guess the main text use case in Krita is shorter passages of text (Comic speech bubbles, graphics heavy posters) where it isn’t a lot of work to hyphenate manually. (As opposed to longer texts like newspaper articles or even whole books, where indeed manually hyphenating is extremely cumbersome and error-prone.)
But just in case anyone wants to look into it, I’d suggest looking at how TeX/LaTeX does it. For anyone not familiar, TeX/LaTeX is an open source typesetter where you write your content in a basic markup language and it gets turned it into very beautifully typeset PDFs. But even TeX, being as popular and stable as it is, is not 100% accurate with hyphening, so it has ways for the user to aid hyphenation if needed by adding specific markups for “you may hyphenate here” or “never insert line break here” etc. Similar to the HTML entities ­ and  .
So, I was actually planning to eventually use hyphen for this, as that’s based on TeX’s algorithm and also kinda what basically all open source software uses, so there’s plenty of dictionaries for it. The bigger problem is that I need to implement stuff in the itemizer (raqm), because hyphenation can lead to morphological changes in the text (basically, for some languages the spelling of the word changes when it is hyphenated), not to mention it is possible it splits up ligatures, on top of that, the morphological changes can change the character count which is also something that I need to keep on top of to ensure editing doesn’t get weird.
In the meantime, I’m still waiting for 5.2 to release, and kinda hit a point where I can’t really work on new stuff for the text tool, so I went back to poke at my PSD text-and-vector branch, and worked on that until I also hit the point I couldn’t continue without help, so hopefully the 5.2 release will go smoothly…
Ok, for the PSD text/shapes loading code I’ve gotten to the point I’m quite sure about the transforms and the like, I even managed to load old PSDs that I made in 2006-2010, and even though the font is missing (as PSD doesn’t embed these), the positioning is scarily accurate. However, my past self never really made use of any advanced features, so I need some help finding how these features are stored.
Now, PSD is an ancient format, so it has a gazillion different ways to store something. Most data is stored in binary, with some of it stored in action script language (ASL) dictionaries. However, most of the text formatting data is stored in carousel object structure (COS) dictionaries, and these are saved to PSD as plain text. What that means is that you can literally open up a PSD in a code text editor to read the markup (Just do a search for “/Editor” to find the main text string, the markup is underneath that). So if you’re adventurous you can try to find some of the info I need in this way, but I’m happy with test-files too
That said, what I am looking for…
A test file with text-on-path and text-in-shape. I know how to load point-texts (preformatted) and paragraph-texts (simple wrapped shapes), and I know where to find the associated path of a shape, but I don’t know how PSD differentiates between text-on-path and text-in-shape. (EDIT: Rakurri shared some)
A test file with vertical text. I think I know where this is stored in the ASL, but I’d like to confirm I’m correct. (EDIT: Rakurri shared some)
A test file with RTL enabled on the paragraph, I have no clue how this is stored.
I don’t need warps, because I know the values, though I kinda have no clue how to support them. As in, I’m just simply not good enough with bezier curves or transforms to know how to warp them… (EDIT: Rakurri shared some)
Open Type Features, I have found the key for ligatures and alternate/discretionary ligatures (/Ligature and /DLigature respectively) as well as the toggle for small-caps (/FontCaps), but I can’t find the keys for the others. They are in the second text dict.
Language specific features, these I am having a hard time finding because they’re pretty hidden in PS (so it is rare to find PSDs using them). I am looking for the keys for…
kinsoku (I know which value is hard and soft, but not the key when applied)
“Standard Vertical Roman Alignment”
I think I know the key for Mojisoroe (/StyleRunAlignment), but I am unsure which number matches to which baseline option
a test file with tate-chu-yoko
vertical underline position (/YUnderline, but which number is left and which is right?)
I’m trying to figure out leading-type.
I’m also open to the middle-eastern features, though my understanding is that most of them don’t have a CSS equivelant and some of them are just plain useless.
EDIT: I’m going to parse the second text-dict first.
(Hyphenation) language, this is stored as a number, of which en-US is 14. I think I may know what the other values are, but I need at the least a few more samples to be sure.
Colors, all of the test files I’ve found have the colors in RGB, which is internally written as a dict with type 1 and a list of values in ARGB order. This is odd, because in all other cases PSD stores the color model RGB as type ‘0’, (1 being ‘HSB’). So my question is, can PSD at all store things like LAB or CMYK colors on text, and if so, what type is it stored as?
if you’d like me to implement load/save for live path data for vector shapes, I need a test file with all the possible live path shapes (that is, a rectangle, polygon, etc, not every possible combo). I only have a sample file with ellipses right now.
Thanks! That was really useful, as it pointed out to me there’s a complete separate text layer dictionary, which has each key as a number. Thankfully they’re mostly duplicate, so I’m going to check what I can do to pull info out of that second dictionary
EDIT: Looks like some of my really old files actually do have the keys in this… Though, I will look at this tomorrow
I had to refine the COS parser for this, and then write something that would translate the keys if they were in number form instead of a nice name. I still need to write the opposite direction (saving, that is), though that’s a little scary when I have no PS to test against, but I’ll try my best.
In common Photoshop fashion, the official Photoshop User Diagnostic plugin I installed either errored itself or didn’t give much information. The error message it throws doesn’t tell me whether it is a recreation of the error of the file crash or an error message for the tool.
This is what it gave me:
"
Photoshop Error information
Code: -1
Text: because of a program error
Message: Could not complete your request because of a program error.
Stack:
"
The bad news is that I can’t seem to figure out how to store the second text dictionary into PSD, while I can store the first text-dictionary. The likely culprit is that this second dictionary contains data of each individual position of each character, as well as the shaped glyph and a whole bunch more, and right now I cannot funnel that information from Krita into the PSD. In effect this means that Krita won’t be able to store opentype features and text-paths until I figure that out.
Now that’s out of the way, we have more good news than bad news:
The first bit of good news is that I’ve more or less figured out everything I was still looking for, including stuff like different color fills, various vertical text properties, language and more vector related stuff. So even though Krita cannot save everything, it can more or less load everything in terms of PSD text.
The second bit of good news is that the text-cursor branch got merged, so 5.3 will definitely have on-canvas text! Three of my side branches also got merged, which were about selecting text with the mouse pointer, implementing ctrl+a for all of the vector tools including text and also a branch that basically ensures that we’re using the default keyboard shortcuts for basic text operation on all platforms (For example, on Linux and Windows the default shortcut for moving to the end of the word is ctrl+arrow, but on MacOS it’s alt+arrow, so this branch takes care of that).
I’m going to finish up my work on the PSD branch coming week, and after that I’m going back into the fray for the text tool, hopefully I can get to a point we can do a papercut testing round soon
I just go the current nightly build. One thing I noticed that while I’m in text edit mode, I can’t zoom or rotate with Ctrl+Drag/Shift+Drag. Other tools I could think of that are in some form of editing mode (transform, polygon selection, adding a multi-step assistant) let you do that.
I understand it’s probably tricky since Shift and Ctrl are needed for text input as well, but if it could be make to work, that would be amazing.
Anyway, it’s great to see the new on canvas editing in action!
Hurm, middle mouseclick+shift should work we only check against keyboard only inputs, but checking that deeper it looks like for some mysterious reason we don’t get a middle-mouse press for shift+middle click. I will need to get someone who actually understands the shortcut matcher to help there.
The double-click/triple-click to select a word/line only works with a mouse/trackpad for me, not a stylus. My guess would be because I can never quite hold the stylus perfectly still so the clicks register at slightly different positions.
Trying to enter line breaks (by hitting enter) doesn’t seem to do anything in the on-canvas editor, but going to the “classic” text editor reveals that they are there, and just hittings “Save” there updates the on-canvas editor with the proper line breaks.
The line-breaks thing, is to my best guess because you’re trying to edit old text. Basically, it is caused by the white-space rule being set to ‘white-space:normal’, while to keep line breaks, you’ll need ‘white-space: pre-wrap’. New texts are using pre-wrap, and I haven’t decided yet what to do with old texts (We can convert them eventually, but it is not always something you’d want to convert).
As for the double-click thing: That’s been a problem in Krita since I’ve started using it, and one of the reasons why we shifted away from double and triple click where possible, at the same time, it is also the way how every other text editor works. I’m not sure I can do anything about it (the reason other text-editors don’t have this problem with a tablet is because they treat stylus input like a mouse, which Krita can’t do for the typical reasons).
EDIT: I forgot, small update: I’m currently working on the input methods. It’s been very interesting to see how different operating systems handle input and how Qt in turn handles it. We’ve got the underlines handled mostly correct right now, and currently I’m trying to figure out how to stop the suggestion window for CJK to overlap the edited text while it is vertical. After that I’ll need to ensure that the selection handles on android transform along when zooming.
Input Method support got merged, we eventually couldn’t figure out how to prevent it from displaying the suggestions window over the text when in vertical, which is a bit of a pity, and there’s still a whole bunch of platform-specific stuff that I’m unsure of how we’re going to tackle that.
I managed to get cross-layer text shape selection to work and it got merged! This means you can click any text on any editable layer to begin editing them.
I also managed to get the SVG paint order property to work and this too got merged. While you could achieve something similar with the layer styles already, this has the benefit of being compatible with eventually being able to set the stroke color on given spans of text (as well as inkscape compatibility).
I’m currently working on the text-creation / inline-size editing improvements. I’ll also be working on making the blinking cursor/caret a bit nicer, and in between that there’s a number of smaller fixes I need to tackle too.
Alright, my cursor changes and inline size changes have been merged, which means we can start testing!
All the changes are in the nightly, so to get yourself a copy of Krita that can edit text, go to krita.org, and get the Krita: Next build for your operating system. I’ve already made some basic changes to the text tool docs, which you can read here, but you can, of course, just jump right in.
Some notes:
Again, this is only plain text editing, inserting text, deleting text, selecting text all works, but no changing font size, weight or underlines yet. Such rich text editing is in the cards too, but for now I’ve focused on getting the on canvas text editing just right, which, as I’ve been working on this over a month, was very necessary.
You can create simple pre-formatted text and wrapped text by clicking and dragging respectively. You can also set the writing mode to vertical or right to left with the new toggles in the text tool options. Creating a text-in-shape or text-on-path is however not possible yet, as I’ve not had the chance to discuss how to handle that properly with the other devs.
Input methods work, however, there’s various bugs on various platforms. For one, Qt doesn’t always interpret the input from Japanese IME as containing several segments. The longpress on MacOS doesn’t work. On Linux, Ibus-Mosc is known to crash (ibus anthy is fine and we have switched the fcitx plugin so the decorations aren’t weird anymore). And we haven’t found a way to prevent the suggestions from overlapping the edited text when the text is in vertical. Finally, the virtual keyboard on windows seems to act weird, and I won’t know why until I have a windows dev machine available for debugging.
You will need to create new texts, as the SVG 1.1 texts of previous Krita need some conversion before being ready to be edited. I won’t be able to make any such converters until rich text editing is complete, as I need to be able to change a ton of properties.
Text made in Inkscape is somewhat in need of this too, because for some reason the Inkscape devs defaulted saving text with a property that says ‘don’t wrap please’, I reported this to them, and it seems like it will be fixed in the next version.
Overal, what I’d like to know from you:
How does text creation feel?
We tried to play with using pressure to make sure that if you accidentally touched the tablet you wouldn’t create a text but then reverted it. Do you think it is necessary?
How does text editing feel? Do the cursor icons make sense to you?
We’ve implemented snapping for both text creation, moving and inline-size editing. How does the snapping feel?
Now, this is is a bit technical, but how do you feel about the little round dot?
It represents the text origin point. We were unsure whether it should be this or the initial text position. both have their values, in particular when moving the text around, as right now its where it snaps to.
In Krita, the initial text position of a text is always at its origin point, so you wouldn’t be able to tell the difference, but for example, Inkscape will always offset the text from its origin point, and if you open texts made with inkscape, you will see that their text has the little dot offset.
So… Should the little dot be the initial text position? The origin point? Should it exist at all? And where would you like to snap text to?
While you guys test, I kind of hope to finally discuss the technical bits of the text shape with one of the other devs and generally discuss how to proceed with the text shape so I can work on rich text editing after this.
Feel free to ask any other text related questions too
