Formatting poetry - non-standard indents

[JoanneM]

Hi all. I am using this for my non-indented lines to preserve hanging indents and spaces between stanzas:

div.poem { margin: 0 0 0 0; padding: 0;}
p.stanzafirstline {margin: 30px 0 0 0; padding: 0; text-align: left; text-indent:-30px;}
p.otherlines {margin: 0 0 0 0; padding: 0; text-align: left; text-indent:-30px;}

Obviously for a line which is normally indented, I just define the margin differently:

p.otherlines1tabindent {margin: 0 0 0 30px; padding: 0; text-align: left; text-indent:-30px;}

But I am trying to figure out how to handle poetic lines which start immediately below where the previous line ended, like so:


This is a first line

and this second line starts below it.

(Hopefully that shows up properly.)

I can think of some inelegant workarounds, eg. inserting non-breaking spaces at the beginning of the line or individually defining the margin of each of those lines, except that that only works if the reader uses the same font and font-size I am using, plus if the line is long enough to wrap around the screen, it'd look double-spaced and probably pretty weird.

Is there any way to define a margin conditionally, so it will look at the previous line for how much it should indent?

[Jellby]

That is tricky, and whatever solution you find is bound to fail in some cases, particularly with a narrow screen or large font size (what would be the desired result if, for example, the screen is just wide enough to fit "This is a first line"? A blank line?)

The immediate solution is repeating the first line, but with a "visibility: hidden" style. But the "visibility" property is not included in the ePub 2.1 standard, which means readers are not required to support it... and just image what would happen if a reader doesn't.

Another possible solution would be to give it a white text color... but that of course would only work if the background is white, which cannot be assumed.

It has just occurred to me that maybe this works: "position: relative; right: 200%;" It should effectively move the "invisible" part out of the screen. In any case, these tricks rely on having the text repeated, which will break as soon as the CSS is ignored or not supported.

Maybe it's safer to have "This is a first line" only once, but moved up from its natural place (with "position: relative"), but that would be tricky again if you don't know the line spacing, and may be hard to get right in all circumstances.

At the end of the story, the only really safe solution is simply assigning a large arbitrary right margin to the second part of the verse, forget about getting exact alignment with the first part and trust the reader (the person) to understand it.

[JoanneM]

Thanks so much for your ideas.

Originally Posted by Jellby

Maybe it's safer to have "This is a first line" only once, but moved up from its natural place (with "position: relative"), but that would be tricky again if you don't know the line spacing, and may be hard to get right in all circumstances.

This gave me an idea. Could I make the font size larger, so superscript and subscript are the same size as my regular text elsewhere, and then use <sup> and <sub> and have each pair of lines on the same line? Or would that break in a lot of devices?

[Jellby]

You could explicitly make superscript and subscript font sizes equal to the base size, or just apply super and sub alignment without changing font size

sub, sup { font-size: 100% }

or

span.moveup { vertical-align: sup }
span.movedown { vertical-align: sub }

(I'd prefer the second, because the texts are not really superscripts and subscripts.)
It could work, but you don't have control on the exact vertical spacing.

[GMcG]

I was just in another thread, discussing tables. And I like tables for formatting.
What about this?

George

[Hitch]

Originally Posted by GMcG

I was just in another thread, discussing tables. And I like tables for formatting.
What about this?

George

Tables will work fine IF:

• The lines of poetry are very, very short, so that you run ZERO risk of the first line ever wrapping inside the table cell, and,
• The poem is extremely short in its entirety, so you never run the risk of the table rows being longer (greater in number) than the "page" (screen) of the device upon which it is being viewed.

See, if the book is an ePUB, most devices, if the table is long (numerous in rows) will simply skip past the entire table, as if it doesn't exist. Like an image that's too long to display--just jumps right past it. In the MOBI world a) in "Kindle for iPad," you currently get some very hinky border results (unwanted, mind you) during viewing, as right now, K4iPad is displaying both the K7 and K8 styling, and, yes, that's a real doozy; and, b) in MOBI 7, (e-ink) if the table is longer than the screen, on the second "page" (screen), the formatting breaks entirely, as if the device has "forgotten" that there is any table styling. As far as I know, this has not been fixed.

Truly, other than Jellby's suggestions, I do not believe that what you are seeking can be done, and I am fairly sure that right this second, it cannot be done on any Amazon format successfully. There's just no way, in CSS, that I know of, to tell a line that it needs to start at the end of the previous line, when in ebooks, the horizontal position of the last character of the last word of the previous line can (and does) always change. I think that the super/subscript idea is the best...but I also think the chance of that format breaking in various devices or readers is exceedingly high. FWIW.

The hidden text part will not work, at least, not right now, on any MOBI read in Kindle For iPad; it's developed hinks lately, displaying the styling not for K7 or K8, but both, which has been great fun (not) to deal with on ANY tabular solutions to situations like yours.

I wish I had something more clever to say, but I don't. The sub/super is probably your best bet. Good luck.

Hitch

[JoanneM]

Thanks so much for the suggestions! I am going to try the relative up/down solution and see if I can get that to work. Thanks again!