I reported a while ago that I was forced to tag the current state of the DTCoreText master repository as 1.0.0. The reason for this was that CocoaPods was starting to gain lots of momentum and several people wanted to use DTCoreText via a podspec.
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.
Categories: Updates
