For the most part these improvements and enhancements were funded from exceptional sales of DTRichTextEditor as well as several sponsors who stepped forward to allow me to finally get support for lists implemented.

From what I can tell the clients who licensed the editor are way more willing to contribute funds to something they have already paid for, than for enhancing the – otherwise free with attribution – DTCoreText.

Here are the collected release notes:

DTRichTextEditor 1.5

• ADDED: Implemented Support for Ordered and Unordered Lists, editable 1 level
• CHANGED: Improved handling of nested lists
• ADDED: Method to set text color for range
• ADDED: Method to set strikethrough style for range
• ADDED: HTMLStringWithOptions methods
• ADDED: Ability to animate between input views (custom keyboards)
• FIXED: style information would not obey custom CSS stylesheet in textDefaults
• CHANGED: editing delegate now uses editorView:shouldChangeTextInRange:replacementText: for image pasting
• ADDED: [DEMO] Formatting View Controller, shown as popover on iPad and input view on iPhone

Online Documentation

DTCoreText 1.5

• ADDED: Methods for getting glyph path for glyph runs and lines
• CHANGED: DTTextAttachment is now a class cluster
• ADDED: Custom text attachments can now opt to participate in inline drawing and/or HTML output
• FIXED: Loading of font table made asynchronously
• FIXED: Fonts that have a synthetic slant matrix cause text to disappear
• FIXED: Shadow:none causes text to disappear
• FIXED: CSS Attributes were not case-sensitive
• FIXED: Issue with setting color of HR
• FIXED: Problems with nested list parsing and DTHTMLWriter output
• FIXED: HTTPS URLS in web video view where treated as external URLs
• FIXED: Bug where text attributes would “bleed” into the paragraph break

Online Documentation

DTLoupe 1.5

• ADDED: sanity check to avoid rare NAN crash

Online Documentation

There is also now a Programming Guide for DTRichTextEditor where I’m collecting guides how to implement frequently asked about things.

I especially would like to thank Lee Hericks for his work on the backend and help with polishing, as well as Daniel Phillips who helped implement the format picker in the Editor demo. Here’s a screenshot.

Of course work has already begun on the next version. If you need something specific implemented please get in touch.

I’ve begun to aggregate issues on both GitHub and our own private GitLab instance via milestones. These are the grouping unit collecting issues so that you can tell from which version onward these fixes or enhancements are available. Each milestone will become a tag, once it is completed and will represent a stable version.

You can always get a picture of the original issues if you filter them by milestone, like in this GitHub issue list for version 1.4.0 of DTCoreText

DTCoreText 1.4 Changes

• ADDED: Support for including local CSS style sheet files
• ADDED: DTHTMLWriter can now write HTML fragments with inline styles
• CHANGED: Changed the way color-changing hyperlinks are drawn, code now unified in DTCoreTextLayoutFrame
• CHANGED: You no longer need an override plist, all available system fonts now get loaded into the override table automatically
• CHANGED: renamed the define for showing performance measurement so that they don’t show in normal DEBUG mode
• CHANGED: strike-through and underline is now properly positioned and sized
• FIXED: Dictation Placeholder not displayed if no text delegate set
• FIXED: Line truncation problem going for longer than the paragraph
• FIXED: RTL justified text too short to be justified would be left-aligned instead of being right-aligned
• FIXED: Problem parsing CSS styles containing a !important tag
• FIXED: Using Chinese characters would cause height problems in hyperlinks
• FIXED: Having text with a shadow would cause bolder text due to it being drawn twice
• FIXED: Images don’t keep aspect ratio on resize
• FIXED: Element hyperlink URL did not get copied to DTTextAttachment
• FIXED: code removed by accident would cause problem with custom views for links
• FIXED: HTML encoding for Emoji Characters
• FIXED: Static Framework was not linking in code from DTFoundation
• FIXED: Static Framework building was missing embedded DTHTMLParser

