Firstly, let me just state that I see 1) HTML -> LaTeX conversion and 2) the set of programs/scripts proposed in the first post of this thread, as not being strictly related or dependent on each other.
Quote:
Originally Posted by kacir
I would suggest that you create one example multi-layout source with a few pages of Lorem Ipsum, with several chapters, subchapters, TOC, a few footnotes and references.
Then we might think about automating creation process.
|
I will probably do the multi-layout source example with a short story of sufficient complexity. That way people will be able to experientially appreciate the results, instead of just dryly looking over a few (dozen) pages of arguably asemantic text.
Quote:
Originally Posted by kacir
There are a few "self contained" LaTeX environments, like MikTex - do you might have a look.
Important question is, how much portable do you want to make the system. Should it be portable across the entire Win, MacOSX, Linux, FreeBSD environment?
|
Portability should not be problematic, kacir. In fact arguably the dependency resolution ought to be irrelevant for most more orthodox English eBooks. Doing deep dependency resolution and including those files (which, now that I think of it, may have licensing implications?) would mean that you can follow the same workflow for simple and complex files with a reasonable expectation of not encountering problems.
The sort of situation where dependency resolution might matter is let's say if I am using a hyphenation dictionary that's more advanced than the most current one in the Babel package, some uncommon packages that do something esoteric and may not be part of the TeXLive distribution (or the version thereof that the other person is using), and perhaps a few home-made .sty files that aren't formally/officially part of any widely distributed package.
Typesetting Casanova's Memoirs or even St. Thomas Aquinas' Summa Thelogica will not need anything as such... but I definitely have projects that do use the above-mentioned sort of odds-and-ends.
Quote:
Originally Posted by kacir
Final thought. We should not start "big". For the begining a simple system that would create just one format (display size) with support just for chapter headings and base text would be enough
|
This is a very good point, both for the Packaging/Autogeneration and for the HTML->LaTeX conversion programs.
For the packaging/autogeneration stuff, I think a small start could be:
1) A useful set of commands/macros to facilitate conditional statements used for certain page size/font size combinations.
2) The "package" could simply start out as a zipped .tex file with perhaps a plaintext file of some sort containing metadata included alongside (perhaps at first indicating nothing other than whether to use "pdflatex" or "xelatex").
3) The initial console-only autogenerator could simply do the unzip to temp. directory, modify unzipped .tex file with user-provided page size/font size paramters, run latex twice, copy PDF back, delete temp. directory.
I could actually do all of the above... to provide a small start for the project. Something to build upon.
Quote:
Originally Posted by tesseract420
You might consider opening the html file in Open Office, and then exporting it to LaTex. What's the need of sending the Latex packages along with the created pdf file? A simple LaTex document doesn't need any packages. The difficulty is specifying the page size for the varying worlds of ebook readers, from laptops to dedicated reading devices. LaTex will give you a beautifully typeset document, better than any other program can (except perhaps InDesign, which uses Professor Knuth's typesetting engine anyway). But at the end of the day, the output is a pdf file.
|
For the HTML->LaTeX stuff, if you read the pacify thread, you can find out about my ideas/plans... I'm pretty excited about that work, actually.
The OpenOffice conversion is as viable as all other options... but rarely results in anything that doesn't require considerable manual fixing.
- Ahi