View Single Post
Old 04-10-2010, 08:04 AM   #11
charleski
Wizard
charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.
 
Posts: 1,196
Karma: 1281258
Join Date: Sep 2009
Device: PRS-505
Quote:
Originally Posted by pdurrant View Post
There is a conflict here between the desire to control the layout by the publisher, and the desire to allow the reader to control the layout through the reading software.

For example, a publisher might like to specify one of two column text, depending on the width in characters (ems) of the current display. But equally, the reader might well want the choice to be a preference.

I think any page-size choice of formatting should be automatic by default, but that reader software should be able to provide the reader with the option to overrride the choice in the publication.

I have no idea how this would be done in practice with the current layout standards that have been mentioned in this thread.
This is more of an implementation issue than a standards one. A lot of it will be determined by the complexity and richness of the UI that is offered by the Reading System.

I think the best route is to encourage this to be done through modification of a user-level styling file. A RS that only allows a few basic modifications could then be enhanced by those willing to write more advanced css code.

Quote:
Originally Posted by pdurrant View Post
As Harry said, it would be wonderful to have some support in for footnotes. At the moment, I do footnotes with a link away to another page. I'd love to seem some specific coding that allowed footnotes to be identified by reading software, and either displayed in a pop-up window, or placed at the bottom of the page.
One important issue about footnotes: at present neither CSS3 nor XSL-FO explicitly support reflowing footnotes onto the next page. The common scenario in which there's a footnote on the 5th line from the bottom pointing to a note that's longer than 4 lines (for example) will break unless the RS is smart enough to realise that it needs to create a new footnote on the next page with the left-over lines. This needs to be mandated in the specification to make sure implementers don't mess it up. Using a pop-up windows instead would negate the problem (and is something I'd find preferable).
charleski is offline   Reply With Quote