It's been a slow week for my principle project, Phitext. Mainly, due to various distractions occurring in the business and in the industry at large.

Firstly, I feel the end of financial year fast approaching (June 30, Australia). This being the first year of Phiware I want to catch any gotcha's early. Lack of a (trusted) accountant does make things easier and I'm still getting used to the world of bookkeeping. I have very few physical receipts and invoices, having the majority of my business in cyberspace and all my operations online. So I want a shrink-wrapped solution to my bookkeeping needs and to help me fulfill my tax obligations. I've decided to sign up (free until August) at xero.com. Xero is a bookkeeping SaaS company from New Zealand, which is tailored to Aus and (obviously) NZ. My favourite feature is the fast bank reconciliation that automatically pulls transaction from PayPal and banks that have direct feeds. My financial institution doesn't have a direct feed but the import function is pretty spiffy too. My only gripe is that I have to pay a lot more just to get multiple currency support.

Second, I have been eagerly awaiting the arrival of my iPad, which finally arrived yesterday. I'm pleased to say Phitext works as expected, after a few bug fixes I might just be happy with v1.1. (Although I find it hard to meet my own high standards; the good enough solution for Phitext has been a hard one.)

Finally, there has been WWDC and I note that the session videos are now available to the rest of us iPhone devs not at the conference. Having just watched session 110, I believe I've made a design error and now I'm considering a small rewrite of PhiTextStorage and PhiTextFrame. So now I just need to muster up the courage to risk introducing a whole slew of bugs for some future proofing and a little efficiency gain. Of course, better design would possibly fix some bugs.

A good practice when using a scroll view is to break your content down into small, easily managed tiles. This is demonstrated in the third app of the ScrollViewSuite sample code. In fact it quickly becomes necessary as the scroll view's content grows since there is a limit to the size of a UIView, and there are big memory saving benefits. When I found that the call to CTFramesetterCreateWithAttributedString was the most expensive operation in Phitext I realised that the framesetter needed to be divided into small and manageable chunks. Hence, I created PhiTextFrame to encapsulate these chunks based on a predetermined tile size (where the size of the path for CTFrame is equal to tile size). Thus, PhiTextEditorView is composed of PhiTextView tiles which in turn displays one or more PhiTextFrames. This design is still stands in my mind, however, the focus is slightly amiss. PhiTextFrame currently seeks to fill the tile with as much text as possible, then a small adjustment is made to the size of the individual tile according to variable line heights (and the tile height is typically not a multiple of the line height). After watching Session 110 - Advanced Text Handling for iPhone OS, I see that I haven't given the framesetter the emphasis that Julio González did, and instead of filling the tile with text, the tile should shrink-wrap to chunks of text. Without knowing the details of the sample app in Julio's demo, I would have at a guess that his documents (particularly the LongText.xml) already has the text divided into manageable chunks (be it pages or paragraphs) at a document design level. I suspect that each page is self contained, in order to achieve asynchronous page loading each page is independent from preceding pages. This is not the case with all pagination systems.

Presently, the last line in a Phitext document is dependent of the first line (in fact Phitext has no pagination) thus the first page needs to be laid out before the last page. In a sophisticated word processor the layout of last page is dependent on the layout from, at least, the last page break (be it a manual page break or a section/chapter break). From my experiments with large documents, Apple's Pages app overcomes this problem by scrolling to the beginning of the document when to going gets tough. For instance when I increased or decreased the font size of an entire document spanning about 66 pages, Pages responds quite quickly by scrolling to the first page. The page scrubber on the right takes some time to accurately reflect the change; about half a minute before page 933 is available. Given the task, this isn't a bad user experience. The page scrubber at the bottom of the iBooks app also takes time to reload when changing font size with a large book (I tried the complete works of Jane Austen, from Project Gutenberg). Gladly, iBooks does not throw you back to the beginning of the book (indeed, that would be a bad experience), nor is the text at the top of the page fixed; it appears keep the layout of every page consistent with page breaks fixed. Project Gutenberg books don't usually have set page breaks, the only page breaks that are set is between books in the case of 'complete works.' This means that iBooks must know the text ranges for every page before the last page can be displayed. Yet the last page is relaid long before the page scrubber is reloaded. If iBooks uses Core Text, the only explanation that I can think of for this is that iBooks stores an index of text ranges (or just the start positions) for pages (or groups of pages) with each font (combinations of type face and size). Alternatively, since iBooks doesn't need all the features of Core Text it may be using a different layout engine that can determine the metrics much quicker than actually creating frames (assuming that the page scrubber is creating frames).