[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Experiences with Lout
From: |
Joerg Jung |
Subject: |
Re: Experiences with Lout |
Date: |
Mon, 15 Apr 2013 15:59:34 +0200 |
Hi,
Am 14.04.2013 um 22:36 schrieb Valery Ushakov <address@hidden>:
>> - Overheads: with @Lectures the default @OverheadNumInDisplays { No } seems
>> not to be applied.
>
> There's a typo in slidesf in def @Overhead invocation of
> @LargeScaleStructure, the at-sign is lost in:
>
> indisplays { OverheadNumInDisplays }
>
>> - @*NumberedDisplay number format: left side numbers are not possible :(
>
> Looks like unedited copy-paste in bsf.
Thanks, for looking into both issues, maybe someone (Jeff?) can fix them
with the next release?
Is there a bug tracking somewhere or can I send patches/diffs somewhere
to help, getting things fixed?
>> - I personally think the Plain and PDF export is useless and can be
>> dropped. Both work only very limited and there are tools
>> available to convert from PS to PDF to TXT and back.
>
> Isn't it a bit rash
Rash, no.
Harsh, yes absolutely. That is why I wrote: "I personally" (IMHO) to
reflect my personal view (which is probably not common).
> to dismiss a feature that you don't use as
> universally useless?
I wrote this, _after_ I worked with both exports for a while, hence I
used them intensely. My very *personal* conclusion is: both are
too limited and introduce bloat, e.g. additional cases in include
configs for Plain case and additional case for drawing primitives
adding "case pdf" in several places. *I* prefer software not bloated
with such limited options.
> I personally find plain text extremely useful for debugging
> definitions or doing a quick test (lout -p -s | cat -s).
This is a good point, but I'm pretty sure there are better options
for debugging from Lout developers point of view (e.g. gdb) and
from users point of view Lout error output is great and
provides everything required for definitions debugging.
For debugging things in my thesis, I ended up in setting up a
"test" document with the same 'template' configuration (headers,
fonts, etc.) but no 'content'. If I setup a new larger Diag for example,
I do this in the test environment as compiling takes a second here.
Afterwards I copy it over to the production document.
My production thesis document is a rather large document (about
180 pages, hundreds of cross references, several Diags, a lot of
Graphs (with larger input from @Pipe awk/grep/sed) and several
Listings. It takes several minutes and about 16 runs to build the ps
and even some more minutes to create the final PDF. So for me,
no option to debug something directly there without wasting hours
of time.
> Other people find PDF useful because when you need to generate simple
> PDFs well within limitations of the pdf backend, you save time/space
> on not having ghostscript around.
*IMHO* not a reason to bloat Lout.
But anyway! Not so important... this was just a suggestion.
I'm fine if that suggestion does not match the view of the
project (developers).
Regards,
Joerg