Here's an update on my "zero markup" experiment. The idea was to create a document in UTF-8 text with no markup. A program then "sees" what a human would see: poetry blocks, epigraphs, block quotes, footnotes, etc. and render the other-than-text output accordingly. I wrote enough code to produce three books that are currently in smoothreading at DP. The goal was to make something that would be very easy for post-processors to use, especially at DP where the backlog is significant. I'm not claiming success on this one, though it does work. For one thing, the plain text cannot represent things like font size changes. Having the title line in a larger font on the title page is an example where that would make a visible and welcomed difference. The zml approach, taken purely, will have no "rend" attribute on an element. I allow the user to add presentation hints to any line that is centered, but it feels like I'm breaking the rules. There are other complications. As it's written, it generates valid and attractive HTML and the text can go up as well to PG without modification. But I suspect the HTML wouldn't make it through the PG ebook chain that creates the .epub and .mobi files. I cannot make any single HTML that is correct as input to both epub and mobi generators without resorting to a very low common denominator (such as nbsp's for poetry). I could have the generator make 3 separate files to be used for HTML and as inputs to epub and mobi generators. But PG understandably won't take that nor will they take actual .epub or .mobi files, also for good reasons. My choices are (1) abandon this and use RST for what's going to PG, or (2) find out what HTML will make it through PGs epub and mobi creating software so it doesn't fall out and use the text version instead. DP has a project underway to define the HTML subset that makes (2) work, which is very important to their PPers, most of which will not use PG-RST. PG-RST also isn't a good solution to produce books for other-than-PG repositories, such as for PG Canada. Bottom line: I have written a generator that takes a UTF-8 PG-submittable text and generates HTML--but that HTML is good, right now, only on a browser and not as a suitable input for any ebook-reader generators. I don't know where I'm going with this from here, if anywhere. --Roger
Do you have a demo page I could look at? On Feb 17, 2012 1:13 PM, "Roger Frank" <rfrank@rfrank.net> wrote:
Here's an update on my "zero markup" experiment. The idea was to create a document in UTF-8 text with no markup. A program then "sees" what a human would see: poetry blocks, epigraphs, block quotes, footnotes, etc. and render the other-than-text output accordingly. I wrote enough code to produce three books that are currently in smoothreading at DP. The goal was to make something that would be very easy for post-processors to use, especially at DP where the backlog is significant.
I'm not claiming success on this one, though it does work. For one thing, the plain text cannot represent things like font size changes. Having the title line in a larger font on the title page is an example where that would make a visible and welcomed difference. The zml approach, taken purely, will have no "rend" attribute on an element. I allow the user to add presentation hints to any line that is centered, but it feels like I'm breaking the rules.
There are other complications. As it's written, it generates valid and attractive HTML and the text can go up as well to PG without modification. But I suspect the HTML wouldn't make it through the PG ebook chain that creates the .epub and .mobi files. I cannot make any single HTML that is correct as input to both epub and mobi generators without resorting to a very low common denominator (such as nbsp's for poetry).
I could have the generator make 3 separate files to be used for HTML and as inputs to epub and mobi generators. But PG understandably won't take that nor will they take actual .epub or .mobi files, also for good reasons. My choices are (1) abandon this and use RST for what's going to PG, or (2) find out what HTML will make it through PGs epub and mobi creating software so it doesn't fall out and use the text version instead. DP has a project underway to define the HTML subset that makes (2) work, which is very important to their PPers, most of which will not use PG-RST. PG-RST also isn't a good solution to produce books for other-than-PG repositories, such as for PG Canada.
Bottom line: I have written a generator that takes a UTF-8 PG-submittable text and generates HTML--but that HTML is good, right now, only on a browser and not as a suitable input for any ebook-reader generators. I don't know where I'm going with this from here, if anywhere.
--Roger
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
On Feb 17, 2012, at 2:13 PM, Alex Buie wrote:
Do you have a demo page I could look at?
Sure. The HTML is here: http://dl.dropbox.com/u/12322400/t/north-h.html And the UTF-8 is here: http://dl.dropbox.com/u/12322400/t/north-u.txt The source for this text is here: http://dl.dropbox.com/u/12322400/t/north.src which is exactly the same as the UTF-8 but with the eye-candy addition of presentation markup on lines that are centered. I can send you the Python 3 source for the generator if you want to play with it. The presentation markup is "f" for font size ([f4] is font-size 1.4em, for example). "T" and "b" is for top and bottom margins, etc. It is entirely optional. --Roger
http://dl.dropbox.com/u/12322400/t/north-h.html Well, ideally you are not relying on epubmaker unless you have to. Assuming that you are not trying to rely on epubmaker, than try generating your html through kindlegen version 2, or equivalently just open your html in Kindle Previewer Version 2 (which causes the generation). You will see that what you are generating works pretty well in "Klassic Kindles" (Mobi7) but it fails due to too large margins when opened in Kindle Fire(KF8) (as emulated in Kindle Previewer Version 2 for example). Klassic Kindles ignore the margin requests, so for them it is not a problem. Epub devices, and KF8 do honour margin setting requests, so they often get killed by html code which set margins (for large screen devices) - and so Marcello kills margin settings in epubmaker, if I remember right - at least in body statements. Also, kindlegen doesn't like dual inheritance at least when generating mobi7, as I think Marcello can tell you based on hard experience. Still, not bad, in that you are willing to live with device defaults rather than trying to force you will on the devices "everywhere gratuitously."
I absolutely love it. Would you send me a copy of the source? Alex On Fri, Feb 17, 2012 at 4:40 PM, Roger Frank <rfrank@rfrank.net> wrote:
On Feb 17, 2012, at 2:13 PM, Alex Buie wrote:
Do you have a demo page I could look at?
Sure. The HTML is here: http://dl.dropbox.com/u/12322400/t/north-h.html And the UTF-8 is here: http://dl.dropbox.com/u/12322400/t/north-u.txt The source for this text is here: http://dl.dropbox.com/u/12322400/t/north.src which is exactly the same as the UTF-8 but with the eye-candy addition of presentation markup on lines that are centered.
I can send you the Python 3 source for the generator if you want to play with it.
The presentation markup is "f" for font size ([f4] is font-size 1.4em, for example). "T" and "b" is for top and bottom margins, etc. It is entirely optional.
--Roger
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
Cut and paste, with only a white-space: pre-wrap div around it (plus the wordpress overhead): http://eb.readingroo.ms/ Here is the same thing raw so you can squash it. eb.readingroo.ms/canto.html Seems like you still have all the options for indenting etc. with css.
Don>http://eb.readingroo.ms/ Doesn't do poetry wraps at all, in fact doesn't do wraps at all, and specifying long lists of fonts does in practice little or nothing (or actually works negatively) towards getting a workable font actually displayed on the great range of targets systems PG targets using HTML to also target EPUB and MOBI machines.
participants (5)
-
Alex Buie -
don kretz -
James Adcock -
Jim Adcock
-
Roger Frank