bug-enscript
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-enscript] Question on "-2" column fill behaviour..


From: uhmgawa
Subject: Re: [bug-enscript] Question on "-2" column fill behaviour..
Date: Sun, 16 Sep 2012 00:27:16 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 09/15/2012 04:04 AM, Tim Retout wrote:
> On 14 September 2012 22:57, Michael McMac <address@hidden 
> <mailto:address@hidden>> wrote:

>     FWIW using -U2 in either portrait or landscape modes doesn't
>     generate the long portrait column rendering I'm after.
> 
> 
> Yes, when using -U/--nup the portrait or landscape mode is chosen based on 
> the n-up option - it alternates between portrait and landscape based on the 
> power of two that was passed, so that the pages will fit proportionately (at 
> least with A4 paper, I guess).  So there's no way to use n-up to have 
> portrait columns at present.
> 
> --nup-columnwise will only have an effect with -U4 or higher - it changes the 
> order in which the logical pages are put into the boxes on the physical page, 
> going down the columns before going across.
> 
> So you want columns like -2, but without forcing a new page on each new input 
> file.
> I honestly don't know if this is possible without patching enscript.

I don't believe it is possible currently with enscript.  For reference a2ps
can achieve a long vertical column rendering in portrait mode as:

    # a2ps --pro=color -A fill -T 4 --toc -R -o outfile.ps <input_files>

..and arguably does a respectable job.  The syntax highlighting however
I believe is more accurate and versatile under enscript.

I'd poked at this briefly just to ferret out the relevant synapses in the
code and was able to get -U2 to eek out roughly the equivalent format with
the attached hardwired patch and the following invocation:

    # enscript -T4 -Ec --color --toc -U2 -j -R -B -o outfile.ps <input_files>

This trivial patch isn't represented as solution and I'm sure it has a slew
of caveats and undesirable interactions with other options which need to be
resolved.

Incidentally concerning "-2" my quick observation of the code leads me
to believe generating the same output would be considerably more involved.
This option doesn't really appear structured to accommodate more than one
input file per physical page.

Attachment: enscript-longcol.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]