The changes to how hyperlinks are drawn are breaking the API since before the color changing of hyperlinks that are touched was done inside DTLinkButton. But it was next to impossible to have these line up perfectly with the text. Now there is a mode on drawing (via bit mask) that allows you to draw a frame either with normal or highlighted hyperlinks.

The second big noticeable improvement relates to underlining. UIWebViews only do a nasty 1 px underline regardless of font size. The new method gets the line thickness and position from the CTFont. This causes underlines to look like in Pages. Also a great deal of effort was spent on having the lines always perfect pixel aligned, even on Retina displays.

DTRichTextEditor 1.4 Changes

• ADDED: A delegation protocol that gives it feature parity with UITextView.
• FIXED: override typing attributes (like setting bold with no selection) would be reset on a new line
• FIXED: Autocorrection was broken due to removal of input delegate notification
• UPDATED: DTCoreText to 1.4

At the time of this writing this version was not finalized and bug fixing still underway. But those are just finishing touches.

The other big and important improvement is that now the code lives on a GitLab server instead of Subversion. This unifies our workflow tremendously since we no longer have to keep copies of sub-projects inside the SVN repo. Instead everything is included as git submodules. Those are always pointing to an exact commit in the submodule. This way we have control over which version of the submodule we want to use and can advance the pointer if there is a new release without having to keep updating a full copy of the source code.

The other big advantage for all our clients comes from everybody having their own git user accounts. This way you can easily contribute enhancements in a project branch and create a merge request for them to be included in the master branch. Previously on Subversion I only had a single read-only user for everybody.

I am hoping that the new structure and the help of fabulous GitLab will enable a new form of social coding that we see as standard on GitHub. And that seeing other users helping out and squashing bugs will inspire a greater belief in the quality of this component as well as inspire contributing for the greater good.

The next version will finally implement proper list support. Two people have stepped forward to fund the development of this feature. This is a somewhat involved thing since we need to implement ability to protect certain parts of the text. You don’t want the user to be able to remove individual characters of a list item prefix. This can also benefit people who want to treat hyperlinks as a single unit.

I admit, that for the first few tags/versions of DTCoreText I didn’t take CocoaPods seriously. But since I got down how to work with sub-modules and sub-specs I find that it gives me a great deal of pleasure to keep my specs current.

As your software matures people want to use a stable version of your library. That’s what versioning is for. From now on, any new features will increase the minor version digit. Fixes and improvements of existing functionality will increase the third digit.

Changes

• ADDED: truncation support to DTCoreTextLayoutFrame
• ADDED: DTAttributedLabel which can be used as a UILabel replacement
• FIXED: GCD ARC errors and warnings with iOS 6 deployment target
• CHANGED: DTAttributedTextView now uses the underlying UIScrollView contentInset
• CHANGED: Improvements on DTAttributedTextView to prevent unnecessary re-layouting

Many thanks go especially to bkennyatmeetme who contributed the first 2 items.

The new version is on CocoaPods and you should get it by pod update. We are thankful for any kind of support that you are willing to offer for our fun project here.

You can use DTCoreText in your apps for free if you attribute it to Cocoanetics, or you can purchase a Non-Attribution License for 75 Euros in our Parts Store. This is basically the DTCoreText improvement fund, but you get an invoice for your contribution that you can use in your company.

We are also looking for sponsors for larger endeavors like for example implementing support for <table> tags or further improve CSS support. Don’t hesitate to get in touch.

There are many wide-reaching changes to warrant an increase in version number on the second digit. I need to sum them up in this location because you might have projects that rely on DTCoreText for displaying attributed strings.

Version 1.1. marks the second major improvement related to parsing HTML. The first step was to replace NSScanner with libxml2. The approach there was to keep track of a sort of DOM fragment comprised of DTHTMLElements. The actual text would be tracked separately and at certain locations the current text would be put into the current element and appended to the building string.

