Re: FW: HTML rules and poetry

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 <[email protected]> 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-4LCm/o+qPMZ96Xl/[email protected]
> http://lists.pglaf.org/mailman/listinfo/gutvol-d
>

_______________________________________________
gutvol-d mailing list
gutvol-d-4LCm/o+qPMZ96Xl/[email protected]
http://lists.pglaf.org/mailman/listinfo/gutvol-d