[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Programming Lout Backends
From: |
Jeff Kingston |
Subject: |
Re: Programming Lout Backends |
Date: |
Wed, 17 Dec 2008 06:44:41 +1100 |
User-agent: |
Mutt/1.4i |
On Tue, Dec 16, 2008 at 07:07:35PM +0100, Christoph Angerer wrote:
>
> My idea would have been, to use lout as the "lingua franca" and
> provide different backends in lout to generate the formats directly
> instead of trying to convert postscript files into mobipocket files
>
> My question is now: does anybody think this is feasible? How difficult
> is it (in practice) to write another lout backend? As I said, the
> input documents are?at least for now?rather simple texts with sections
> and subsections and maybe sometimes boldface font or a quote.
>
> In the lout source code, backends look pretty well modularized; I am
> thinking of the typedef struct back_end_rec in externs.h that seems to
> provide some plugin functionality. So is it as simple as providing
> implementations of those 26 functions to produce a file in a
> completely new format? Or are there some caveats or am i missing
> something? (Since the PDF backend is kinda discontinued it makes me
> think that this might be harder than it looks...)
I don't think Lout is well suited to the job of being a universal
document markup language. I can't think of any language that is
well suited to that task, except Nonpareil, which does not exist yet.
There are a lot of issues hiding behind the 26 backend functions.
My suggestion would be to make a design that allowed multiple formats
and plugins that convert those formats to other formats. In the end
I think you want to be displaying PDF, because it can display all
kinds of fun things, it is a moderately reliable standard, and there
are converters from virtually every format to PDF. But of course
you can't store documents in PDF format, because they are already
laid out in a fixed format.
Jeff