In the not always laudable
PDF is not an eBook thread,
an idea was born as a result of discussion between frabjous and myself.
The idea is twofold, and can be seen either as a step toward eBook distribution via LaTeX source files that would be processed at display-time
OR as merely a better way of allowing eBook reading individuals to custom-generate high-quality (semi-)professionally typeset eBooks.
Either way, there are three components arguably required (or at least ideal) for LaTeX source-based distribution:
1)
LaTeX source packager (with deep dependency resolution)
A program--a simple console script should suffice--that determines (whether by parsing or other methods)
all dependencies of a LaTeX file, and bundles them along with the user-created source file in a zip (or other format) "package". It may be preferable/necessary to have some of the source files altered to ensure that include statements give primacy to the files stored in the local folder (once the package is unzipped).
The idea here is to include all files that aren't part of even the most bare-bones LaTeX installation, and thereby ensure that if the package compiles on 1 computer, it is maximally likely to compile on all computers. (i.e.: It won't fail because of a missing .sty file, or because the .sty file is a different version. It won't fail because of missing babel packages. It won't use a different [possibly older/less correct] hyphenation dictionary than the package generator had on their system. Et cetera.)
Also, page sizes and font sizes should be handled via standard variables that can be easily changed (and whose effects will cascade throughout the source) to alter the output.
2)
LaTeX -> Custom PDF generator
A minimalistic GUI program (a front-end for the console script, really) that basically allows either via drag-and-drop or via browsing/file selection the user to pick a LaTeX source package (as per above) and generate a PDF therefrom
with user-specified page size and font size preferences.
This is nothing overcomplicated, other than perhaps for making the GUI both elegant and functional.
The console back-end would basically:
a) unzip the LaTeX source package into a temporary directory
b) run "latex" or "pdflatex" or "xelatex" (depending on what is demanded by the package) twice
c) copy the resulting PDF into the output directory (or the current directory where the console script runs from)
d) delete the temporary directory
In essence, what little complexity there is gets hidden completely, and the user is not left with a myriad LaTeX working files (.out, .toc, et cetera).
3)
Multi-layout LaTeX sources
A convention--or more probably a set of macros/commands maybe even in a LaTeX package--that facilitates the creation of LaTeX source files that have manual adjustments/corrections for multiple fixed layouts.
At its simplest, this could be a conditional (using the ifthen LaTeX package) \clearpage{} when the page size is (for example) 6", in order to avoid an unsightly orphan or widow.
At a more complex level, it might go as far as including conditional soft-hyphens, conditional kerning, et cetera based on specific combinations of page size and font size.
The idea, of course, is that these sort of conditional adjustments will help make different size PDFs autogenerated via #2 better looking
in the cases where the eBook maker specifically addressed the page size or page size/font size combination. In the cases, where they have not, the autogenerated PDF might lack the refinement of a manually fixed up book, but could still be made to look fairly good by the judicious relaxing of certain values typographic strictness in LaTeX (i.e.: when instead of the manually addressed sizes or size combinations, the user requests something unorthodox).
----------------------
I have written this post with the hope of getting some of my fellow LaTeX / typography aficionados interested in the idea, and perhaps contributing their talents in some way.
I've no desire/intention to lead this project. So by all means post your comments and code here freely, and may innovation come forth in great rushes from the creative chaos that ensues!
I myself will probably give an attempt to tackling #3 first, and maybe give a shot to the console/back-end portion of #2 down the road. I am, however, no GUI programmer (if indeed I am any sort of programmer at all) and am utterly befuddled by TeX's directory structure... so probably would be no good at anything else.
Thanks in advance to anybody and everybody that decides to contribute either ideas or concrete programs/source code.
- Ahi