Ugly formatting

[DaleDe]

Originally Posted by Jadon

Not remotely. I convert whatever format I start with to HTML, then run that through BookFixer, then edit that in The Semware Editor. There I add various things, like a title block and changing headers for an anthology, say. And I make lots of substitutions and checks, like searching for and fixing &ldquo;</p> from where Tidy gets confused. A 300-page novel might take a half-hour of editing, and that just gets it to my good-enough standards. I won't find OCR errors, or plenty of other things, but I'll get the formatting up to a level where I might be able to read ten pages between annoying errors.

Thanks, that is about where I am also. Still a little too much manual fixup but doable.

[RWood]

Originally Posted by Tanzaku

No, we're still fussing with the template and will have some more samples with the various suggestions from this thread. What font size are you comfortable with? The draft PDF was as 9-point font for the basic text.

BTW, another option we are looking at is using a font with a larger x-height. (The x-height is essentially the size of the lower half of the letter -- for example the full height of the letter "e" but only the part of the letter "t" below the cross.) Fonts with a larger x-height are easier to read at the same font size. Examples: New Century Schoolbook is an example of a font with a large x-height. Palatino is an example of a font with a smaller x-height. Hence, New Century Schoolbook at 9-points is actually easier to read than Palatino at 10-points. One of the worst reading fonts is Times and Times New Roman -- unfortunately a very commonly used font for simple PDFs because it is one of the default fonts in the PDF reader. Too bad!

Anyway, thanks for prodding me about your question. Hope this helps!

I have found New Century Schoolbook to be the easiest font to read. The large x-height as well as the open glyphs allow quick identification of the word shapes. My reading speed increases when NCS is used. Likewise, Baskerville or even New Baskerville will decrease my reading speed and produce a headache after about 15 minutes of reading. TNR is a condensed font by all standards except its own. It was designed to fit the most characters on a printed page at a given size as possible.

The current Sony Reader practice of making oblique fonts on the fly (along with bold and bold-oblique) is a trade-off between processor power, storage requirements (for the extra fonts), and the IO requirements of the hardware system design. I have made several books in BookDesigner (for my use alone) implementing full font families and the results (while a bit slower on page turns and bit larger in size) are very rewarding.

[JSWolf]

Rwood, how did you manage to implement full font families using Book Designer? I'd love to know how. Also do you know if it is possible to just implement a bold font and an italic font? I don't mind them being times new roman and the standard font being the dutch one.

[RWood]

Originally Posted by JSWolf

Rwood, how did you manage to implement full font families using Book Designer? I'd love to know how. Also do you know if it is possible to just implement a bold font and an italic font? I don't mind them being times new roman and the standard font being the dutch one.

On the Make eBook|Sony Reader|Styles Tab I added the external font family and then assigned them to specific paragraph types. I did set the style for each to normal to keep the Reader from obliqueing (is that the way to spell it?) the glyph. It works great except for intra paragraph italic where it still obliques the base font.

[DaleDe]

Originally Posted by RWood

I have found New Century Schoolbook to be the easiest font to read. The large x-height as well as the open glyphs allow quick identification of the word shapes. My reading speed increases when NCS is used. Likewise, Baskerville or even New Baskerville will decrease my reading speed and produce a headache after about 15 minutes of reading. TNR is a condensed font by all standards except its own. It was designed to fit the most characters on a printed page at a given size as possible.

The current Sony Reader practice of making oblique fonts on the fly (along with bold and bold-oblique) is a trade-off between processor power, storage requirements (for the extra fonts), and the IO requirements of the hardware system design. I have made several books in BookDesigner (for my use alone) implementing full font families and the results (while a bit slower on page turns and bit larger in size) are very rewarding.

New Century Schoolbook has always been my favorite font. I always try and use it when I work in Framemaker.

Dale

[GregS]

Nice thread about an important problem.

There are a number of problems associated with ebooks that need attention. First, for serious rather than recreational reading page numbers are now meaningless, at best as internal references to p-book editions. Standard formats need to include rational numbering schemes as mandatory requirements.

If we end up numbering chapters and paragraphs, the option of showing the numbers has to be dealt with elegantly - at the moment this is a black-hole. Page numbers are effectively gone, and nothing is there to replace them.

Second, and I am strongly biased in this towards non-fiction works, reflowing formats are fine for most novels, however, things get a lot more complex when serious non-fiction texts become involved and frankly we are nowhere close to solving this one.

