There have been one or two appends over the last month or two which have mentioned the difficulty of marking up poetry in html. Trawling through the web this afternoon I came across: http://gtwebdev.com/workshop/misc/verse.php Which also refers to: http://webtypography.net/Rhythm_and_Proportion/Blocks_and_Paragraphs/2.3.4/ To summarise, these seem to me to imply that there is an 'architected' way using CSS to mark up verse so that it is centred in the page, set flush left and ragged right (which I take to be what is required) namely to use a block whose CSS style is: {display: table; margin: 0 auto;} but please read the actual references for more erudite details. To take an example from PG3496 - Jack Tier by James Fenimore Cooper, which I have been converting to epub, there is a quotation at the head of chapter 4 which I originally marked up as follows: <blockquote class="margins-inset"> <p class="no-indent"> "Leander dived for love. Leucadia's cliff<br/> The Lesbian Sappho leap'd from in a miff,<br/> To punish Phaon; Icarus went dead,<br/> Because the wax did not continue stiff;<br/> And, had he minded what his father said,<br/> He had not given a name unto his watery bed."</p> <p class="justify-right small-caps">Sands.</p> </blockquote> Where the stylesheet contains: blockquote.margins-inset { font-size: 90%; margin-left: 3em; margin-right: 3em; margin-top: 0.5em; margin-bottom: 0.5em} This displays a poem left-justified to the left margin at 3em. Following the advice in the references I then changed this to: <blockquote class="margins-inset"> <p class="no-indent verse">"Leander dived for love. Leucadia's cliff<br/> The Lesbian Sappho leap'd from in a miff,<br/> To punish Phaon; Icarus went dead,<br/> Because the wax did not continue stiff;<br/> And, had he minded what his father said,<br/> He had not given a name unto his watery bed."</p> <p class="justify-right small-caps">Sands.</p> </blockquote> Where the style sheet now contains in addition: p.verse { display: table; margin: 0 auto} Displaying this changed version with IE9 makes the verse left-justified, but with the longest line centred, as the references imply. This doesn't work in any of my Sony Readers, but neither does it work any worse than the previous version, so I am thinking that as a way to mark up poetry in a device-independent way (works best on a full-spec browser, but still looks acceptable on an e-reader) so that one XHTML master file could be used to produce both HTML and epubs, it might be quite useful. Can anybody see anything wrong with this? Would either of these versions look right on a kindle? Bob Gibbins
On Feb 17, 2012, at 3:53 PM, Robert Gibbins wrote:
Can anybody see anything wrong with this? Would either of these versions look right on a kindle?
I got a Kindle yesterday as part of a promotion and did some coding for mobi last night. I believe there are at least two show-stoppers in your code. First, the Kindle cannot handle two classes together as in "no-indent verse". Second, it will not honor margin-anything. If you Google this: "Formatting poetry for EPUB and Kindle" and read what Ben Crowder wrote, you'll see some of the other limitations. In my generator, I used "text-indent" which does work on a Kindle, and "margin-left" which does work in an Epub. For HTML where I want to shrink-wrap and center a block of poetry, I use a centered div which I believe will not work in epub of mobi. I'm one day into coding for mobi but I believe this is accurate. I have to believe that Marcello has figured this all out and that the right markup is buried in epubmaker, which generates epub and mobi. Wish there were a place for best practices for both epub and mobi. --Roger
For some "hints" about the problems of poetry in (x)html, particularly as it relates to small machines, see: http://epubsecrets.com/formatting-poetry-in-epub-part-1.php http://www.pigsgourdsandwikis.com/2012/01/media-queries-for-formatting-poetr y-on.html http://ebookarchitects.com/blog/backwards-compatible-poetry-for-kf8mobi/ In general I would say most people at PG/DP are going to be pretty unhappy if you mark each line of your poems with a "<p>" because the consensus is pretty much we really really want <p> to mean a paragraph. In general the "poetry problem" consists of the following problems: * you would like a relatively clean, simple, readable, maintainable markup scheme. * that scheme should "correctly" label parts of poetry to the extent that it marks them up at all. * you would like not to have to put in extra "hacky" bits. * you would like the poetry to do an appropriate poetry wrap-indent on small machines. * you would like lines that are indented in the original (which are not simply wrap line in the original) to be indented like the original. * you would like a font that is indicative of poetry and not a hack monospace font for example. * you would like it to work with the limitations of epub * you would like it to work with the limitations of kf8 And *you would like it to work with the limitations of mobi I haven't seen a "poetry scheme" yet that meets all these criteria. The ones that come close use negative margins, but I have seen negative margins fail spectacular on epub machines that support margin trimming. What I have done personally so far is just punt and not bother to do the poetry wrap-indent, in which case say a blockquote with explicit <br> on line ends and some is "sufficient." If you want to do poetry wrap-indents and are willing to break badly on epub machines with margin trimming turned on then the common PG/DP approach which I think is being generated by guiguts is not bad: ======= <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> <title>The Project Gutenberg eBook of Limericks</title> <style type="text/css"> .poem {margin-left:10%; margin-right:10%; text-align: left;} .poem br {display: none;} .poem .stanza {margin: 1em 0em 1em 0em;} .poem span.i0 {display: block; margin-left: 0em; padding-left: 3em; text-indent: -3em;} .poem span.i2 {display: block; margin-left: 1em; padding-left: 3em; text-indent: -3em;} .poem span.i4 {display: block; margin-left: 2em; padding-left: 3em; text-indent: -3em;} </style> </head> <body> <div class="poem"> <div class="stanza"> <span class="i0">There was a young man of St. Kitts,<br /></span> <span class="i0">Who was very much troubled with fits;<br /></span> <span class="i2"> The eclipse of the moon<br /></span> <span class="i2"> Threw him into a swoon;<br /></span> <span class="i0">Where he tumbed and broke into bits.<br /></span> </div> </div> </body> </html> ====== Note to imply that I agree with the particular margin settings being used! Note unfortunately the kindles require the gratuitous <br /> Where I have put a copy of this up at http://freekindlebooks.org/Dev/poem.html and http://freekindlebooks.org/Dev/poem.mobi (kf8 + mobi7) Scrunch an html browser to a very narrow window, or set a Kindle to a very large font to force a "poetry wrap-indent" This code "works" on IE, ADE epub, and Kindle Fire (KF8) and "works but somewhat degraded" on Firefox and Kindle mobi7 versions. But again may break spectacular on epub devices with margin trimming set.
Is "white-space pre" usable? On Fri, Feb 17, 2012 at 3:06 PM, James Adcock <jimad@msn.com> wrote:
For some "hints" about the problems of poetry in (x)html, particularly as it relates to small machines, see:
http://epubsecrets.com/formatting-poetry-in-epub-part-1.php
http://www.pigsgourdsandwikis.com/2012/01/media-queries-for-formatting-poetr y-on.html http://ebookarchitects.com/blog/backwards-compatible-poetry-for-kf8mobi/
In general I would say most people at PG/DP are going to be pretty unhappy if you mark each line of your poems with a "<p>" because the consensus is pretty much we really really want <p> to mean a paragraph.
In general the "poetry problem" consists of the following problems:
* you would like a relatively clean, simple, readable, maintainable markup scheme. * that scheme should "correctly" label parts of poetry to the extent that it marks them up at all. * you would like not to have to put in extra "hacky" bits. * you would like the poetry to do an appropriate poetry wrap-indent on small machines. * you would like lines that are indented in the original (which are not simply wrap line in the original) to be indented like the original. * you would like a font that is indicative of poetry and not a hack monospace font for example. * you would like it to work with the limitations of epub * you would like it to work with the limitations of kf8 And *you would like it to work with the limitations of mobi
I haven't seen a "poetry scheme" yet that meets all these criteria. The ones that come close use negative margins, but I have seen negative margins fail spectacular on epub machines that support margin trimming. What I have done personally so far is just punt and not bother to do the poetry wrap-indent, in which case say a blockquote with explicit <br> on line ends and some is "sufficient."
If you want to do poetry wrap-indents and are willing to break badly on epub machines with margin trimming turned on then the common PG/DP approach which I think is being generated by guiguts is not bad:
=======
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> <title>The Project Gutenberg eBook of Limericks</title> <style type="text/css">
.poem {margin-left:10%; margin-right:10%; text-align: left;} .poem br {display: none;} .poem .stanza {margin: 1em 0em 1em 0em;} .poem span.i0 {display: block; margin-left: 0em; padding-left: 3em; text-indent: -3em;} .poem span.i2 {display: block; margin-left: 1em; padding-left: 3em; text-indent: -3em;} .poem span.i4 {display: block; margin-left: 2em; padding-left: 3em; text-indent: -3em;} </style> </head> <body>
<div class="poem"> <div class="stanza"> <span class="i0">There was a young man of St. Kitts,<br /></span> <span class="i0">Who was very much troubled with fits;<br /></span> <span class="i2"> The eclipse of the moon<br /></span> <span class="i2"> Threw him into a swoon;<br /></span> <span class="i0">Where he tumbed and broke into bits.<br /></span> </div> </div>
</body> </html>
======
Note to imply that I agree with the particular margin settings being used!
Note unfortunately the kindles require the gratuitous <br />
Where I have put a copy of this up at http://freekindlebooks.org/Dev/poem.html and http://freekindlebooks.org/Dev/poem.mobi (kf8 + mobi7)
Scrunch an html browser to a very narrow window, or set a Kindle to a very large font to force a "poetry wrap-indent"
This code "works" on IE, ADE epub, and Kindle Fire (KF8) and "works but somewhat degraded" on Firefox and Kindle mobi7 versions. But again may break spectacular on epub devices with margin trimming set.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
Is "white-space pre" usable? <pre> implies the use of an ugly courier-like fixed pitch "monospace" font. You don't want to get into the business of trying to set font-families IMHO because well frankly it will never work. Desktop machines can't even agree on fonts, and small machines have a less-than zero overlap in what they will accept for font-families. And even IE breaks horrible on something as simple as "monospace" So, I think people at DP/PG have pretty much universally stayed away from setting font-families, which leaves <pre> tied to monospace, which, no, is not usable for poetry, unless the poetry is about 1970s teletype machines, or something -- see #24353 Even the simplest attempts to set font-family on the Klassic Kindles fails spectacular.
You lost me at your first assumption. I use it and seldom with monospace fonts. And then not because I'm using some white-space setting but because it fits the context. On Fri, Feb 17, 2012 at 3:49 PM, James Adcock <jimad@msn.com> wrote:
** **
Is "white-space pre" usable?****
<pre> implies the use of an ugly courier-like fixed pitch “monospace” font. ****
** **
You don’t want to get into the business of trying to set font-families IMHO because well frankly it will never work. Desktop machines can’t even agree on fonts, and small machines have a less-than zero overlap in what they will accept for font-families. And even IE breaks horrible on something as simple as “monospace”****
** **
So, I think people at DP/PG have pretty much universally stayed away from setting font-families, which leaves <pre> tied to monospace, which, no, is not usable for poetry, unless the poetry is about 1970s teletype machines, or something -- see #24353 ****
** **
Even the simplest attempts to set font-family on the Klassic Kindles fails spectacular.****
** **
** **
** **
** **
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
There are two examples of possibly legitimate markup for poems at eb.readingroo.ms in wordpress context, duplicated at eb.readingroo.ms/dt.html and eb.readingroo.ms/canto.html in the rawest possible form (just view source in your browser.) They both use completely un-marked-up text (zero markup) as sources. Feedback please - I'm working out a poetry strategy too. Don On Fri, Feb 17, 2012 at 7:52 PM, don kretz <dakretz@gmail.com> wrote:
You lost me at your first assumption. I use it and seldom with monospace fonts. And then not because I'm using some white-space setting but because it fits the context.
On Fri, Feb 17, 2012 at 3:49 PM, James Adcock <jimad@msn.com> wrote:
** **
Is "white-space pre" usable?****
<pre> implies the use of an ugly courier-like fixed pitch “monospace” font.****
** **
You don’t want to get into the business of trying to set font-families IMHO because well frankly it will never work. Desktop machines can’t even agree on fonts, and small machines have a less-than zero overlap in what they will accept for font-families. And even IE breaks horrible on something as simple as “monospace”****
** **
So, I think people at DP/PG have pretty much universally stayed away from setting font-families, which leaves <pre> tied to monospace, which, no, is not usable for poetry, unless the poetry is about 1970s teletype machines, or something -- see #24353 ****
** **
Even the simplest attempts to set font-family on the Klassic Kindles fails spectacular.****
** **
** **
** **
** **
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
On 2/18/2012 1:22 PM, don kretz wrote:
There are two examples of possibly legitimate markup for poems at eb.readingroo.ms <http://eb.readingroo.ms> in wordpress context, duplicated at eb.readingroo.ms/dt.html <http://eb.readingroo.ms/dt.html and eb.readingroo.ms/canto.html <http://eb.readingroo.ms/canto.html in thrawest possible form (just view source in your browser.)
They both use completely un-marked-up text (zero markup) as sources.
Feedback please - I'm working out a poetry strategy too.
FWIW, I don't like the presentation at all -- but that is a result of your style sheets, not your markup -- which is, in fact, non-existent. /My/ most fundamental rule for markup is that a document must look acceptable on a device that cannot handle CSS. On this count, your proposed formulation fails spectacularly. In spite of Mr. Adcock's objections, I think that for poetry the <pre> element is exactly what is called for (and this is the opinion of the W3C as well; see http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#edef-PRE). <pre> is a block-level element, which means that it can be a direct replacement for a <div> element. And even though "[a]uthors are discouraged from altering this behavior through style sheets," it is certainly possible to do so. So, rather than marking a poem as <div class="poem | poetry"> I recommend marking it as <pre class="poem | poetry">. In a user agent that respects style sheets you can override the default 'pre' presentation just as easily as you could if you were using the <div> element, but on older user agents (such as the "Kindle Klassic") the text would gracefully degrade to something at least acceptable, even if not very satisfying. Other comments: While a verse or stanza in a poem is certainly analogous to a paragraph, it is nonetheless not one. You should use <div class="stanza"> for that purpose, not <div class="poem"><p>. I don't understand why you would use a horizontal rule in a poem as "a hard return" (whatever that means). Personally, I like short, centered horizontal rules as dingbats, but seeing a horizontal rule in a poem is jarring. Additionally, the old MobiPocket Reader (and presumably the old Kindles, although I can't say for sure) co-opted the horizontal rule to mean a page break, so poetry in that context could be broken up in very strange ways. Other than that, I think your style sheet is largely irrelevant; it is almost certain that I will replace your preferred styles with my own. Markup, even for poetry, needs to be designed in such a way that it tolerates swapping styles. Therefore, the focus needs to be on the actual markup, and not the associated style sheet.
Actually the markup I would use internally would be <poem> ... ... </poem> which would map whichever of your options would be appropriate for the device. I'm increasingly convinced that using markup that is associated with a specific device (or devices) leads to ambiguity and confusion. Worse is <div class="something"> if it's true as you say that some devices won't handle css at all. <p> is troublesome as well, because it's frequently used without regard to whether what is being marked is, in fact, a paragraph; and <p> has constraints that are specific to itself that create limitations - most troublesome to me is the inability to embed images other than inline, so <p> won't flow around an image in the middle like a <div> will. Or a <poem> for that matter. On Sun, Feb 19, 2012 at 1:25 PM, Lee Passey <lee@novomail.net> wrote:
On 2/18/2012 1:22 PM, don kretz wrote:
There are two examples of possibly legitimate markup for poems at
eb.readingroo.ms <http://eb.readingroo.ms> in wordpress context, duplicated at eb.readingroo.ms/dt.html <http://eb.readingroo.ms/dt.**html<http://eb.readingroo.ms/dt.html> and eb.readingroo.ms/canto.html <http://eb.readingroo.ms/**canto.html<http://eb.readingroo.ms/canto.html> in thrawest possible form (just view source in your browser.)
They both use completely un-marked-up text (zero markup) as sources.
Feedback please - I'm working out a poetry strategy too.
FWIW, I don't like the presentation at all -- but that is a result of your style sheets, not your markup -- which is, in fact, non-existent.
/My/ most fundamental rule for markup is that a document must look acceptable on a device that cannot handle CSS. On this count, your proposed formulation fails spectacularly.
In spite of Mr. Adcock's objections, I think that for poetry the <pre> element is exactly what is called for (and this is the opinion of the W3C as well; see http://www.w3.org/TR/1999/REC-**html401-19991224/struct/text. **html#edef-PRE<http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#edef-PRE>). <pre> is a block-level element, which means that it can be a direct replacement for a <div> element. And even though "[a]uthors are discouraged from altering this behavior through style sheets," it is certainly possible to do so.
So, rather than marking a poem as <div class="poem | poetry"> I recommend marking it as <pre class="poem | poetry">. In a user agent that respects style sheets you can override the default 'pre' presentation just as easily as you could if you were using the <div> element, but on older user agents (such as the "Kindle Klassic") the text would gracefully degrade to something at least acceptable, even if not very satisfying.
Other comments:
While a verse or stanza in a poem is certainly analogous to a paragraph, it is nonetheless not one. You should use <div class="stanza"> for that purpose, not <div class="poem"><p>.
I don't understand why you would use a horizontal rule in a poem as "a hard return" (whatever that means). Personally, I like short, centered horizontal rules as dingbats, but seeing a horizontal rule in a poem is jarring. Additionally, the old MobiPocket Reader (and presumably the old Kindles, although I can't say for sure) co-opted the horizontal rule to mean a page break, so poetry in that context could be broken up in very strange ways.
Other than that, I think your style sheet is largely irrelevant; it is almost certain that I will replace your preferred styles with my own. Markup, even for poetry, needs to be designed in such a way that it tolerates swapping styles. Therefore, the focus needs to be on the actual markup, and not the associated style sheet.
______________________________**_________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/**mailman/listinfo/gutvol-d<http://lists.pglaf.org/mailman/listinfo/gutvol-d>
Note that my original question was about "white-space: pre" (and meaning to imply "pre-wrap" as well), not <pre>. Not sure what your question about the <hr> question refers to ... On Sun, Feb 19, 2012 at 1:45 PM, don kretz <dakretz@gmail.com> wrote:
Actually the markup I would use internally would be
<poem> ... ... </poem>
which would map whichever of your options would be appropriate for the device. I'm increasingly convinced that using markup that is associated with a specific device (or devices) leads to ambiguity and confusion. Worse is <div class="something"> if it's true as you say that some devices won't handle css at all.
<p> is troublesome as well, because it's frequently used without regard to whether what is being marked is, in fact, a paragraph; and <p> has constraints that are specific to itself that create limitations - most troublesome to me is the inability to embed images other than inline, so <p> won't flow around an image in the middle like a <div> will.
Or a <poem> for that matter.
On Sun, Feb 19, 2012 at 1:25 PM, Lee Passey <lee@novomail.net> wrote:
On 2/18/2012 1:22 PM, don kretz wrote:
There are two examples of possibly legitimate markup for poems at
eb.readingroo.ms <http://eb.readingroo.ms> in wordpress context, duplicated at eb.readingroo.ms/dt.html <http://eb.readingroo.ms/dt.** html <http://eb.readingroo.ms/dt.html> and eb.readingroo.ms/canto.html <http://eb.readingroo.ms/**canto.html<http://eb.readingroo.ms/canto.html> in thrawest possible form (just view source in your browser.)
They both use completely un-marked-up text (zero markup) as sources.
Feedback please - I'm working out a poetry strategy too.
FWIW, I don't like the presentation at all -- but that is a result of your style sheets, not your markup -- which is, in fact, non-existent.
/My/ most fundamental rule for markup is that a document must look acceptable on a device that cannot handle CSS. On this count, your proposed formulation fails spectacularly.
In spite of Mr. Adcock's objections, I think that for poetry the <pre> element is exactly what is called for (and this is the opinion of the W3C as well; see http://www.w3.org/TR/1999/REC-** html401-19991224/struct/text.**html#edef-PRE<http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#edef-PRE>). <pre> is a block-level element, which means that it can be a direct replacement for a <div> element. And even though "[a]uthors are discouraged from altering this behavior through style sheets," it is certainly possible to do so.
So, rather than marking a poem as <div class="poem | poetry"> I recommend marking it as <pre class="poem | poetry">. In a user agent that respects style sheets you can override the default 'pre' presentation just as easily as you could if you were using the <div> element, but on older user agents (such as the "Kindle Klassic") the text would gracefully degrade to something at least acceptable, even if not very satisfying.
Other comments:
While a verse or stanza in a poem is certainly analogous to a paragraph, it is nonetheless not one. You should use <div class="stanza"> for that purpose, not <div class="poem"><p>.
I don't understand why you would use a horizontal rule in a poem as "a hard return" (whatever that means). Personally, I like short, centered horizontal rules as dingbats, but seeing a horizontal rule in a poem is jarring. Additionally, the old MobiPocket Reader (and presumably the old Kindles, although I can't say for sure) co-opted the horizontal rule to mean a page break, so poetry in that context could be broken up in very strange ways.
Other than that, I think your style sheet is largely irrelevant; it is almost certain that I will replace your preferred styles with my own. Markup, even for poetry, needs to be designed in such a way that it tolerates swapping styles. Therefore, the focus needs to be on the actual markup, and not the associated style sheet.
______________________________**_________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/**mailman/listinfo/gutvol-d<http://lists.pglaf.org/mailman/listinfo/gutvol-d>
On 2/19/2012 2:50 PM, don kretz wrote:
Note that my original question was about "white-space: pre" (and meaning to imply "pre-wrap" as well), not <pre>.
Just as I pointed out to Mr. Adcock.
Not sure what your question about the <hr> question refers to ...
Your style sheet contains: /* A hard return in a poem. */ div.poem hr { border-color: #445570; margin: 0.250em 0.000em; } I do note that you never actually /used/ this construct in the sample poem, but its existence in the style sheet indicates that it /might/ be used in the future.
The style sheet just came with the text from the referenced article. It was an interesting example of no-markup poetry so I just grabbed the whole thing. After seeing what some people do to a poem for markup and the mixed results, it seems to me that one approach would be to mark it up as little as possible (in the case of this example, just the container with the pre-wrap style) and find out if that works. The more you add, the more the user-agent needs to get right to give you the desired result - so see how little you can get by with. On Sun, Feb 19, 2012 at 2:24 PM, Lee Passey <lee@novomail.net> wrote:
On 2/19/2012 2:50 PM, don kretz wrote:
Note that my original question was about "white-space: pre" (and meaning
to imply "pre-wrap" as well), not <pre>.
Just as I pointed out to Mr. Adcock.
Not sure what your question about the <hr> question refers to ...
Your style sheet contains:
/* A hard return in a poem. */ div.poem hr { border-color: #445570; margin: 0.250em 0.000em; }
I do note that you never actually /used/ this construct in the sample poem, but its existence in the style sheet indicates that it /might/ be used in the future.
______________________________**_________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/**mailman/listinfo/gutvol-d<http://lists.pglaf.org/mailman/listinfo/gutvol-d>
Sorry, but either this "conversation" is spinning out of control, or we are living on different planets. *My* planet is one inhabited by people reading on small machines, including epub and mobi devices. When I make comments about poetry, it is about how people actually reading on those machines, actually experiencing poetry, when read by their very own eyes. When I say something "doesn't work" I mean that what I understand someone on this forum is proposing I or other have tried experimentally, and we find that it shows up as "scrambled eggs" on small epub and mobi devices. Now if all you have ever worked on is 20" monitors attached to desktop machines you may have a hard time understanding this other planet. Again, suggest you actually try what you are proposing on small epub and mobi machines and see what happens. It is not hard to perform such an experiment. Install Amazon's "Kindle Previewer Version 2" http://www.amazon.com/gp/feature.html?ie=UTF8&docId=1000234621 And then feed your HTML page to that Previewer. The Kindle Previewer is a software emulator for a variety of Amazon epub/mobi devices. If you switch Previewer to emulate "Kindle Fire" you will see results similar to what you would see on an epub device. If you switch Previewer to emulate "Kindle" then you will see results similar to what you would see on a Klassic Kindle mobi device. Presumably some people who try this experiment will now blame Amazon when they find that their code doesn't work in practice. Its not Amazon, its your choice of coding. You can try that coding on a variety of other epub devices and again you will find that your code doesn't work. When I say something "works" or "doesn't work" what do I mean? I mean something "works" when a user can read that poetry on their machine and it "looks" like valid poetry formatted as-if one were reading poetry in a paper book about poetry. I say something "doesn't work" if it comes out scrambled so that it doesn't look like valid poetry formatted in a paper book about poetry. I also say something "doesn't work" if some or all of the poem is simply unreadable on the end users machine, or if they have to perform some kind of strange contortions on their machine to get it readable. In turn this all means that a "poetry scheme" needs to understand the issue of line wrapping and specifically how line wrapping applies to poetry. And it needs to understand the issue of fonts and font families (and why they don't work) Again, there are authors who "get" these issues, people who actually write books for small machines and about small machines. See the writings of Elizabeth Castro, Rufus Deuchler, and Joshua Tallent for example.
HI Lee, Your continuous references to reading devices is interesting. It shows one very important point that the HTML-standard is not well implemented or not fully implemented on such devices. What it does show is that using complex style of mark-up (semantic mark-up) is a very bad idea! Inorder to achieve a better visual presentation it would be more appropriate to use just <p>. I know this is disconcerting to you. Yet, as far as visual layout is concerned it is actually all that is needed. Agreed that source looks ugly, and is not easy to read, but it will do the trick! I believe you were around during the browser wars, were you could write beautiful HTML for one browser, yet on another all you had was junk! Well, we have the same situation with the reading devices. So, what did one do to have your pages work in different devices! You stayed basic! The same principle should apply, today, for ebooks. regards Keith. Am 19.02.2012 um 22:25 schrieb Lee Passey:
So, rather than marking a poem as <div class="poem | poetry"> I recommend marking it as <pre class="poem | poetry">. In a user agent that respects style sheets you can override the default 'pre' presentation just as easily as you could if you were using the <div> element, but on older user agents (such as the "Kindle Klassic") the text would gracefully degrade to something at least acceptable, even if not very satisfying.
Other comments:
While a verse or stanza in a poem is certainly analogous to a paragraph, it is nonetheless not one. You should use <div class="stanza"> for that purpose, not <div class="poem"><p>.
I don't understand why you would use a horizontal rule in a poem as "a hard return" (whatever that means). Personally, I like short, centered horizontal rules as dingbats, but seeing a horizontal rule in a poem is jarring. Additionally, the old MobiPocket Reader (and presumably the old Kindles, although I can't say for sure) co-opted the horizontal rule to mean a page break, so poetry in that context could be broken up in very strange ways.
Other than that, I think your style sheet is largely irrelevant; it is almost certain that I will replace your preferred styles with my own. Markup, even for poetry, needs to be designed in such a way that it tolerates swapping styles. Therefore, the focus needs to be on the actual markup, and not the associated style sheet. _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
On Fri, February 24, 2012 1:50 am, Keith J. Schultz wrote:
HI Lee,
Your continuous references to reading devices is interesting.
It shows one very important point that the HTML-standard is not well implemented or not fully implemented on such devices.
What it does show is that using complex style of mark-up (semantic mark-up) is a very bad idea!
No, it demonstrates that /relying/ on a complex style of mark-up is a very bad idea. But if you can create markup that looks good in a simple User Agent, and looks even better in a more powerful User Agent why wouldn't you do that? You don't want to make a document that looks crude even in the most powerful of environments, and you don't want to create a document that loses its formatting in a simple environment. But this is not a zero sum game -- you don't have to choose one or the other. Start with basic formatting for a User Agent that doesn't recognize CSS. Do the best job you can, recognizing that it won't be perfect. Now classify the markup (in HTML, classification involves adding 'class' attributes to elements) so that by adding a style sheet the presentation is improved. Be careful just to add class attributes, not to change any elements. What you have then is a win-win! Why would you want to penalize any group of users?
In order to achieve a better visual presentation it would be more appropriate to use just <p>.
No it is not, because paragraphs carry semantic baggage that you want to avoid. Try this experiment: Mark up a poem using <p> elements (no styles allowed). Look at the document in a browser; is it acceptable? Now look at the same poem on a User Agent that displays paragraphs indented. All good e-book readers, devices or software, will allow you to set the indentation of paragraphs: make it 50% or 25em, or some other really large value. How does your poem look now? (If you don't have a good e-book reader, you can simulate this by putting: <style type="text/css"> p { text-indent: 50% > </style> in the <head> element of your document, and then using a modern browser). Now try the same experiment again with <div> instead of <p>. How does that change the results? Yes, using basic markup is good, but you must always use markup that matches the semantics of what you're marking. And you should never disallow styles that makes the basic markup even better.
Lee>If you don't have a good e-book reader, you can simulate this by putting... Again, if you don't have an e-book reader, you can easily simulate one accurately by installing the Amazon software emulator called "Kindle Previewer Version 2" which will compile your html file (or other file formats) into kf8 format -- a format which basically contains *both* a copy of an epub document *and* a copy of a mobi document, and then allows you to see what these look like on a variety of epub-like and mobi-like devices of various styles, sizes, and shapes. www.amazon.com/kindleformat/KindlePreviewer
On 2/26/2012 3:50 PM, Jim Adcock wrote:
Lee> If you don't have a good e-book reader, you can simulate this by putting...
Again, if you don't have an e-book reader, you can easily simulate one accurately by installing the Amazon software emulator called "Kindle Previewer Version 2" ...
Likewise, you could download a /good/ e-book reader program from any number of places on the internet (the Kindle Previewer does not allow you to set indentation level for paragraphs -- which is why a browser-based work-around is useful).
Lee>Likewise, you could download a /good/ e-book reader program from any number of places on the internet (the Kindle Previewer does not allow you to set indentation level for paragraphs -- which is why a browser-based work-around is useful). Again, these arguments amount to "blame the user" -- because the great majority of PG ebook readers are simply going to use the reader software which came on their choice of machine -- which they may well have chosen for reasons other than the quality of the reader software. Again, do "we" want to write "write once read everywhere" code, or do we want to write code that only works on "the best" software -- where Lee gets to define what "the best" reader software is? Pretty easy to write "successful" HTML code *if* your only targets are Moz10 and IE9 running on 20" monitors. Please *do* download a variety of epub software from the internet, including the Kindle Previewer. It's just that it seems obvious to me looking at the submitted HTML code that most submitters are *only* checking their work on *one* web browser running on *one* large-sized monitor. Especially try your coding on Aldiko, if you happen to think that somehow epub browser are always better. Kindle Previewer is simply one simple way to get people to try their code on *something* other than a desktop browser and a 20" monitor! At least Amazon provides tools to support their product, which apparently none of the epub vendors do.
HI Lee, I believe we basically, agree that the use of "less" complex markup is the way to go. What I have come to realize is that we do have a problem about terms. what you mostly call semantic, I still put in the realm of syntax as a linguist, or better express as a computer linguist. You see poem, verse, stanza and line are first and foremost syntactic. Naturally, they carry semantic meaning in there labels. Yet, no where are these objects being used to do any "semantic" analysis of of text. I can fully understand your dislike of my approach, because the lines of a poem are not paragraphs. Yet, if I disregard the intended use of paragraphs and say that by using style/class elements I make the these paragraphs formally to lines of a poem. The user agent could care less. It just renders the markup. It is the result that matters. Or, have you not used a wrench as a hammer, a screw driver as a chisel? Sometimes, it is practical to "misuse" tools or here markup. regards Keith. Am 24.02.2012 um 20:44 schrieb Lee Passey:
On Fri, February 24, 2012 1:50 am, Keith J. Schultz wrote:
HI Lee,
Your continuous references to reading devices is interesting.
It shows one very important point that the HTML-standard is not well implemented or not fully implemented on such devices.
What it does show is that using complex style of mark-up (semantic mark-up) is a very bad idea!
No, it demonstrates that /relying/ on a complex style of mark-up is a very bad idea. But if you can create markup that looks good in a simple User Agent, and looks even better in a more powerful User Agent why wouldn't you do that?
You don't want to make a document that looks crude even in the most powerful of environments, and you don't want to create a document that loses its formatting in a simple environment. But this is not a zero sum game -- you don't have to choose one or the other. Start with basic formatting for a User Agent that doesn't recognize CSS. Do the best job you can, recognizing that it won't be perfect. Now classify the markup (in HTML, classification involves adding 'class' attributes to elements) so that by adding a style sheet the presentation is improved. Be careful just to add class attributes, not to change any elements.
What you have then is a win-win! Why would you want to penalize any group of users?
In order to achieve a better visual presentation it would be more appropriate to use just <p>.
No it is not, because paragraphs carry semantic baggage that you want to avoid.
Try this experiment:
Mark up a poem using <p> elements (no styles allowed). Look at the document in a browser; is it acceptable?
Now look at the same poem on a User Agent that displays paragraphs indented. All good e-book readers, devices or software, will allow you to set the indentation of paragraphs: make it 50% or 25em, or some other really large value. How does your poem look now?
(If you don't have a good e-book reader, you can simulate this by putting:
<style type="text/css"> p { text-indent: 50% > </style>
in the <head> element of your document, and then using a modern browser).
Now try the same experiment again with <div> instead of <p>. How does that change the results?
Yes, using basic markup is good, but you must always use markup that matches the semantics of what you're marking. And you should never disallow styles that makes the basic markup even better.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
On Mon, February 27, 2012 1:19 am, Keith J. Schultz wrote:
HI Lee,
I believe we basically, agree that the use of "less" complex markup is the way to go.
No, I don't think so. I believe, as Albert Einstein suggested, that everything should be made as simple as possible, /but no simpler/. If it makes sense to mark every line of poetry with <line> or <div class="line"> or <span class="line"> then I think it should be done. The fact that some user agents may not be able to deal with the markup is no excuse not to include it for other user agents. The goal should be first to maximize textual richness, and secondarily to simplify markup. Gratuitous markup should be avoided, but significant markup should be included.
What I have come to realize is that we do have a problem about terms. what you mostly call semantic, I still put in the realm of syntax as a linguist, or better express as a computer linguist.
Semantics is the study of meaning, and linguistic semantics is the study of meaning that is used to understand human expression through language. As such, lexicology, syntax and etymology can all be said to be part of semantics. The opposite of semantics is not syntax, but...well, I don't know what you would call it; abstract representationalism maybe? A word is a word is a word; whether you call it /wort/ or /mot/ or /palabra/ or 119 110 114 100 the meaning does not change. This is semantics. On the other hand, if I draw a random glyph on a canvas at a specific point, and different random glyph on the canvas immediately to its right, and yet another random glyph on the canvas again to the right that sequence of glyphs, in and of themselves, have no meaning. This is presentation.
You see poem, verse, stanza and line are first and foremost syntactic. Naturally, they carry semantic meaning in there labels. Yet, no where are these objects being used to do any "semantic" analysis of of text.
Well, at the very least semantic analysis is being performed when a human reader views the text. But in almost every user agent semantic analysis is being done as well. The perfect example of this is the much-discussed paragraph. I would argue that the concept of a paragraph is a semantic concept, not a presentational one. Now every good user agent available has the ability to allow the user to specify how a paragraph should be rendered (indented, degree of indentation, line spacing before, line spacing after, etc.). The only way that a user agent can satisfy those requirements is to do a semantic analysis of the file; and because computers are still far behind the human brain in their capacity to do semantic analysis, they /have/ to rely on explicit markup indicating the semantic meaning.
I can fully understand your dislike of my approach, because the lines of a poem are not paragraphs.
Precisely. And when you tell a user agent that they are, you are lying to the poor computer, and confusing it.
Yet, if I disregard the intended use of paragraphs and say that by using style/class elements I make the these paragraphs formally to lines of a poem.
You didn't do the experiment, did you? What if you're user agent is too unsophisticated to understand CSS? What if you have a human user that replaces your CSS, relying on the notion that you won't lie about the semantic meaning of well-established markup?
The user agent could care less. It just renders the markup.
Sure. Computers are literal, and will not second-guess the instructions they are given. But is your e-text a work with linguistic meaning, or is it paint-by-numbers instructions on how to create a graphic image?
It is the result that matters. Or, have you not used a wrench as a hammer, a screw driver as a chisel? Sometimes, it is practical to "misuse" tools or here markup.
I'm nothing if not a pragmatist. Sometimes a man's got to do what a man's got to do. But be wary of treating every problem as a nail just because the only tool you're familiar with is a hammer. In the case of poetry, not only is there a better way, but that way has /no/ downside. Learn the rules, so you know how to break them properly.
Hi Lee, I do not where you are getting your definitions from. Yet, my assumption is that you are not a linguist. What you put in the realm of semantics is actually linguistics in general. The fields are interrelated. I believe this is the wrong forum to take this all apart and clarify your misconceptions of the subject matter of linguistics and grammar. I you are truly interested we can e-mail off list. regards Keith. Am 27.02.2012 um 19:01 schrieb Lee Passey:
On Mon, February 27, 2012 1:19 am, Keith J. Schultz wrote:
HI Lee,
I believe we basically, agree that the use of "less" complex markup is the way to go.
No, I don't think so. I believe, as Albert Einstein suggested, that everything should be made as simple as possible, /but no simpler/. If it makes sense to mark every line of poetry with <line> or <div class="line"> or <span class="line"> then I think it should be done. The fact that some user agents may not be able to deal with the markup is no excuse not to include it for other user agents. The goal should be first to maximize textual richness, and secondarily to simplify markup. Gratuitous markup should be avoided, but significant markup should be included.
What I have come to realize is that we do have a problem about terms. what you mostly call semantic, I still put in the realm of syntax as a linguist, or better express as a computer linguist.
Semantics is the study of meaning, and linguistic semantics is the study of meaning that is used to understand human expression through language. As such, lexicology, syntax and etymology can all be said to be part of semantics.
The opposite of semantics is not syntax, but...well, I don't know what you would call it; abstract representationalism maybe?
A word is a word is a word; whether you call it /wort/ or /mot/ or /palabra/ or 119 110 114 100 the meaning does not change. This is semantics. On the other hand, if I draw a random glyph on a canvas at a specific point, and different random glyph on the canvas immediately to its right, and yet another random glyph on the canvas again to the right that sequence of glyphs, in and of themselves, have no meaning. This is presentation.
You see poem, verse, stanza and line are first and foremost syntactic. Naturally, they carry semantic meaning in there labels. Yet, no where are these objects being used to do any "semantic" analysis of of text.
Well, at the very least semantic analysis is being performed when a human reader views the text. But in almost every user agent semantic analysis is being done as well. The perfect example of this is the much-discussed paragraph.
I would argue that the concept of a paragraph is a semantic concept, not a presentational one. Now every good user agent available has the ability to allow the user to specify how a paragraph should be rendered (indented, degree of indentation, line spacing before, line spacing after, etc.). The only way that a user agent can satisfy those requirements is to do a semantic analysis of the file; and because computers are still far behind the human brain in their capacity to do semantic analysis, they /have/ to rely on explicit markup indicating the semantic meaning.
I can fully understand your dislike of my approach, because the lines of a poem are not paragraphs.
Precisely. And when you tell a user agent that they are, you are lying to the poor computer, and confusing it.
Yet, if I disregard the intended use of paragraphs and say that by using style/class elements I make the these paragraphs formally to lines of a poem.
You didn't do the experiment, did you?
What if you're user agent is too unsophisticated to understand CSS? What if you have a human user that replaces your CSS, relying on the notion that you won't lie about the semantic meaning of well-established markup?
The user agent could care less. It just renders the markup.
Sure. Computers are literal, and will not second-guess the instructions they are given. But is your e-text a work with linguistic meaning, or is it paint-by-numbers instructions on how to create a graphic image?
It is the result that matters. Or, have you not used a wrench as a hammer, a screw driver as a chisel? Sometimes, it is practical to "misuse" tools or here markup.
I'm nothing if not a pragmatist. Sometimes a man's got to do what a man's got to do. But be wary of treating every problem as a nail just because the only tool you're familiar with is a hammer. In the case of poetry, not only is there a better way, but that way has /no/ downside.
Learn the rules, so you know how to break them properly.
[sorry, been out of town] Don>Is "white-space pre" usable? Jim><pre> implies the use of an ugly courier-like fixed pitch "monospace" font. Don>You lost me at your first assumption. I use it and seldom with monospace fonts. And then not because I'm using some white-space setting but because it fits the context. Not sure what you are doing but if you look up the definition of "<pre>" you will find that it switches HTML away from the default normal font to the default monospace font. If you don't want the default monospace font then you have to specify what font you do want. However, in HTML with EPUB and MOBI there is no reliable way to specify fonts that works with all the target platforms. Thus, I think if you explore PG HTML code you will find that people reliably do not specify fonts. They just use the provided defaults. But the default font associated with <pre> is the default monospace font, which is inappropriate for poetry -- unless perhaps you are coding Archy and Mehitabel -- but I have been unable to find a PD source for that one! Conclusion: No, <pre> doesn't work for poetry. Primarily because of the monospace font issue, but also because it doesn't do poetry wraps.
On 2/17/2012 4:49 PM, James Adcock wrote:
Is "white-space pre" usable?
<pre> implies the use of an ugly courier-like fixed pitch “monospace” font.
Again, two different conversations. <pre> is an HTML tag. According to the specification, <blockquote> The PRE element tells visual user agents that the enclosed text is "preformatted". When handling preformatted text, visual user agents: * May leave white space intact. * May render text with a fixed-pitch font. * May disable automatic word wrap. ... [It] is intended to preserve constant line spacing and column alignment for text rendered in a fixed pitch font. Authors are discouraged from altering this behavior through style sheets. </blockquote> I find it interesting that the W3C uses the word "may" in the specification as opposed to "should" or "must." I'm not aware of any user agent that violates this expectations, but the wording is nonetheless interesting. -------------- 'white-space' is a CSS property. The 'pre' value, "prevents user agents from collapsing sequences of white space. Lines are only broken at preserved newline characters." Text marked with 'white-space:pre' will not have multiple runs of spaces collapsed, which allows multiple levels of indentation at the beginning of lines, and will not wrap text except where there is an explicit newline character (0x10). 'white-space:pre' has no implication as to font face or pitch. Furthermore, I suspect that it would have no impact at all on the "Klassic Kindle," as .mobi does not have /any/ support for style sheets, and I'm not certain how KindleGen would transform it into HTML 3.2.
participants (7)
-
don kretz -
James Adcock -
Jim Adcock
-
Keith J. Schultz -
Lee Passey -
Robert Gibbins -
Roger Frank