[Scribus] EasyPose - OpenSource Profissional Imposition

Craig Ringer craig
Thu Aug 30 20:10:37 CEST 2007


celsojr wrote:
> Hi there!
> My name is Celso, I'm from Brazil and I 'm starting finishing a project that
> aims to finally solve the lack of high-end options when we talk 'bout
> Imposition (more when we care about complex imposition, like 64 pages per
> eg...) ^_^

Sounds good to me.

> http://geocities.yahoo.com.br/celsojr2005/easypose/
> 
> since it is still in zeta release (far from a beta ^_^) there is no usefull
> output yet... but the features are:

If you plan to release this under an OSS license and want to make it a
bit easier for people to get the code, etc, maybe you might want to
consider a sourceforge account. Their subversion servers aren't fast but
overall they're pretty good, and they take care of things like backups
for you.

> All calculations are done and most of the interface is ready... but I'm
> stukked... the Ghostscript is great to RIP or PDF generation, but I must
> embed the Postscript data of each page selected, so I could positioning and
> rotate the correct pages throughout  the final page.

Honestly, I'd drop GhostScript if possible, and try to impose PDF
natively. You'll have fewer problems with transparency and other
advanced features, and you'll be able to more efficiently eliminate
duplicate content.

> So I thought EasyPose could easylly  create the final layout in a ,sla file
> and then use the pdf embedded image for the pages...but I saw the pdf ,
> althought is embedded, becomes rasterized in the output...

Correct. It's one of those things that it'd be nice to change, but
nobody has got around to trying yet. There are now tools that'd make it
easier though.

> I can direct my output right to a Raster format, so inkjet, or laser
> printers can be used, but, if I have to use the PDF in CPT or a outsider
> RIP... what could I do?

First, I'd make sure your design was flexible enough that you can handle
multiple different output formats. Sooner or later, somebody will want
this, I guarantee it. This would also let you implement a TIFF output
engine that you can use for comparison against (eg) imposed PDF when
testing.

Once that flexibility is in place you can more easily try new things
with regards to output formats. I'd start with native PDF impostition,
but maybe that's because I help develop a PDF library ;-) . As I noted
above I expect that'll give you the most flexible results with the best
quality and output sizes.

Speaking of PDF libraries, if you're using C++ PoDoFo
(http://podofo.sf.net) might be worth looking at for your low-level PDF
manipulation, since it's reasonably efficient and provides access to the
guts of the document format without your having to do the work parsing
it, writing it out, etc. It's not at an API-stable release point, but
we're not breaking things too fast at present, there are milestone
releases you can target, and it's easy to bundle into your app so you
can use private snapshots. You'd need to use another library like
poppler to rasterise PDF for page thumbnails etc, though.

I've been of the view for a while now that a standalone PDF imposition
tool would be the ideal way to handle the limited imposition facilities
available to OSS DTP users.

If you decide to go that way I'd be glad to lend a helping hand if I can
(even if it's just with library issues, compiling & testing, porting, etc).

--
Craig Ringe



More information about the scribus mailing list