Register Guidelines E-Books Search Today's Posts Mark Forums Read

Go Back   MobileRead Forums > E-Book Formats > Workshop

Notices

Reply
 
Thread Tools Search this Thread
Old 09-11-2009, 10:08 AM   #1
ahi
Wizard
ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.
 
Posts: 1,792
Karma: 507333
Join Date: May 2009
Device: none
LaTeX Source Packages & Autogeneration

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
ahi is offline   Reply With Quote
Old 09-11-2009, 10:23 AM   #2
Jellby
frumious Bandersnatch
Jellby ought to be getting tired of karma fortunes by now.Jellby ought to be getting tired of karma fortunes by now.Jellby ought to be getting tired of karma fortunes by now.Jellby ought to be getting tired of karma fortunes by now.Jellby ought to be getting tired of karma fortunes by now.Jellby ought to be getting tired of karma fortunes by now.Jellby ought to be getting tired of karma fortunes by now.Jellby ought to be getting tired of karma fortunes by now.Jellby ought to be getting tired of karma fortunes by now.Jellby ought to be getting tired of karma fortunes by now.Jellby ought to be getting tired of karma fortunes by now.
 
Jellby's Avatar
 
Posts: 6,049
Karma: 4347035
Join Date: Jan 2008
Location: Spaniard in Sweden
Device: Cybook Orizon, Kobo Aura
For #1, adding \listfiles in the source might help.

I think it would be more interesting at the moment to have some XHTML+CSS -> LaTeX converter (where the generated LaTeX file need not be fully structured) as a means to generate good (though not "perfect") quality PDFs from ePUBs, for instance.
Jellby is online now   Reply With Quote
Old 09-11-2009, 10:28 AM   #3
ahi
Wizard
ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.
 
Posts: 1,792
Karma: 507333
Join Date: May 2009
Device: none
Quote:
Originally Posted by Jellby View Post
For #1, adding \listfiles in the source might help.

I think it would be more interesting at the moment to have some XHTML+CSS -> LaTeX converter (where the generated LaTeX file need not be fully structured) as a means to generate good (though not "perfect") quality PDFs from ePUBs, for instance.
My pacify script eventually should be able to deal with (X)HTML input... and I suppose, given that it will also parse RTF with some formatting preserved, taking the CSS into consideration also wouldn't be that great a leap. Perhaps I'll have time this weekend to continue working on it.

I'll check out what \listfiles does. Never used it before.

- Ahi
ahi is offline   Reply With Quote
Old 09-11-2009, 10:41 AM   #4
acidzebra
Liseuse Lover
acidzebra ought to be getting tired of karma fortunes by now.acidzebra ought to be getting tired of karma fortunes by now.acidzebra ought to be getting tired of karma fortunes by now.acidzebra ought to be getting tired of karma fortunes by now.acidzebra ought to be getting tired of karma fortunes by now.acidzebra ought to be getting tired of karma fortunes by now.acidzebra ought to be getting tired of karma fortunes by now.acidzebra ought to be getting tired of karma fortunes by now.acidzebra ought to be getting tired of karma fortunes by now.acidzebra ought to be getting tired of karma fortunes by now.acidzebra ought to be getting tired of karma fortunes by now.
 
acidzebra's Avatar
 
Posts: 869
Karma: 1035404
Join Date: Jul 2008
Location: Netherlands
Device: PRS-505
Quote:
Originally Posted by Jellby View Post
I think it would be more interesting at the moment to have some XHTML+CSS -> LaTeX converter (where the generated LaTeX file need not be fully structured) as a means to generate good (though not "perfect") quality PDFs from ePUBs, for instance.
I'd second that vote; I've been trying to use htmltolatex.jar but the output leaves a lot to be desired. Still better than nothing, though. Using tidy to clean up the HTML beforehand helps too.
acidzebra is offline   Reply With Quote
Old 09-11-2009, 10:47 AM   #5
frabjous
Wizard
frabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameter
 
frabjous's Avatar
 
Posts: 1,213
Karma: 12890
Join Date: Feb 2009
Location: Amherst, Massachusetts, USA
Device: Sony PRS-505
Excellent.

Would it worth bringing this up at comp.tex.tex and/or latex-community.org in hopes of soliciting volunteers?

