0

I find some iphone book apps have such feature:

One screen one page of text without scrolling. The text can just fit into the whole screen with linebreaks and indentations.

I'm curious of how to implement this. How could I decide the length of text that just fit into the screen. And also, given the whole text, I can calculate out the number of pages.

If this is not possible to be done on iPhone(runtime?), then is it possible to process the text before storing it in app? I mean I calculate how many pages I need(how to split the raw text), probably how many lines per page.

KailZhang
  • 33
  • 2
  • 5

2 Answers2

0

I think this is what you are looking for

iPhone SDK: How do you measure the width and height of a string using Quartz?

The accepted answer gives methods you can call on NSString to calculate sizes

Community
  • 1
  • 1
Liam
  • 7,762
  • 4
  • 26
  • 27
  • Thanks for your answer. I did check NSString UIKit additions. But here I wanna know the size of the text before it's rendered. I think this may be only possible by deciding how many lines a page can hold with predetermined font rather than calculating at runtime. – KailZhang May 05 '10 at 10:16
  • I presume that you have a fixed size to your text field? and you want the same font for each page. If so, then all you need to know is what text will be displayed on each page. To do this you will have to do some string manipulation to chop up the text for each page – Liam May 05 '10 at 15:09
  • You can't generally guess the size of a string on the screen without knowing the content. Look at these 10 character strings: 'iiiiiiiiii', 'mmmmmmmmmm' – FRotthowe Oct 07 '10 at 21:41
0

What I did for TouchTomes' books was have two iPhone apps. One was the reader that showed up on the App Store. The other was a renderer that calculated what could fit on each page, that only needed to be run in the simulator to create a book DB that the reader could use.

It would throw up a bunch of text, say 100 words, and see if that overflowed or underflowed. If it underflowed, more text was added (say 20 words) and it would binary search until it found exactly how much text would fit. Then it stored in a SQLite DB a row saying "page 12 shows words 100-228" for example. The app would go through this for each font. Another table held all the words in individual rows (!). An optimization step would chop that table down, combining words that always appeared on the same page no matter what font.

I used a Webkit display so the book could include HTML formatting. Now that really complicated the page breakup (e.g. had to keep italics going from page to page) but it let me include some fancier formatting in the text.

Then the reader app had very little to do to display pages; from the page id look up what range of words go on that page, then throw that text up into a webkit view. The user could jump between pages all over the book very quickly, all the hard CPU work had already been done by the rendering app.

Graham Perks
  • 23,007
  • 8
  • 61
  • 83