html formatting question

[Nate the great]

Originally Posted by rogue_ronin

rbmake also supports regex search/replace, built in. Just add a rule to your basic rbmake script (or a separate regex file using the s switch) or OPT file to replace <div style="page-break-after:always"/> with either <hr size=0> or <hr new-page>. Or whatever your preferred output is. (Maybe you want to keep the div, just replace the style?)

You could have quite a list of standard replacements to make your work easier. (You could share too! )

rbmake can be told to recognize <hr size=0> or to ignore it, using the z switch.

If you're going to update the program, I think you want the RBhtml libraries. I've emailed with Wayne Davison a few times, he's super-approachable. (I think he might hang out here, too -- don't know why I think that...)

m a r

Actually, what I'd really like to do is add support for OPF files. This would give me a chance to really learn the file format. But I don't know that I'll have the time.

[rogue_ronin]

Originally Posted by Nate the great

Actually, what I'd really like to do is add support for OPF files. This would give me a chance to really learn the file format. But I don't know that I'll have the time.

Do you mean make RB from OPF? Which format do you want to learn? I'd like to know more about OPF myself -- I think it's going to be a target for my xhtml macro library (along with RB, FB2, etc.) ePub itself eventually, but it kills my brain right now.

rbmake is really, really flexible. I wouldn't be surprised if a combination of scripting, switches and smart sourcing couldn't be done, as the utility is (unmodified), to produce what you want.

Are you a Linux guy, or Windows? In Linux, this would be very doable. In Windows, you have a more limited command-line.

What is the basic structure of an OPF? It's the "index" file of the ebook, right? If it is, all you'd have to do is:

a) unzip the source files
b) parse the OPF for contents and metadata
c) call rbmake with the list of pieces of the book, meta and with appropriate switches

Okay, step b is a bit Underpants-Gnomish, but not impossible at all. Step b would be pretty easy in my text-editor. (Actually, it can do all three steps.)

Step c might not even need much (or any) done in step b to be effective with rbmake : you can tell it where to begin in an URL tree and what to include using wildcards. It does all the searching and concatenation for you.

Play with it, you'll be surprised.

m a r

[Nate the great]

"Spine file" is a good way to think of it. It's an XML file that contains all the metadata for the ebook as well as a manifest of of the component html file(s), optional cover image, etc.

My main ebook creation tool right now is MobiCreator. I like it for a bunch of reasons, one of which is that it makes an OPF file as an intermediate step. After making the Mobi ebook, I then use the OPF file with html2epub to make the epub version.

[ilovejedd]

Originally Posted by Nate the great

"Spine file" is a good way to think of it. It's an XML file that contains all the metadata for the ebook as well as a manifest of of the component html file(s), optional cover image, etc.

My main ebook creation tool right now is MobiCreator. I like it for a bunch of reasons, one of which is that it makes an OPF file as an intermediate step. After making the Mobi ebook, I then use the OPF file with html2epub to make the epub version.

You don't actually need a "spine file". You can include a very simple spine inside the OPF file, itself.

Here's a crude OPF template I made for a pet project (FLAG). I doubt the OPF would work all that well inside an epub but it's a fairly good source of metadata when using Calibre's command-line conversion utilities.

<?xml version="1.0"  encoding="UTF-8"?>
<package xmlns="http://www.idpf.org/2007/opf" version="2.0"
         unique-identifier="BookId">
 <metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
           xmlns:opf="http://www.idpf.org/2007/opf">
  <dc:title>%%TITLE%%</dc:title>
  <dc:creator opf:role="aut">%%AUTHOR%%</dc:creator>
  <dc:language>en-US</dc:language>
  <dc:publisher>%%PUBLISHER%%</dc:publisher>
  <dc:identifier id="BookId">urn:uuid:%%IDENTIFIER%%</dc:identifier>
  <dc:subject>%%SUBJECT%%</dc:subject>
  <dc:date opf:event="publication">%%DATE_PUB%%</dc:date>
  <dc:date opf:event="modification">%%DATE_MOD%%</dc:date>
  <dc:description>%%SUMMARY%%</dc:description>
 </metadata>
 <manifest>
  <item id="id1.1" href="chapter1.xhtml" media-type="application/xhtml+xml"/>
  <item id="id1.2" href="chapter2.xhtml" media-type="application/xhtml+xml"/>
  <item id="id1.3" href="chapter3.xhtml" media-type="application/xhtml+xml"/>
  <item id="id1.4" href="chapter4.xhtml" media-type="application/xhtml+xml"/>
  <item id="id1.5" href="chapter5.xhtml" media-type="application/xhtml+xml"/>
  <item id="id2" href="style.css" media-type="text/css"/>
  <item id="id3" href="cover.png" media-type="image/png"/>
 </manifest>
 <spine>
  <itemref idref="id1.1"/>
  <itemref idref="id1.2"/>
  <itemref idref="id1.3"/>
  <itemref idref="id1.4"/>
  <itemref idref="id1.5"/>
 </spine>
</package>

[Nate the great]

Originally Posted by ilovejedd

You don't actually need a "spine file". You can include a very simple spine inside the OPF file, itself.

I meant that the OPF was a spine file (sort of).