Has anyone tried any of the html2latex converters (I guess there are several scripts by this name) already out there? There is a list of five of them on the PC Textprocessors to (La)TeX converters page at TUG? I have to confess I haven't tried any of them. (Most seem to be in perl or C... I have to confess that if I were going to start honing my own skills to do better, I'd prefer something in Python, so maybe ahi's is a better place to start...) I have used the rtf2latex2e converter listed there, with so-so results.

(P.S. I guess while posting, acidzebra has chimed in with some feedback on one of them! Great...)
frabjous is offline   Reply With Quote
Old 09-11-2009, 10:56 AM   #6
ahi
Wizard
ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.
 
Posts: 1,792
Karma: 507333
Join Date: May 2009
Device: none
Quote:
Originally Posted by frabjous View Post
Excellent.

Would it worth bringing this up at comp.tex.tex and/or latex-community.org in hopes of soliciting volunteers?

Has anyone tried any of the html2latex converters (I guess there are several scripts by this name) already out there? There is a list of five of them on the PC Textprocessors to (La)TeX converters page at TUG? I have to confess I haven't tried any of them. (Most seem to be in perl or C... I have to confess that if I were going to start honing my own skills to do better, I'd prefer something in Python, so maybe ahi's is a better place to start...) I have used the rtf2latex2e converter listed there, with so-so results.

(P.S. I guess while posting, acidzebra has chimed in with some feedback on one of them! Great...)
I personally have found HTML -> LaTeX converters to be close to useless... primarily because, not making assumptions about what they are being used for, they simply try to do as precise a conversion as possible.

The results of that we all know, it sounds like.

My approach with pacify will be to assume we are dealing with an eBook that uses only simple formatting (and ignore overcomplications in the source code accordingly). That should result in cleaner LaTeX source that isn't an active obstacle to LaTeX producing a good quality output.

I have not approached any TeX/LaTeX groups... having no connection with any, and being at best moderately familiar with TeX's/LaTeX's internal workings. As a result, I suspect I would not be a technically coherent enough spokesperson to raise sufficient interest in this idea.

Might you be better suited, frabjous, to approach them?

- Ahi
ahi is offline   Reply With Quote
Old 09-11-2009, 11:05 AM   #7
kacir
Wizard
kacir ought to be getting tired of karma fortunes by now.kacir ought to be getting tired of karma fortunes by now.kacir ought to be getting tired of karma fortunes by now.kacir ought to be getting tired of karma fortunes by now.kacir ought to be getting tired of karma fortunes by now.kacir ought to be getting tired of karma fortunes by now.kacir ought to be getting tired of karma fortunes by now.kacir ought to be getting tired of karma fortunes by now.kacir ought to be getting tired of karma fortunes by now.kacir ought to be getting tired of karma fortunes by now.kacir ought to be getting tired of karma fortunes by now.
 
kacir's Avatar
 
Posts: 2,765
Karma: 3093505
Join Date: May 2006
Device: PocketBook 360, before it was Sony Reader, cassiopeia A-20
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.

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?

Another idea is to take a format, like FB2 and make a parser that would create LaTeX source .

Would it be feasible to use Scribus? - An opensource program that would like to be an inDesign alternative.
http://wiki.scribus.net/index.php/Wo...h_latex_frames

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.

Disclaimer:
I do not really use or know LaTeX. LaTex is just at the top of my "To Do" list, and has been there for more than a decade ;-)
kacir is offline   Reply With Quote
Old 09-11-2009, 11:12 AM   #8
tesseract420
Member
tesseract420 is on a distinguished road
 
Posts: 19
Karma: 68
Join Date: Apr 2007
Device: sony prs-500
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.
tesseract420 is offline   Reply With Quote
Old 09-11-2009, 11:24 AM   #9
ahi
Wizard
ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.
 
Posts: 1,792
Karma: 507333
Join Date: May 2009
Device: none
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 View Post
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 View Post
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 View Post
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 View Post
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

Last edited by ahi; 09-11-2009 at 11:26 AM.
ahi is offline   Reply With Quote
Old 09-11-2009, 11:29 AM   #10
tesseract420
Member
tesseract420 is on a distinguished road
 
