HTML2LRF "Preprocessor"

[pepak]

Very nice. Now I don't need to add Linux compatibility anymore :-)

[sehrgut]

A question. Do you use the @import feature that much? It'd be a rewrite of the main function to implement, but it wouldn't be too difficult, if it's something that'd be useful. It just seems that little enough global metadata would be used (maybe a single comment or something) that it'd be just as easy to type that in as an absolute path to a common.htm or similar file. What's an example of the sort of thing you'd keep in a common.htm?

[sehrgut]

Oh, and a quick note on sed, in my script. If you're using gsed (Linux) rather than BSD sed, you'll need to change the -E option to, I believe, -r. Whatever option it is that in GNU sed invokes extended regexp support . . .

[pepak]

Originally Posted by sehrgut

A question. Do you use the @import feature that much?

I do - I have a whole tree of includes, e.g.:
common.inc - for all books
pratchett.inc - for author, author-sort; includes common.inc
discworld.inc - for customized chapter detection; includes pratchett.inc
book.htm - title, title-sort; includes discworld.inc

What's an example of the sort of thing you'd keep in a common.htm?

<meta name="lrf:--header" content="" />
<meta name="lrf:--no-links-in-toc" content="" />
<meta name="lrf:--chapter-regex" content="@@@NONE@@@" />
<meta name="lrf:--chapter-attr" content="h2,id,^(chapter|part)" />
<meta name="lrf:--force-page-break-before-tag" content="h2" />
<meta name="lrf:--add-chapters-to-toc" content="" />
<meta name="lrf:--cover" content="%p%n.jpg" />
<link rel="stylesheet" href="common.css" type="text/css" />

[sehrgut]

Ahhh . . . that does sound a good deal more useful than I at first thought. Mayhap I'll get it implemented over the weekend in h2lwrap.

Also, I didn't know you implemented flags as having empty "content" . . . I should support that as well as the complete absence of a "content" attribute (which is how h2lwrap currently does flags).

Thanks much!

[pepak]

I am not sure if missing content is permissible under HTML/XHTML rules. That's why I prefer an empty one.

[pepak]

New version (still the same link) has several enhancements:

1) It should be far easier to port to Linux: All (hopefully) Windows-specific functions have been isolated into four places:
- function Execute - calls an external program and returns result code
- function GetLastErrorStr - returns message explaining why Execute failed
- function SystemTempDir - returns location of temporary directory
- function SystemTempFile - creates uniquely-named file in a given directory
When these four functions are rewritten, the application should compile under Linux (using FreePascal compiler)

2) The utility now supports any format that Calibre supports: You just provide target on the command line (-t epub) and the utility uses information in its INI file to create a valid command for conversion.

3) Target-specific parameters are now supported. Instead of the old:

<meta name="@include" content="common.inc">
<meta name="lrf:--title" content="Book title">
<meta name="lrf:--header" content="">

you can now use:

<meta name="@include" content="common.inc">
<meta name="lrf:@include" content="common-lrf.inc">
<meta name="*:--title" content="Book title">
<meta name="lrf:--header" content="">

This way all targets include common.inc and add a title, but only LRF includes common-lrf.inc and uses --header parameter (which is not supported for e.g. EPUB).

[pepak]

Modified it a bit more. Now it should work under Linux. Could one of our Linux users try to compile it with FreePascal and see if it works? I don't have Linux myself.

[pepak]

Version 0.09 available - it is now compatible with Calibre 0.6 (and, presumably, any other utility no matter how it organizes its command line).

[pepak]

Version 0.10 adds one more compatibility fix (unfortunately, Calibre does not and will not support output paths beginning with a dot).

[pepak]

Even more fixes for Calibre 0.6.