Ich habe in einem Vortrag auf der Macoun gelernt, dass man dafür in die Tiefen von CoreText und Konsorten einsteigen muss.
Eventuell hat sich das auch in den letzten Jahren vereinfacht, aber ich glaube nicht.

Das ist ein Objective-C-API, das auf Core-Text basiert.

Nein, da ist nichts dergleichen schon eingebaut. Ansetzen würde ich da beim NSLayoutManager. Über einen eigenen LayoutManager könnte man Formelsatz hinkriegen. Einfach ist das aber nicht.

NSLayoutManager ist herrlich - da kämpfe ich auch gerade mit.. Könntest du nicht eine UIView-Subclass machen, in der du Zähler und Nenner als Labels oder TextFields machst?

TextField in TextField ist irgendwie blöd und geht das überhaupt?

Ja. Sofern NSTextAttachment unterstützt wird (weiß ich nicht). Dann kann man eine beliebige Cell also statt einem Image wohl auch ein TextField dort darstellen das mit dem Text mitformatiert wird.
Das erste WYSIWYG Programm das mit Formeln sehr gut umgehen konnte war ca. 1993 FrameMaker. Dort wurde aus der Bedienung klar dass eine Formel quasi als eine Buchstabenbox gehandhabt wird. So wie ein Bild das man in ein RTF einbettet. In die Box wird der Formel-Baum als geschachtelte Elemente reingerendert. Die Größe der Box wird dynamisch berechnet (bei Framemaker gab es eine Art "sizeToFit").
D.h. Du brauchst zu jedem Formelknoten eine -size, eine -baseline und eine -draw-Methode. Dann kann z.B. ein Klammerknoten so hoch werden wie das größte eingeklammerte Element und so breit dass Platz für Klammern und Kind-Elemente bleibt. Und neben die geklammerten Kind-Elemente die Klammern links und rechts malen. Und ein Bruchstrich-Element kann den Zähler oben und den Nenner unten malen.
Wenn Du das in das NSTextAttachment reinbringst sollte es auch in beliebigem Fließtext unterzubringen sein.
NSLayoutManager oder CoreText braucht man dafür nicht.

Eine Möglichkeit wäre, das mit einem NSAttributedString und superscripting zu machen:


Dann kannst Du den Nenner mittels Kerning nach links schieben:

ich mache das so, um Taktarten darzustellen, was ja auch nur einem Bruch entspricht. Geht alles ohne subclassing oder custom drawing. Klappt auch noch mit iOS 6.

Gruß, Markus

Hier meine Variante. Allerdings funktioniert die nur mit Brüchen, wo der Zähler grösser als der Nenner ist (eben für Taktarten). Für wirklich generische Brüche kommst Du wohl um TextKit nicht herum.

Kleiner Hinweis zu Best Practices blog.sourcetreeapp.com/2012/08…-sourcetree-and-git-flow/

falscher Thread?

Ups

Auch wenn es OT ist, ich praktiziere Featurebranching nicht, als Einzelkämpfer auch nicht nötig, allerdings gibt es auch das Argument, dass FB continuous integration erschwert und eigtl dessen Grundidee zuwider läuft (zu spätes mergen wird schwierig, Abhilfe in den feature branches durch regelmäßiges rebase möglich etc.). Hier ein Video mit Martin Fowler zu dem Thema:

[media]http://m.youtube.com/watch?v=xzstASOvqNc[/media]

Ich komme mit seiner Argumentation nicht so ganz klar.

Continuous Integration wird doch erst dann wichtig, wenn Dein via TDD fertig implementiertes Feature in den Master Branch geschoben wird.
Im Allgemeinen sind bei mir die Merge Probleme weniger geworden, je mehr unterschiedliche Features auf unterschiedlichen Branches entwickelt werden.

Dazu muss natürlich klar sein, dass besagte Features 'für sich' implementiert werden und kein Verändern der UI- oder anderer Elementen aus dem Branch stattfindet.
Sobald man in einem Code herumhampelt (beispielsweise um sein eigenes View anzuzeigen), der mit an Sicherheit grenzender Wahrscheinlichkeit verändert werden kann (also absolut jede bereits existierende Datei), baut man sich potentielle Merge-Konflikte.
Solange man diesen Code jedoch unverändert lässt bzw. die gemachten Änderungen aus dem Branch fern hält, wird es keine Probleme geben.

Baut man also das Feature in einem völlig anderen Ordner, quasi als vollkommen neues Projekt autark vom eigentlichen System und verschmilzt dann die benötigten Dateien mit dem Master, dann passiert effektiv nichts, was Continuous Integration in irgendeiner Weise beeinflussen kann. Schließlich gab es die Dateien ja vorher nicht.
(Natürlich könnte man einwerfen, 'Wenn jetzt noch ein Team seine Klasse genauso genannt hat wie…', doch darauf lässt sich kontern: 'Wenn ein anderes Feature ganz genau so heißt, dann habt ihr wohl was falsch gemacht.'
Scheint übrigens ein beliebter Konter in der Softwareentwicklung zu sein…)