Posts: 19
Karma: 68
Join Date: Apr 2007
Device: sony prs-500
But putting this issue aside, I would love to see LaTex as the ur-source of ebook files. In my own case, I have all sorts of files that I can really no longer access easily, starting with the Rocketbook's html 3.3 files and bizarre names. LaTex files are plain text and small; the fact that they are plain-text guarantees that the archives can be kept over time without losing access due to unavailability of devices or even operating systems. The "issue" with LaTex is that it is page-oriented and the e-book world is rapidly distancing itself from the printed page. I was playing around with the epub format the other day. Its cross-platform functionality is great, but what happens to the table of contents? Its simply gone, since there aren't pages anymore. Epub may be a great format, but who knows if it will be around ten years from now? Plain text will be around as long as we have computers.
tesseract420 is offline   Reply With Quote
Old 09-11-2009, 11:35 AM   #11
ahi
Wizard
ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.
 
Posts: 1,792
Karma: 507333
Join Date: May 2009
Device: none
Quote:
Originally Posted by tesseract420 View Post
The "issue" with LaTex is that it is page-oriented and the e-book world is rapidly distancing itself from the printed page.
I firmly believe that only eNovels have the privilege of such fanciful tomfoolery. eBooks in general need pages as much as scrolls do. And even with novels... all of my eBooks have table of contents--and I would not wish to do without them. (But let's not turn this thread into a discussion about whether eBooks needs pages or not.)

I'm largely in agreement with everything else you said though.

- Ahi
ahi is offline   Reply With Quote
Old 09-11-2009, 11:45 AM   #12
kovidgoyal
creator of calibre
kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.
 
kovidgoyal's Avatar
 
Posts: 25,622
Karma: 4998489
Join Date: Oct 2006
Location: Mumbai, India
Device: Various
Just a couple of notes:

1) All of LaTeXs (actually TeXs) layout algorithms are designed for a fixed page size. Now while in theory this should not be a problem, as you can pass in the page size at compile time, in practice almost all LaTeX macro packages make certain assumptions about minimum page size. Just one example: The RevTeX package used for formatting of articles to be submitted to the Physical Review Journals format the abstract assuming a large page size. Just try using the geometry package with a revtex file.

2) TeX (as opposed to HTML) is designed for multi-pass compiling. This is poses two problems:

a) Your hypothetical latex viewer will have to figure out how many times to run pdflatex on the source, not an easy task, witness the number of build systems for LaTeX

b) This will be really, really slow compared to laying out a reflowable format

3) Packaging a TeX distribution is no trivial task and the smallest Text distributions I've ever come across are still pretty large

4) The real improvements of formatting something using TeX come when you either position things by hand or write special purpose algorithms. Positioning things by hand is out in a reflowable context and writing custom algorithms in TeX is a nightmare, believe me, I've done it.

All in all, I doubt this will work. But don't let me discourage you from trying
kovidgoyal is offline   Reply With Quote
Old 09-11-2009, 11:46 AM   #13
frabjous
Wizard
frabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameterfrabjous can solve quadratic equations while standing on his or her head reciting poetry in iambic pentameter
 
frabjous's Avatar
 
Posts: 1,213
Karma: 12890
Join Date: Feb 2009
Location: Amherst, Massachusetts, USA
Device: Sony PRS-505
Anything that uses e-Ink technology still uses "pages" -- we press a button and get a completely different stock of words. It's not a "scroll" like with a browser. For most purposes, I'm happier with pages.

Maybe if devices like iPhones, etc., or portables with more computer-like monitor scrrens, took off and e-Ink died out there will come a time when page-based typography will go away, but not anytime soon, I don't think.

I actually don't think a tweaked version LaTeX would do *that* poorly transitioning to a scroll-like environment, so long as its paragraph and line-breaking algorithms were left mostly untouched.

There's little point in using LaTeX rather than the presently available epub renderers if you don't even want that much traditional typography.

Quote:
Originally Posted by ahi View Post
Might you be better suited, frabjous, to approach them?
I'll bring it up at the latex-community forms. I don't subscribe to comp.tex.tex -- my ISP doesn't have usenet, and going through Google groups is too much of a hassle. But perhaps the idea may spread from LC to comp.tex.tex, which I think has more of the real TeX pros on it. I'm probably not much more TeX-savvy than you are (if at all), so I'm not sure it would come off as more technically competent coming from me, but from what I've seen, the people in these communities are friendly folks who realize that not everyone knows everything from the get-go.

EDIT:
Kovid, most of your points have already been addressed in our discussion in the thread ahi linked to. Ahi's idea now is to have scripts for making the PDFs run on our desktops/laptops, and then just using the resulting PDFs on our readers, not trying to include TeX in the firmware of the reader (though I maintain that would still be a great thing as a long-term goal). So the size and slowness issues should be fairly minimal. (And not to put down your wonderful work, but compiling a book in TeX to PDF takes no longer than converting one in calibre--if anything, it takes less time, in my experience, for the same sized/complexity book.) The idea would be to distribute the .tex source so that the end user could make their own PDFs with their own preferred page and font sizes (which is why any dependent packages would have to be included); not to distribute the PDFs.