The problem with the previous approach was that it caused the code to be extremely convoluted because I needed to keep track of a multitude of parameters: whether the previous string had whitespace at the end, whether the next string fragment would require a newline before being flushed because it belonged to a block-level element and much more.

DOM-inating

The new parsing approach greatly simplifies the code inside DTHTMLAttributedStringBuilder, both in the DTHTMLParser delegate callbacks as well as the blocks to be executed for beginning and ending of tags. DTHTMLElement is now itself a subclass of DTHTMLParserNode. This represents a node in the parse tree which a name, attributes and child nodes.

Because this approach constructs an actual Document Object Model (DOM) of the HTML document you can output a HTML-like structure similar to how Safari shows the structure of an inspected document.

This output works because DTHTMLParserNode provides a debugDescription method which constructs this properly indented display.

The default mode of DTHTMLAttributedStringBuilder is to discard child nodes that it does not need any more, but you can have the structure be preserved and output it at any stage during or after the build process. The _rootNode IVAR points to the root node of the document, the _bodyElement points to the tag representing the <body> tag.

libxml2 always adds a body tag even if the parsed HTML did not have one. It does an exceptionally good job in making the HTML well-formed. Must be from its XML parsing heritage.

Class-Cluster Polymorphism

This new approach to a DOM tree allowed me to remove all these crufty state IVARs and a few specialized methods from the begin and end tag handlers. Those are blocks that get called after a new node is opened or closed by libxml2.

Instead there are now multiple subclasses of DTHTMLElement which provide specialized behavior for several HTML tags. One such HTML element primarily provides an attributedString method that returns a representation of said element as NSAttributedString. The base class provides an extensive implementation that also walks through its children. But for an <img> tag we don’t care about these anyway, so the overwritten version of attributedString does not need to iterate over the child nodes.

This method is what they call a “class cluster” and I got the inspiration for it from UIButton. You might remember that UIButton does not have an alloc/init but rather you instantiate buttonWithType:. The reason for this is that you never actually get a UIButton, but each of these types returns a specialized UIButton subclass.

Same with DTHTMLElement, there the tag name is used to look up the class to be used for the initializiation.

+ (void)initialize
{
	// lookup table so that we quickly get the correct class to instantiate for special tags
	NSMutableDictionary *tmpDict = [[NSMutableDictionary alloc] init];
 
	[tmpDict setObject:[DTHTMLElementBR class] forKey:@"br"];
	[tmpDict setObject:[DTHTMLElementHR class] forKey:@"hr"];
	[tmpDict setObject:[DTHTMLElementLI class] forKey:@"li"];
	[tmpDict setObject:[DTHTMLElementStylesheet class] forKey:@"style"];
	[tmpDict setObject:[DTHTMLElementAttachment class] forKey:@"img"];
	[tmpDict setObject:[DTHTMLElementAttachment class] forKey:@"object"];
	[tmpDict setObject:[DTHTMLElementAttachment class] forKey:@"video"];
	[tmpDict setObject:[DTHTMLElementAttachment class] forKey:@"iframe"];
 
	_classesForNames = [tmpDict copy];
}
 
+ (DTHTMLElement *)elementWithName:(NSString *)name attributes:(NSDictionary *)attributes options:(NSDictionary *)options
{
	// look for specialized class
	Class class = [_classesForNames objectForKey:name];
 
	// use generic of none found
	if (!class)
	{
		class = [DTHTMLElement class];
	}
 
	DTHTMLElement *element = [[class alloc] initWithName:name attributes:attributes options:options];
 
	return element;
}

Since all these subclasses derive from DTHTMLElement I can treat them as such whenever I am iterating over them. Each provides an attributedString method, however specialized it might be. This polymorphism should give a further performance improvement because there is never a need for giant “if trees”.

The only remaining items in the tag start/end handling blocks are related to special CSS style cases that are difficult to model with the current brute for CSS selector methodology. For example setting the headerLevel property to 1 for a <h1>. Of course I could make a special H1 DTHTMLElement subclass or maybe even one for all headers.

