[Scribus] I really shouldn't open my mouth... but I'm going to

[Craig Ringer]

Calum Polwart wrote:
> Ok - there are three things that stop me getting some of my windows
> mates into scribus for their work. 
> 
> 1. The tables thing - there is nothing I can do to sort that and so I
> just have to live with it. 
> 
> 2. The size of PDF it produces when I want a baby PDF for a web version.
> In the past I've got the impression that fixing this would be tricky
> because it all comes down to individual character placement instead of
> word / lines.  So again I think I have to live with it.

Ideally that character placement method would not be required. I'd be
very interested in knowing if it's actually still an issue with
acceptably recent software (not even a *printer* could still be using
stuff of the Acrobat 2 / Acrobat 3 vintage despite their adoration for
the obsolete).

A few things can improve this:

   - Collapsing runs of characters better (new text system)
   - Using PDF object streams (PDF >= 1.5) to compress the
     character data, if Scribus doesn't already do this
   - True font subsetting support

... and probably more.

> 3. Lack of booklet printing.  I know all the work around etc etc etc.
> But these are Windows Users!  These are people who expect a paper clip
> to pop up and ask if they need help writing a letter!  This is a very
> common query on this list which makes me think it would be a popular
> upgrade...

Yep. I think everybody's aware of the large group of users for whom it
matters. Getting it done is another thing, since that group aren't
exactly full of people volunteering to dive into some sometimes-hairy
C++ code to implement it.

> Now I may be wrong but I imagine this is possibly relatively easy to
> code.

1: No

2: Collapsing runs is currently not easy at all; PDF object streams
wouldn't be too hard but would only be compatible with Adobe Reader 6 or
7; true font subsetting is certainly not trivial even before you work
around the myriad different bugs in clients.

3: Probably not too bad. I had a bash at it myself but (surprise
surprise) got bogged and ran out of time. It's certainly not a trivial
job and requires changes to more than you might expect but it's far from
impossible.

> After-all the difficult bit is presumably getting the PDF format -
> and that's done. So (hence the title) what if I wanted to fix it myself.
> I have a fair amount of coding experience in other languages but don't
> even know what language Scribus is written in would it be worth my while
> even attempting it?

If you're prepared to spend a bunch of time learning the code base and
learning C++ then yes, it's quite possible.

You will not be able to leap straight into tackling these issues. You
would want to start by investigating some bugs, documenting code, doing
some cleanups, etc. There's plenty to do. In that process you'll become
more familiar with the language, the tools, and the codebase, to the
point where you may be able to tackle these problems.

> Is there a place to look for help and if I did get
> it working (hah!) then where would I go to post the "solution" and would
> it be taken on by the team?

If done right, sure. You'd want to talk over any plans in IRC or here
before embarking on major changes, just to give others' a chance to spot
any flaws or problems in the planned approach.

> I've seen the naming convention wiki - but
> was looking for more of a howto...

There really isn't a howto for the sort of stuff you want - it's Scribus
innards. It'd be nice if there was more doxygen documentation but that's
something that's only been being added to the code progressively and is
currently EXTREMELY far from being complete.

> The plugin howto seems to be a broken link but I'm not clear if this
> would be a plugin or a change to the actual core code (if there is a
> difference)

No chance you could do any of this with a plugin. I'm not too sure what
true table support would entail, but it'd probably be a lot of work in
PageItem, the canvas, etc. However I think there's work in progress on
this (?) .

Booklet printing can be done in a couple of ways. There should be a big
document on the wiki somewhere (no time to look right now) discussing
different ways to tackle imposition. One of them - which I think is the
easiest to implement and best suited to simple tasks like booklet
printing - is to separate logical Scribus pages from "physical" PDF
pages so that one PDF page may contain zero or more Scribus pages
subject to suitable transformations. I've investigated this approach and
dome some preliminary work that might help. Most of the work here is in
pdflib .

PDF size... well, there are a few areas to investigate here. The PDF
export code is actually fairly readable, and that's mostly what you'd be
working on. I'm not aware of any reason why object streams would be
particularly hard to implement (heck, they might be already, I haven't
checked). Font subsetting will not be easy and involves work on the
rather complex font classes in Scribus. There are also reasons why it's
not currently used or supported, so I wouldn't jump into working on that
without having a chat to Franz. Finally, collapsing runs of characters
is probably not at all easy - but AFAIK will be done as part of the new
text system work that's in progress in 1.3.x anyway.

If you're serious about any of this you might want to drop in on IRC and
have a chat, since I've been a bit out of touch lately and there's some
background on some of this that I don't know.

--
Craig Ringer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20061101/d9309715/attachment.pgp