Scripts that automatically determine how many times LaTeX needs to run already exist. I'll see if I can find one...

Edit x2: Here are three such scripts:

latexmk

latex-mk

latexmake

Last edited by frabjous; 09-11-2009 at 12:09 PM.
frabjous is offline   Reply With Quote
Old 09-11-2009, 11:59 AM   #14
kovidgoyal
creator of calibre
kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.
 
kovidgoyal's Avatar
 
Posts: 25,622
Karma: 4998489
Join Date: Oct 2006
Location: Mumbai, India
Device: Various
Ah you want to have users generate custom PDFs. That's a whole different ball game and is certainly do-able, though you will still run up against badly designed macro packages.
kovidgoyal is offline   Reply With Quote
Old 09-11-2009, 12:04 PM   #15
ahi
Wizard
ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.ahi ought to be getting tired of karma fortunes by now.
 
Posts: 1,792
Karma: 507333
Join Date: May 2009
Device: none
Quote:
Originally Posted by kovidgoyal View Post
Just a couple of notes:

1) All of LaTeXs (actually TeXs) layout algorithms are designed for a fixed page size. Now while in theory this should not be a problem, as you can pass in the page size at compile time, in practice almost all LaTeX macro packages make certain assumptions about minimum page size. Just one example: The RevTeX package used for formatting of articles to be submitted to the Physical Review Journals format the abstract assuming a large page size. Just try using the geometry package with a revtex file.
This part is addressed by the assumption that the source is one prepared by somebody that knows what they are doing... and is aware of the intended use of the files.

To be clear, the HTML -> LaTeX discussion is an entirely separate one. No automatic conversion can generate a file that's ready for multi-layout targeted distribution.

Quote:
Originally Posted by kovidgoyal View Post

2) TeX (as opposed to HTML) is designed for multi-pass compiling. This is poses two problems:

a) Your hypothetical latex viewer will have to figure out how many times to run pdflatex on the source, not an easy task, witness the number of build systems for LaTeX

b) This will be really, really slow compared to laying out a reflowable format
Personally I do not believe in the merit of trying to use TeX source directly on an eBook reading device... but, like you, I do not wish to discourage others.

Quote:
Originally Posted by kovidgoyal View Post

3) Packaging a TeX distribution is no trivial task and the smallest Text distributions I've ever come across are still pretty large
This seems to be a misunderstanding. Packaging in the context of anything I myself wrote refers to basically shoving the .tex source file, along with whatever dependencies have been determined, into a .zip (or other) container... so you have a single file, instead of a bunch of them.

Kind of like ePub is for HTML+CSS+METADATA.

Perhaps I've used the term "package" / "packaging" confusingly.

Quote:
Originally Posted by kovidgoyal View Post

4) The real improvements of formatting something using TeX come when you either position things by hand or write special purpose algorithms. Positioning things by hand is out in a reflowable context and writing custom algorithms in TeX is a nightmare, believe me, I've done it.
The main idea is something around the lines of inserting conditional manual adjustments throughout the LaTeX source that activate only for certain (popular) page size / font size combinations. And for any unanticipated combinations, there are tricks (like \sloppy) that can generate a tolerable, if lesser quality, output even still.

The key, of course, will be to test a reasonably large number of sizes... and also to accept the fact that the smaller the screen, the less strict LaTeX must be allowed to be.

Quote:
Originally Posted by kovidgoyal View Post
All in all, I doubt this will work. But don't let me discourage you from trying
Thanks!

- Ahi
ahi is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Nook nook Source-Code durch B&N veröffentlicht :D ominik Andere Lesegeräte 3 02-25-2010 05:14 AM
Hello From Virginia & New Open Source Software lprichar Introduce Yourself 3 06-06-2009 08:13 PM
folder management & delete source file after conversion Taantric Calibre 1 12-16-2008 01:10 AM
Encrypting & Securing your data: Open- or Closed-Source? Alexander Turcic Lounge 20 04-11-2004 02:51 PM


All times are GMT -4. The time now is 04:12 PM.


MobileRead.com is a privately owned, operated and funded community.