I believe PDF is the way to go, but not in the way it is implemented. Large print books are needed, sometimes more words on the page are critical (small type) reading devices will always vary in size, some readers will want references in the margins (Shakepeare's plays for instance, but many other works being used for study would benefit, precisely because page numbers are a dead issue) and the idea of catering for this with different PDF versions of the same book becomes mind bogglingly complex.

The contradiction is making a fixed typographic system (PDF) into a semi-dynamic one. I use the term semi-dynamic, because there is little need to make it on-the-fly, after all the devices exist before the ebook, it should be easy enough to generate material for the size of different devices.

That is the problem as I see it. Does TeX fill the bill? Or is it necessary to approach it from a macro style sheet point of view? I tend to favour the latter solution.

[kkingdon]

Originally Posted by GregS

There are a number of problems associated with ebooks that need attention. First, for serious rather than recreational reading page numbers are now meaningless, at best as internal references to p-book editions. Standard formats need to include rational numbering schemes as mandatory requirements.

If we end up numbering chapters and paragraphs, the option of showing the numbers has to be dealt with elegantly - at the moment this is a black-hole. Page numbers are effectively gone, and nothing is there to replace them.

I've been thinking that reflowable ebook editions of serious works should include an extra index of "page numbers" taken from the page numbers of some reference fixed-layout edition. The reference page numbers need not always be displayed, but should easily be called up on demand for momentary display or for inclusion in an annotation. Chapter/paragraph references should also be available in a similar way as both a navigation index and on-demand displayable property of the current reading location, though such references need not be linked to a particular fixed-layout edition of the work.

[Lexicon]

I'll admit to being a little surprised to see so much support here for hard coding the layout of eBooks. Given the myriad eReading devices that currently exist, a number which is only going to increase, surely it is pretty much impossible to code the layout of a single file such that it appears equally good on all eReaders? Are people really prepared to spend time reformating and hand-tuning their eBooks again and again as they upgrade their devices?

I thought HTML had taught us all about the disadvantages of integrating presentation instructions with content. If people are going to devote time to marking up books then I think they'd be better served marking up meaning rather than presentation. Defining your eBook in terms of logical book elements like title, author, chapters and footnotes makes more sense than adding font tags and layout tables.

I believe that presentation should be handled by software on each eReader - the reflowing of text, widow and orphan detection, hyphenation, etc. could therefore be tailored to the strengths and weaknesses of each device. CSS shoud be supported so the designer can exert some control over the display and provide an attractive default presentation but the reader should be able to override this with their own CSS files if they feel it necessary.

I've been looking at the epub spec recently and I found it supports the DAISY standard - which was originally designed as a way of marking up a book (in terms of t-o-c, chapters, appendices and so on) so that it can be rendered into braille or interpreted by text-to-speech engines. It's XML so it can be formatted into readable text (for display on an eReader) using CSS files included in the epub container.

I'd urge anybody interested in converting pBooks to eBooks to take a look at the DAISY standard. Consider the advantages of only having to mark up a book once such that it is readable on all epub devices and accessible to the visually impaired.

[JSWolf]

Originally Posted by GregS

Nice thread about an important problem.

There are a number of problems associated with ebooks that need attention. First, for serious rather than recreational reading page numbers are now meaningless, at best as internal references to p-book editions. Standard formats need to include rational numbering schemes as mandatory requirements.

If we end up numbering chapters and paragraphs, the option of showing the numbers has to be dealt with elegantly - at the moment this is a black-hole. Page numbers are effectively gone, and nothing is there to replace them.

BBeB has page numbers. And when you look at different versions of pbooks and editions, you can end up with different page numbering. If you are So basically, when you refer to page numbers on the ebook, you refer to the page number and text size and then you have it.

[GregS]

Originally Posted by JSWolf

BBeB has page numbers. And when you look at different versions of pbooks and editions, you can end up with different page numbering. If you are So basically, when you refer to page numbers on the ebook, you refer to the page number and text size and then you have it.

The id attribute is more than sufficient when linked to XMLnamespace for unambiguous references. But it takes two factors to work.

First the XMLnamespace must be truly unique for all time, unfortunately the common method of URL + location is not that, so a simple system of generating truly unique identities is needed (it not hard and a perfectly good system already exists).

The second factor is to logically apply id attribute ids to every publication (which can be achieved automatically with a simple script).

The problem with the text size is that device will change size overtime - my opinion is that the page number is basically dead as a reference point for electronic literature, milestone page numbers could be used but XML already supplies the means to elegantly deal with the problem.

[DaleDe]

Originally Posted by JSWolf

BBeB has page numbers. And when you look at different versions of pbooks and editions, you can end up with different page numbering. If you are So basically, when you refer to page numbers on the ebook, you refer to the page number and text size and then you have it.

Can you actually tell the text size? Other than s,m,l which varies from book to book?

Dale

[DaleDe]

Originally Posted by GregS

The id attribute is more than sufficient when linked to XMLnamespace for unambiguous references. But it takes two factors to work.

First the XMLnamespace must be truly unique for all time, unfortunately the common method of URL + location is not that, so a simple system of generating truly unique identities is needed (it not hard and a perfectly good system already exists).

The second factor is to logically apply id attribute ids to every publication (which can be achieved automatically with a simple script).

The problem with the text size is that device will change size overtime - my opinion is that the page number is basically dead as a reference point for electronic literature, milestone page numbers could be used but XML already supplies the means to elegantly deal with the problem.

I do not see that you have suggested a solution, only a method. So what do you count? I vote for paragraphs in standard books and stanzas in poems or lines in poems if appropriate.

[GregS]

Originally Posted by Lexicon

I'll admit to being a little surprised to see so much support here for hard coding the layout of eBooks. Given the myriad eReading devices that currently exist, a number which is only going to increase, surely it is pretty much impossible to code the layout of a single file such that it appears equally good on all eReaders? Are people really prepared to spend time reformating and hand-tuning their eBooks again and again as they upgrade their devices?

Currently yes. It s just impractical. But a PDF (fixed page) solution does ensure it will look good on every device if a means is made to generate it for each device as needed.

The problem simply does not really exist as a major concern for popular novels. But other works can and often do have special typographical elements that need to be treated with fidelity regardless of the device being used.

The problem can be solved without hands-on fine tuning for each device. In fact the problem can be reduced to just several broad contexts all based on relative size (mini, small and normal). 99% of the time nothing needs to be specially done, but exceptions have to be catered for and how each is treated in the context anticipated.

Originally Posted by Lexicon

I thought HTML had taught us all about the disadvantages of integrating presentation instructions with content. If people are going to devote time to marking up books then I think they'd be better served marking up meaning rather than presentation. Defining your eBook in terms of logical book elements like title, author, chapters and footnotes makes more sense than adding font tags and layout tables.

This is assuming that we are talking about presentation being the same as file format. I agree content and presentation has to be separate, PDF files as PDF and nothing more are a disaster for flexible use of content. XML is ideal. XML within PDF is in my opinion half-baked, disguised and problematic (relying on too many hidden factors - and you still get stuck with a presentation that is basically unchangeable).

I side with you very strongly in this, but for me the problem remains.

Originally Posted by Lexicon

I believe that presentation should be handled by software on each eReader - the reflowing of text, widow and orphan detection, hyphenation, etc. could therefore be tailored to the strengths and weaknesses of each device. CSS shoud be supported so the designer can exert some control over the display and provide an attractive default presentation but the reader should be able to override this with their own CSS files if they feel it necessary.

I have been waiting and waiting for CSS3, which is not a problem per se. As a stylesheet language it ideally solves all the presentation problems which presently haunt me.

The problem is, as has already been seen in HTML, CSS1 & 2, is that different implementations interpret differently, so unless there is a fundamental agreement on using the same code base everywhere, it is condemned to being an unreliable ideal. PDF for all that is wrong with it, presents exactly the same where ever it is displayed - that is its strength.

I am unfamiliar with TeX, but that may be another route already established.

The other factor is XML integrity for scholarly works, something which goes well beyond epub (a standard I strongly support). TEI is developed, does work (though it is a cow to employ) but it works well for this highly demanding area. Creating CSS in any form to do justice to the many features possible in this kind of markup is its own nightmare. CSS is great for relatively simple markup, in my opinion it crumples before the possibilities of something like TEI.

Originally Posted by Lexicon

I've been looking at the epub spec recently and I found it supports the DAISY standard - which was originally designed as a way of marking up a book (in terms of t-o-c, chapters, appendices and so on) so that it can be rendered into braille or interpreted by text-to-speech engines. It's XML so it can be formatted into readable text (for display on an eReader) using CSS files included in the epub container.

What you suggest as a solution, let the devices sort it out, is for me the problem - though for novels and light reading in general this is fine. This specific combination that you recommend is an excellent one and I would be likewise encouraging publishers to follow it based on what you have said.

DRM has so narrowed the vision of some publishers they forget the inherent versatility of ebooks, braille and text-to-speech, "big print" compatibility (and printing and referencing) should be part of every publication.

Originally Posted by Lexicon

I'd urge anybody interested in converting pBooks to eBooks to take a look at the DAISY standard. Consider the advantages of only having to mark up a book once such that it is readable on all epub devices and accessible to the visually impaired.

Thanks for the reference, I will be looking at this carefully, compatibility with epub and useful cross use markup is definitely the way to go for most texts.

[HarryT]

Originally Posted by JSWolf

BBeB has page numbers. And when you look at different versions of pbooks and editions, you can end up with different page numbering. If you are So basically, when you refer to page numbers on the ebook, you refer to the page number and text size and then you have it.

But it's NOT so easy on devices such as the CyBook where, not only do you have 12 available text sizes, but the user can install any font (family) they wish on the machine. Different fonts will produce different pagination.

[GregS]

Originally Posted by DaleDe

I do not see that you have suggested a solution, only a method. So what do you count? I vote for paragraphs in standard books and stanzas in poems or lines in poems if appropriate.

I missed your post earlier.

XMLnamespace.I.29

Chapter I paragraph 29 the <p id = "I.29">

For reference it is easy to go XMLnamespace.I.29/2-/3

Sentence 2 to 3 (inclusive) in para 29 Chapter I.

If the XMLnamespace is truly unique then that reference can located unambiguously.

The best thing is that IDs can be mixed.
XMLnamespace.I.29 [next element is an illustration]
XMLnamespace.illus.10
or as another form
XMLnamespace.1.illus1