One exception to this rule is the block that deals with a <style> block. Version 1.0 of DTCoreText has a bug where only the first part of a lengthly style sheet is actually being parsed. Simply for the reason that I never thought that libxml2 would send multiple CData callbacks for longer blocks.

In the previous version HTML created from attributed strings would attach the style information to the individual tags. Inspired by Apple’s NSHTMLWriter I created DTHTMLWriter and I’m also aggregating styles into classes per tag. Naturally this increases the size of such a style block enough for the above mentioned problem to manifest.

This is a case where a state in the string builder class needs to be modified because of the contents of the stylesheet and so the logical place is in the handler block.

Oh, and some bug fixes, too!

First there was the problem with the long style blocks. That’s working now.

Actually the motivation for this weeks worth of changes came from an open issue. The problem was that if you had two underline words then the space between them would also get underlined. This was quite hard to fix in the old parse style because of the detachment of text and formatting information. This is fixed now.

There was a bug in DTLinkButton that would manifest if you were using highlighting on tapping on links. The assumption was that there could only ever be one glyph run and so only the first one got displayed there. The bug resulting from this was that hyperlinks consisting of multiple Chinese characters would consist of multiple glyph runs of which all but the first would not be displayed. Fixed.

There was also a second problem with DTLinkButton that would only show for very small fonts. This button has a feature to make itself grow in size if the hit area became to small for normal fingers. This caused small text to shift to the left side. Fixed.

Then there was a problem with dealing with pt versus px as length measurement. Previously I had treated them as equivalent but it turns out that apparently 1 point should be 1.3333 px. Because of this HTML that specified font sizes as pt would make the text appear too small. Fixed.

Conclusion

I was too lazy to to a benchmark comparison between both versions, but my guess is that the new method should be faster. Maybe somebody can verify this by timing it.

I’m hoping that the source code in this new version is so much more simple to understand that more people can contribute to the project. For example now that the entire tree of a <table> tag exists one could implement a simple form of table support.

Just two days ago it didn’t look to me like I could bring this development branch to 100% coverage of the unit tests, but I endured and finally I got all test cases to pass, including a few new ones. This should mean that the results should be identical or better than what version 1.0 was generating.

Your feedback cordially invited.

You can have podspecs point to the master branch as well, but then you never really know what you get. This can possibly cause many headaches especially in larger projects where you cannot track the state of each individual sub-project.

Therefore it is generally recommended – if not required – to make use of tags in GitHub.

Tags are like labels that you attach to the current state of a repository. You can create them simply by issuing the following command in the repository root folder.

git tag "1.0.1"

You can list the existing tags with:

git tag -l

There is an option on git push to have the tags also travel to the origin repository on GitHub:

git push origin master --tags

Once you’ve done that, GitHub provides snapshots of the tagged state as tar balls and zip files… though you probably don’t want to use these but rather have the project as a clone so that you can easily update it.

DTCoreText News

Amongst the fixes that made this maintenance release necessary where:

• Fixed Block-Retain-Cycle
• Fixed a second minor retain-cycle
• Workaround for Chinese Font cascade bug in iOS 5.x (radar://11262229)
• Workaround for a CoreText memory leak in iOS 4.3 (fixed in 5.0)
• Some Unit Testing corrections
• Updated Readme regarding necessary linker flags

I finally got around to also filing a Radar for the cascade bug. The memory leak issue is fixed as of iOS 5, the problem there was that if you replaced the paragraph style attribute on an NSAttributedString with a new one, the previous entry would leak. I fixed that by simply removing the attribute first before calling addAttribute with the new style.

The project has surpassed 1000 watchers on GitHub which tells me that it is definitely of use for many people. If you have any app making use of it, then please tell me about it as I like to feature your work. I especially love to receive testimonials like this one.

The changes to the Readme reflect the outcome of research done by David Hoerl. The question was to determine which linker flags are really necessary when linking in DTCoreText – or any other static library that contains categories – into an app.

Linker Flags Wisdom

The linker in general tries to only link in code that is actually used. So if you have C-functions then their code will not end up in the final app binary if it is never being called. This does not work for Objective-C category extensions because of the dynamic nature of method resolution.

Therefore you would generally use the -ObjC linker flag when dealing with static libraries that contain Objective-C code.

Greg Parker from Apple who refers to himself as “Runtime Wrangler” explains it like this:

-all_load and -force_load act at link time, not at load time. -all_load and
-force_load tell the linker to link the entire static archive in the final
executable, even if the linker thinks that parts of the archive are unused.

When you link a traditional C static archive (.a file), any code from the
archive that is never referenced in the final executable is simply omitted from
the executable. So if you had a static archive with 999 functions you did not
call and 1 function that you did call, your final executable would include only
that one function.

Objective-C categories break the C static archive model, because you want the
Objective-C category to appear in the final executable even though there are no
C symbol references to it from the executable.

The best solution for Objective-C categories in static archives is the -ObjC
linker option, which tells the linker that all Objective-C categories in the
archives are “used” but to apply the usual reference algorithm for everything
else in the archives.

The -ObjC option is broken in some versions of the linker. For those cases the
-force_load and -all_load options work. The final executable may be larger than
necessary with those options, if there were classes or C functions that could
have been omitted by the linker. If you have multiple archives and only some of
them have Objective-C code then -force_load may generate smaller output than
-all_load.

On iOS you’d typically only link in libraries that you need, as opposed to traditional C or C++ where you’d often link in large static libraries that are collections of utility methods. So in the case where the libDTCoreText.a is the only static library should be  no difference between force_load and all_load at all.

Personally I prefer the simplest approach which is to first try to get by with only -ObjC and if I get unrecognized selector crashes to additionally add -force_load because there I don’t need to know or specify the path to the specific library.

DTRichTextEditor

I’ve streamed all the 1.0.1 updates also into DTRichTextEditor which uses DTCoreText for display of rich text. Changes there include:

• Support Left, Center, Right and Justified toggling of paragraphs
• Preliminary work on supporting lists

I love to get feedback from people who are actually using the editor in shipping apps. The most prominent one is Dootrix who made the Simpl iPad app. I interviewed the maker on my podcast, if you haven’t done so I urge you to listen to it as I think it was one of the most enlightening conversations I ever had on air.

I keep getting requests for a ways to test the editor component before purchasing it. Also the work on lists as well as some feature requests are still open for the editor.

Unfortunately I won’t have any time to devote to these requests as we are in “crunch time” for a major project of maximum importance for the next two weeks. Therefore I ask for some patience.

The Future

I’m not making very much money from selling licenses. Only enough to justify it as a hobby. I might be forced to dramatically raise the price in the near future. So if you are thinking of buying then better do so now, because you then will have access to my Subversion repository and get the benefit of all future updates.

On the above mentioned podcast episode I also discussed what my thoughts where related to the future of rich text editing on iOS.

I am happy if Apple takes on more of the burden that DTCoreText and DTRichTextEditor are currently carrying. It is astonishing that they truly believe that people would use contentEditable UIWebViews for that task. As iPads become equal-partners in content creation this is an essential platform feature.

There are two levels that I can see Apple move forward on:

• Add the missing protocols and interfaces for interacting with selections and the magnifying glass – you would still have to create your own editor but at least you could do way more easily
• Enhance UITextView – which is using WebKit under the hood already – to be editable. Or alternatively create a totally new Rich Text Editing View.

Either way I will still have a market and and audience while people support 4.3 and above, or 5.0 and above when 6.0 finally ships. I would predict the former and not bet on the latter.

To cut a long story short: progress is being made and patience is required.