TextLayout


#1

This has been discussed before but thought I would bring it up again. Is there a TextLayout editor available? You know, just the standard text box that allows different font, size, style, etc for any of the words or characters in the text box. Also the text box can be resized and have the text flow within the box.


#2

TextEditor?


#3

I know about TextEditor but I am not seeing how to use it with TextLayout or Attributed Strings. For example, how do I select the second word in a sentence and make that word bold? Or how to use Attributed Strings in the editor.


#4

A TextEditor using TextLayout and the liking does not yet exist, at least not in the JUCE library.


#5

Sadly no. At some point I hope I can get around to writing a TextLayoutEditor which supports bi-directional text editing, attributed strings and even TheVinn’s oft requested center justified text. It is the final missing piece in JUCE’s internationalization support (for Windows and OS X that is).


#6

That is bad news, because I need it badly, ASAP. I may try to do a simple editor. All I need is to have a text box that can be sized, has text justification (for all text in box) and the ability to select characters and apply font attributes. Any ideas?


#7

Considering that juce::TextEditor is hands down the most complicated widget in the JUCE toolbox, I’d say that there is absolutely NOTHING simple about a text editor with justification and style runs.


#8

Yes and it’s a shame that Juce doesn’t have a very necessary component for REAL applications. All these experts agree Juce should have it be there but no one brave enough to do it, so I have no other choice.


#9

You said it. After I finished the TextLayout stuff I started to spec out a TextLayoutEditor and the complexity is staggering.
Random inserts, random deletes, carets, arrow keys, selection keys, mouse selection, and on and on.
It leaves me in awe of what Jules achieved with TextEditor.

Well I’d like to do it but unfortunately writing a TextLayoutEditor won’t pay the bills so it will have to wait until I have a lot of free time.

All the cursor stuff has to be done directly in DirectWrite and CoreText because that is where all the glyph metrics are stored which are needed to move the cursor properly. Both APIs were designed for text rendering and not text editing. Every change you make to the text you will have to pass in as a new string to these APIs to redo the layout. This should be ok for short text but it will probably become nasty for random inserts and delete in large blocks of text. One optimization is to put every paragraph into its own string that way you can cache all the paragraphs and only be updating the one paragraph you are actually working on. Editing the strings themselves will require some sort of specialized data structure like a gap buffer (emacs) or a piece table (AbiWord).

Now I remember why this was giving me nightmares.


#10

Rope (data structure)

Ropes: an Alternative to Strings (PDF)


#11

I should probably clarify that I meant this as a string rendering optimization, not a string editing optimization. Caching the output from Directwrite/CoreText will definitely help improve rendering performance. In terms of optimizing string editing you should be using a good data structure like TheVinn or I mentioned.

That reminds me of another reason why to split the paragraphs (for rendering). DirectWrite will only allow you to set the justification for the entire string you are sending in, not just specific parts. So if you want one left aligned paragraph and then one right aligned paragraph you have to send them as two separate strings. CoreText on the other hand lets you set the justification on parts of string so you could just send it a single string with paragraph attributes. To make it work cross platform you would need to do it the DirectWrite way for both.


#12

I hacked the Juce code and now have a limited TextEditor that allows selected characters/words to have their font changed and I can save and restore the contents. If someone, preferably the Juce crew could implement Justification of the text (all of the would be OK), we would have a better TextEditor.

Jules, the simple functions would be very useful for users. They are all based on your UniformTextSection.

int TextEditor::getNumSections();

void TextEditor::getSectionInfo( int index, int &start, int &numChars, Font &font, Colour &colour );

void TextEditor::setSectionInfo( int index, Font font, Colour colour );

void TextEditor::getSelectedTextInfo( Font &font, Colour &colour );

void TextEditor::setSelectedTextInfo( Font font, Colour colour );

Adding these routines allows the TextEditor contents to be saved and restored later on.

Current method do TextEditor::setSelectedTextInfo( Font font, Colour colour ) and this work fine.

  1. Select desired characters.
  2. Get the selected range.
  3. Copy the selected characters.
  4. Delete them.
  5. Set text for newly inserted text.
  6. Insert copied characters/paste.

You now have a simple TextEditor. All that is needed is Justification. Given some time I could also do that but you would do a much better job.

Please add Justification to TextEditor. This has been requested for many years and your response was, I’ll wait until I rewrite the whole thing. You’re very busy now, so I don’t think this is going to happen anytime soon, so adding Justification and these routines solves most of the problems.


#13

Sorry digging this topic up, but I need a JUCE::RichTextEditor eagerly.

Anything new about this? Or someone could pointed me how to implement it? I just need font size and color for some specified text, also justification.

I’ll pay for it if someone is willing to write this class. Please contact me.

Thanks!