[plt-scheme] Re: SRFI documentation

On Jun 30, Hugh Myers wrote:
> I'm looking at html2latex at the moment.

I don't think that tools like that are appropriate -- if they're good,
then they'll create a pdf that looks (and prints) roughly in the same
way that a typical browser will render it.  Looking at the html2latex
site, it looks like that's what it does.  Perhaps you can try to just
tweak your browser to print things more compactly, or maybe find
another browser that does a better job at printing?


> As far as 'main medium' goes, I use two screens and still have a
> printed manual open in front of me, not to mention bookshelves all
> around. That said, I understand what you mean in terms of effort and
> dividend.
> 
> I'll let you know if I can contrive an automated solution using the
> distributed html files in /PLT/doc/srfi-std.
> 
> --hsm
> 
> On Tue, Jun 30, 2009 at 10:42 AM, Eli Barzilay<eli at barzilay.org> wrote:
> > On Jun 30, Hugh Myers wrote:
> >> Little point? Using SRFI-13 as an example, printed, it runs to 30
> >> pages. Printed duplex, runs to 15.
> >>
> >> 1. you dislike trees?
> >> 2. you disdain manuals (printed that is)?
> >>
> >> I understand that 'real' scheme programmers don't need documentation,
> >> but this seems a little extreme.
> >
> > You forgot the "within the context of PLT" part...  In general, of the
> > two documentation formats, the HTML one is important in this context
> > because it is used by the help system -- so it made sense to work on
> > making those index wrappers so that help works with these manuals too.
> > A side benefit is that these external documents are already in HTML
> > form so they're viewable alongside the rest of the plt documentation
> > when used from the help system.
> >
> > We would probably have had to work more if, for example, the srfi
> > documents were all in PDF -- then we'd need to work on converting the
> > PDFs into html.  Another option is if we'd use PDFs for our help
> > system, and then it would make a lot of sense to work on converting
> > the srfi documents to PDF.
> >
> > But as things stand now, converting them is putting work into PDF
> > formats that are not used in the help system and not distributed with
> > the plt installers -- which is why I said that there is little point
> > in doing so.  If printed papers are the main medium that you're using
> > to read the manuals, then obviously it makes a lot of sense for you.
> > Also, if there is some relatively painless way to convert a directory
> > of random HTML (and they *are* random, since AFAICT, the pages come
> > directly from srfi authors that can do whatever they) into better
> > looking PDFs on Linux then we can integrate that into our nightly
> > build and create PDFs for them too.  I don't know of any such tool.
> >
> >
> >> On Tue, Jun 30, 2009 at 10:24 AM, Eli Barzilay<eli at barzilay.org> wrote:
> >> > On Jun 30, Hugh Myers wrote:
> >> >> The process of converting from HTML to PDF is not a 'new' problem---
> >> >> so yes it could magically be done.
> >> >
> >> > Most of the manuals are written in scribble form, which has rendering
> >> > backends for latex and for html.  The srfi and r6rs documentations are
> >> > used "as is" -- directly from the respective sources, and there is a
> >> > thin wrapper that arranges the index.  There is little point in
> >> > turning them into PDF form within the context of PLT.
> >> >
> >> > --
> >> >          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
> >> >                    http://barzilay.org/                   Maze is Life!
> >> >
> >> _________________________________________________
> >>   For list-related administrative tasks:
> >>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> >
> > --
> >          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
> >                    http://barzilay.org/                   Maze is Life!
> >

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!