I did a book of Vidyapati poems for PG:

http://www.gutenberg.org/files/38174/38174-h/38174-h.htm

I let guiguts put in <span>s with margins to format the poetry and it looks OK in HTML but not at all well on a Kindle.  I made a Kindle version using non-breaking spaces and making some modest formatting changes.  Instead of the speaker of the lines (Krishna) being listed on the same line as the words I put him on his own line.  The text did NOT wrap the way we'd all like but the result was readable on a Kindle and I don't think the Kindle could do better with any other format.

EPUB and Kindle versions are here:

http://archive.org/details/VidyapatiBangiyaPadabali

I sell the same Kindle version on Amazon, but not many.

James Simmons


On Fri, Nov 30, 2012 at 2:29 PM, Lee Passey <lee@passkeysoft.com> wrote:
On Thu, November 29, 2012 5:16 pm, James Adcock wrote:

>> In the end, I think I would follow the W3C and use:
>> <pre class="poem">
>
> The pre suggestion is so bad that I think that those who read it at DP
> assumed you have not seriously studied the issue of how to code poetry in
> HTML.

Ahhh, a blanket rejection without supporting analysis. You ought to feel right
at home with PGDP.

> In general the "poetry" problem is how to reliably wrap lines of text on
> small machines according to common poetry standards, and to do so in a
> manner that actual runs correctly on the great majority of reader devices.
> And to do so in a manner that doesn't require an excess of gimcrackery while
> coding the HTML.

If I understand this run-on sentence correctly, you believe that the primary
problem of encoding poems is how to make them wrap correctly. While I agree
that that is /one/ of the problems, it is not the only problem, nor even the
most important problem.

In my mind, the most important problem is making lines end where the author
wanted them to end, as that has the greatest impact on rhyme and meter. The
second most important problem is making lines begin where the author wants
them to begin. /Now/ we are faced with the problem of how to wrap lines given
dynamic screen sizes in such a way that the line endings and beginnings are
apparent without being distracting.

Two overarching concerns here are 1. how to accomplish these goals when /CSS
is not supported/; and 2. how to accomplish these goals in the simplest and
cleanest fashion.

> This problem is an unsolved, and presumably unsolvable problem.

Unlike you, I do not live in a binary world, where you either have total
success or total failure. Sometimes good enough is good enough, and a good as
you can get is as good as you can get. The inability to achieve perfection is
not an excuse for abandoning the attempt.

So, if you don't have CSS (like Mobipocket and 1st generation Kindles), <pre>
is probably as good as you can get. At one time, Mobipocket did have some sort
of proprietary markup which would cause poetry to wrap with subsequent
wrapping to be right justified. If you were to mark poetry with something
recognizable, such as <pre class="poem"> a post processing program could
easily transform that into whatever Mobipocket is expecting before passing the
file to your Kindle program.

Now, if you allow CSS then, and only then, can "DP gimcrackery" come into
play. But once you allow CSS, the actual element that the CSS is assigned to
starts to become less relevant. For example, I can certainly create a CSS rule
such that <pre class'para'> would behave exactly like <p>; I don't recommend
this, I'm simply saying that it's possible.

So my approach is to use <pre class='poem'> and to add all the "gimcrackery"
to a pre.poem {...} rule. If you've got a UA that doesn't do CSS (like the
Kindle) or which doesn't do it well, the default <pre> presentation is
probably as good as it's going to get. But if you've got a UA that supports
CSS, you override the default presentation of <pre class="poem"> to give you
whatever presentation you want.

[snip]

> One partial suggestion is to minimize indents and margins when doing poetry
> in order to minimize the wrap problem.   And recognize when the poetry in
> the original book was wrapped to begin with.
>

A trick I particularly like is to add inter-word non-breaking spaces to lines
of poetry, placing ordinary spaces only at those points in the phrasing where
word wrapping should be allowed. It requires a lot of intelligent evaluation,
and is not necessary in most cases, but it is an interesting tool to have in
the tool belt.

> Liz Castro had an intelligent discussion on the problem about a year ago:
>
> http://www.pigsgourdsandwikis.com/2012/01/media-queries-for-formatting-poetr
> y-on.html

In general I tend not to be very impressed with Ms. Castro's advice. In this
case, she settles on increasing the left margin and then adding a negative
("hanging") indent to the beginning of each line, just as the "HTML Best
Practices" working group at DP advocates. And of course, the negative
indentation trick can be confusing on poems where different spacing is applied
at the beginning of each line (e.g. Percy Bysshe Shelly's "To a Skylark").

So far, I have not yet been convinced that <pre class='poem'> is not the best
way to indicate the beginning of a poem. At the same time, I've not yet made
up my mind as to the best way to construct the CSS rule for pre.poem.
_______________________________________________
gutvol-d mailing list
gutvol-d@lists.pglaf.org
http://lists.pglaf.org/mailman/listinfo/gutvol-d