The Scribus target - a question for the developers

[Mike Morris-12]

I am new to Scribus, but not to DTP.  I have been exploring Scribus, and I
am an avid reader of the mailing list messages. I am using Scribus
1.3.3.11on a Windows XP platform. My question for the developers is a
result of the
many comments and questions posted over the past month on such topics as who
is (or should be) using Scribus, and such features as imposition, color
management, printing, and even spell checking.

The question:  What is the goal of the developers?

This is curiosity on my part.  Scribus, so far, is, in my judgment, a
significant accomplishment, especially as the work is (apparently)
financially uncompensated and done on a "part time" basis. I say that as
both a software user (not a programmer) and former small print shop owner.
My tentative conclusion is that Scribus is a useful design tool, but not
(yet) a production tool--consider, for example the comments on imposition.
I see no reason why Scribus could not be a significant design AND production
tool.  That makes it targeted, I think, based on current capabilities,
towards the "professional" user and not the consumer.  Given the necessary
complexity of a true DTP (call it page layout or page assembly if you
prefer) application, that makes sense to me.  However, as a former shop
owner, I find myself compelled to point out that both ease of use AND
functionality are important to getting work done in a timely and profitable
way.  Two non-coding issues are important contributors to ease of use (in my
opinion).  One is good documentation, and the revised tutorial and the
forthcoming printed manual (yes, I consider a printed manual important) are
steps in the right direction.

The second issue (as I see it) will probably stimulate much disagreement.  I
am aware that frequent changes are viewed as appropriate and even necessary
in the open source community.  However, frequent changes (even if free) can
be a significant productivity blocker in a production environment--at least
in a small independent print shop.  Software stability--and I am not talking
technical stability--is necessary (again, in my opinion) for profitable
operations.  By the way, I do not consider that need limited to DTP
software.  I had a specialized (for the printing business) production
control package that required an annual update ($800) and impacted the
hardware as well.  As you (the developers) I am sure know, printing is a
capital-intensive business.  That makes it difficult--especially for small
shops--to be continually investing in software and hardware.  OK, OK,
Scribus is free, but there is still time (=money) for training, even if it
for oneself.  "Stable" software, that is software that can access files from
older versions without user intervention, features that work the same from
day to day, month to month, and even year to year (among other issues) are
important to maintaining a high level of productivity.  And yes, I realize
that there are times when upgrades are not only appropriate, but necessary.
Frequent changes are not always a positive business model (however appealing
the technical model).

Now I know you have been working on this application for at least five
years, and are currently working on a new version.  As a (potential) user, I
would like to see, once the new version (1.3.5?) is released, that you spend
time cleaning up the bug reports and polishing the application to make it a
truly effective package for the printing industry.  I wish I had had
something like Scribus when I was in the business.

But that gets me back to my original question;  what is your goal?  From
other posts, I conclude that others have the same question.  Perhaps it is
to continue with the software development as a technical and intellectual
project, and not provide a "finished" product.  Well . . . that is certainly
OK.  If so, more power to you.  I certainly don't have the knowledge or
skills to create anything even close to what you have already created.  Yes,
I saw the number of downloads of Scribus, but, for the reasons I have
presented here, I don't consider that as evidence of a finished product.  I
would definitely like to see a finished product--I am convinced the industry
could benefit from your work on a much greater scale.

Again, and just out of curiosity, what is your goal for this application?
Please note, that whatever it is, I wish you much future success.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.info/pipermail/scribus/attachments/20080831/511078ae/attachment.htm>
_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[Gregory Pittman]

Mike Morris wrote:

> I am new to Scribus, but not to DTP.  I have been exploring Scribus, and I
> am an avid reader of the mailing list messages. I am using Scribus
> 1.3.3.11on a Windows XP platform. My question for the developers is a
> result of the
> many comments and questions posted over the past month on such topics as who
> is (or should be) using Scribus, and such features as imposition, color
> management, printing, and even spell checking.
>
> The question:  What is the goal of the developers?
>  

I am not one of the developers, but have been on the sidelines from some
time, and am one of those working on our manual. For a question like
this, you probably need several answers from various members.
The way I see the development having taken place, the emphasis has at
first been on high-quality output from the program: making PDFs
compliant to the standards set by Adobe, including color management, and
including the ability to use high-level components (ie, various image
formats) to work with for this DTP work, primarily with commercial
printing in mind. Consequently, things like imposition were not primary
goals. Some things, such as being able to embed a PDF within Scribus,
while desirable, are major tasks and will simply take time to accomplish.
The current development series, 1.3.5svn, is a major step forward in
usability, and incorporates of a number of things such as those you
mention that others have indicated are more or less essential. It is at
least hoped that the file format at this point will be more stable,
which should help create a greater sense of comfort for users. The
upcoming manual should also help, since it will explain a lot about
using Scribus heretofore not well-documented or not documented at all.
Since there are many things to be worked on, and a limited number of
developers available to do the work, decisions have to be made about
where to focus energy and time.

I saw an interchange posted on kerneltrap.org between Linus Torvalds and
some other developers, when they were wondering if they could stop
incorporating new features for a while, so that they could stop to fix
all the bugs before moving on. Linus replied that to artificially stop
new features would mean the death of the project, and in reality, you
can't stop this from happening. Projects develop a life of their own
outside of the desires of the individuals working on them. You can't
tell people to stop working on something they're intently interested in,
and making positive contributions about.
If you look around at the many projects that might in some sense be
considered "stable", no one is working on them anymore. They stopped at
version 0.9, because the developer(s) lost interest.

All in all, I think Scribus is a remarkable thing. A number of people
scattered across the globe continue to work on this project begun by
Franz Schmid, all trying to advance it with no significant monetary gain
in sight.

Greg

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[Mike Morris-12]

On Sun, Aug 31, 2008 at 4:37 PM, Gregory Pittman <gpittman@...> wrote:

> Mike Morris wrote:
>
>> I am new to Scribus, but not to DTP.  I have been exploring Scribus, and I
>> am an avid reader of the mailing list messages. I am using Scribus
>> 1.3.3.11on a Windows XP platform. My question for the developers is a
>> result of the
>> many comments and questions posted over the past month on such topics as
>> who
>> is (or should be) using Scribus, and such features as imposition, color
>> management, printing, and even spell checking.
>>
>> The question:  What is the goal of the developers?
>>
>>
> I am not one of the developers, but have been on the sidelines from some
> time, and am one of those working on our manual. For a question like this,
> you probably need several answers from various members.
> The way I see the development having taken place, the emphasis has at first
> been on high-quality output from the program: making PDFs compliant to the
> standards set by Adobe, including color management, and including the
> ability to use high-level components (ie, various image formats) to work
> with for this DTP work, primarily with commercial printing in mind.
> Consequently, things like imposition were not primary goals. Some things,
> such as being able to embed a PDF within Scribus, while desirable, are major
> tasks and will simply take time to accomplish.
> The current development series, 1.3.5svn, is a major step forward in
> usability, and incorporates of a number of things such as those you mention
> that others have indicated are more or less essential. It is at least hoped
> that the file format at this point will be more stable, which should help
> create a greater sense of comfort for users. The upcoming manual should also
> help, since it will explain a lot about using Scribus heretofore not
> well-documented or not documented at all.
> Since there are many things to be worked on, and a limited number of
> developers available to do the work, decisions have to be made about where
> to focus energy and time.
>
> I saw an interchange posted on kerneltrap.org between Linus Torvalds and
> some other developers, when they were wondering if they could stop
> incorporating new features for a while, so that they could stop to fix all
> the bugs before moving on. *Linus replied that to artificially stop new
> features would mean the death of the project*, and in reality, you can't
> stop this from happening.

Interesting thought.  And , as an ex-engineer, understandable . . . yet I
consider Open Office (at least the word processor) as a "finished" product.
Perhaps the corporate involvement in Open Office provides the additional
resources, of the right kind, to "finish"  the product.

> Projects develop a life of their own outside of the desires of the
> individuals working on them. You can't tell people to stop working on
> something they're intently interested in, and making positive contributions
> about.
> If you look around at the many projects that might in some sense be
> considered "stable", no one is working on them anymore. They stopped at
> version 0.9, because the developer(s) lost interest.
>
> All in all, I think Scribus is a remarkable thing. A number of people
> scattered across the globe continue to work on this project begun by Franz
> Schmid, all trying to advance it with no significant monetary gain in sight.

Thank you for your response.  Perhaps Scribus will always remain a work in
process.  If Linus Torvalds is correct, that is probably a good thing for
the capabilities of the application.  Although, in my opinion, that will
limit the impact of Scribus on the industry.  Despite that, I agree that
"...Scribus is a remarkable thing."  Thanks to the developers for the work
so far.  I would like to hear from any of the developers willing to take a
moment from their busy schedule on this issue.

>
>
> Greg
>
> _______________________________________________
> scribus mailing list
> scribus@...
> http://lists.scribus.info/mailman/listinfo/scribus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.info/pipermail/scribus/attachments/20080901/53755c71/attachment.htm>
_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[Craig Bradney-2]

Hi Mike

> The question:  What is the goal of the developers?

I think the best answer is to produce a DTP/layout/assembly (your
definitions you mentioned) program of professional quality - to allow users
to be able to replace other apps on Linux, and compete with those same apps
on OSX and Windows (and any other platform for that matter).

That puts Scribus with an aim to reach to the stars, where in the
professional world, the liftoff and man hours are provided by those well
known companies to get them there, and about 10 years advance over Scribus.

As for imposition, as you specifically mentioned it, as I have rarely come
across a print shop that wanted it done for them - it is a little hard to
place in terms of requirement. We certainly see the need for the basics for
those wanting to replace the functionality in say MS Pub, but to go all the
way and replace the software worth thousands specifically designed for
imposition.. well.. one day.. but maybe not on our first priority list.

So we skipped a few years, most people have reviewed Scribus at a "Quark 4"
level in most areas (on what, I cannot say right now). In some things, its
way ahead.

Yes it is true, we are currently 100% unfunded and 100% part-time. At this
point, that amounts to 4-8 hours per night, for up to about 8 people all
working full-time elsewhere. All in all, at this point, I would say with
busy schedules included, that 4-8 hours might be a maximum spent total per
day for the whole team. Without funding of some sort, this won't increase
unless we are on holidays from our real work. The time spent will also
increase once we get 1.3.5 done - its a major work that is just taking along
time to get finished up, and we will all party hard when 1.3.5 is finally
out the door.

As for stability - there is Scribus 1.3.3.x. We are making VERY few changes
to it. It works for many tasks and works well. There are bugs, and there are
issues in certain uses of the program, but it is pretty stable and usable.
No more new features are going into 1.3.3.x, and I do not expect we will
release anything after 1.3.3.13. 1.3.3.x can open all files from before it,
1.3.5svn should be able to open all files from before it.

1.3.5svn is what is being worked on and we really are working on a lot of
small finishing touches, while slowly working through any major issues
outstanding. Looking at the bug tracker open bug count is a little deceiving
- many of those bugs, or specifically features, just wont be fixed until we
are at something like Scribus 1.6 or 3.0 (random guess). People do dream up
wonderful ideas but many take a long time to do, or require substantial
underlying changes to be even able to start on them.


> Now I know you have been working on this application for at least five
> years, and are currently working on a new version.  As a (potential) user,
I
> would like to see, once the new version (1.3.5?) is released, that you
spend
> time cleaning up the bug reports and polishing the application to make it
a
> truly effective package for the printing industry.  I wish I had had
> something like Scribus when I was in the business.

You will find that many of the bugs in 1.3.3.x are already fixed in 1.3.5,
including many small usability issues. Including issues created by 1.3.5
itself (moving to a new toolkit, rewriting the canvas somewhat, etc), 1.3.5
includes fixes for well over 1000 bugs. We used to do 30-100 per release
maximum - 1.3.5 has covered a LOT of ground.

Future development releases post 1.3.5 will be short (around 3m) and will
allow us to have smaller targets, and allow added projects into the
development codebase (eg GSoC additions). Eventually we will release this
codebase into a new stable series.

Craig



_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[Mr. Beast]

I consider the imposition feature (akin to pagemaker's "build booklet")
an important step forward for Scribus. While the printshops I deal with
may be happy to impose multiple copies of one or two images on a large
sheet. When it comes to two up double sided sorts of printing they want
it already done so that all they have to do is hit print.
Cheers,
B

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[alpha1]

--- On Mon, 9/1/08, Craig Bradney <cbradney@...> wrote:
From: Craig Bradney <cbradney@...>
Subject: Re: [scribus] The Scribus target - a question for the developers
To: "Mike Morris" <scribus@...>, "scribus@..." <scribus@...>
Date: Monday, September 1, 2008, 7:20 AM

Hi Mike

> The question:  What is the goal of the developers?

As for imposition, as you specifically mentioned it, as I have rarely come
across a print shop that wanted it done for them - it is a little hard to
place in terms of requirement. We certainly see the need for the basics for
those wanting to replace the functionality in say MS Pub, but to go all the
way and replace the software worth thousands specifically designed for
imposition.. well.. one day.. but maybe not on our first priority list.
<snip>
Craig

---
When I first started trying Scribus only a few short weeks ago, one of the things that I felt was missing was "imposition", although I had never heard of the term before.  I was just wanting to produce simple "2-up" documents.  However, now that I have learned a bit more about Desktop Publishing in general, and Scribus in particular, I realize that there is probably little or no need for imposition capabilities within Scribus.  I just bought a new, low cost laser printer, and even it can do any imposition I am likely to want when I print it. Also, talking to local copy shops (i.e. mass market "print shops" using laser printers), they would rather do the imposition when they print the documents than have me do it before hand.

Thus I withdraw my earlier request for this feature as a priority item.

Murray




     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.info/pipermail/scribus/attachments/20080901/3df1c6ad/attachment.htm>
_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[Mike Morris-12]

Thanks to all of you who have responded to my earlier question on developer
goals.

Regarding the imposition capability, I offer the following thoughts (from a
former shop owner's perspective):

For certain items, such as business cards and letterheads (among other
items), it is true that I, as shop owner, preferred to do the imposition
in-house, rather than try to train my customers.  After all, how I would run
the job depended on its complexity and quantity, and even, to some extent,
on other jobs on order.  If a customer brought me (in those days) a
Pagemaker or Quark file, I would open the file and change the imposition so
that it would fit the way I wanted to run the job.

Now I know that the Multiple Duplicate feature in Scribus can accomplish
this task for such items--provided both customer AND shop have Scribus.
However, the Scribus development goals appear to exclude use in shops:

" As for imposition, as you specifically mentioned it, as I have rarely come
across a print shop that wanted it done for them - it is a little hard to
place in terms of requirement. We certainly see the need for the basics for
those wanting to replace the functionality in say MS Pub, but to go all the
way and replace the software worth thousands specifically designed for
imposition.. well.. one day.. but maybe not on our first priority list."

It is not clear to me how to change imposition, once defined in a PDF file.
I have been out of the printing business for several years, so perhaps there
is a way to change a PDF file with business cards set up as:

4 up on 5.5 x 8.5

to 4 up on 4 x 8 (one set up used for Thermography)--as one example.

Another example:  a customer brings in a PDF file of a letterhead.  It uses
3 spot colors with tight register and one of the spot colors is used in a
bleed bar at the top of the sheet (bleeds left, top and right).  The
quantity is 20,000.  I might want to run that  4 up on 11.5 x 17.5 or
perhaps 8 up on 23 x 35.  In this case, perhaps the ability of Scribus to
import PDF's will work.  But, if I correctly understand Scribus, I would
then need to create a PDF of the "imposed" document before I could send it
to the image setter.  Is that possible?

If not, the customer (or graphic designer) must have a detailed discussion
with the print shop before starting the project.  While that is normally
expected of a graphic designer--and I am certain that all contributors to
this list make the effort, my experience is that it is (or was) an
occurrence much rarer that it should have been.

As for multi-page documents (whether marketing documents or newsletters,
etc.),  whether they are created within the shop or by the customer (or
graphic designer), the imposition feature (or "booklet" feature) is an
important element of a true page layout software application--even if the
customer doesn't know the difference between "reader spreads" and "printer
spreads."  If I correctly understand the threads that have been posted on
this issue, there are work-arounds, but they are not as efficient as a true
"booklet" feature.  That means higher cost to the print shop and higher
prices to the customer--and possibly a non-competitive situation compared to
someone using InDesign or Quark.  Or lower profit to the shop using Scribus.

As I understand the current status of Scribus, the booklet feature can be
implemented with a plug-in (at least with the Linux version).  I use the
Windows version, and I have not tried this task.  Given the nature of the
Scribus development, this seems to be an acceptable alternative, but with
the reservations expressed above.

Despite my reservations, I wish to state once again, that I find the efforts
to date of the development team remarkable indeed.

On Mon, Sep 1, 2008 at 8:41 PM, Mr. Beast <mrbeast@...> wrote:

> I consider the imposition feature (akin to pagemaker's "build booklet") an
> important step forward for Scribus. While the printshops I deal with may be
> happy to impose multiple copies of one or two images on a large sheet. When
> it comes to two up double sided sorts of printing they want it already done
> so that all they have to do is hit print.
> Cheers,
> B
>
>
> _______________________________________________
> scribus mailing list
> scribus@...
> http://lists.scribus.info/mailman/listinfo/scribus
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.info/pipermail/scribus/attachments/20080901/a68e9be1/attachment.htm>
_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[John Jason Jordan-2]

On Mon, 1 Sep 2008 23:10:29 -0600
"Mike Morris" <twriterext@...> dijo:

> Regarding the imposition capability, I offer the following thoughts (from a
> former shop owner's perspective):

I print all my documents myself on laser. I specialize in short run
book publishing. Since I print on laser I print on individual sheets,
either US letter or tabloid. Thus, my imposition needs are minimal.

However, in the past I have had occasion to send print jobs to outside
printers. It seems to me that all print shops had commercial software
to impose PDF files. All I had to do was supply them with a PDF of the
document and they did the imposition. If this is still true, the only
kind of imposition Scribus needs is for people like me who print on
laser. For that matter, so far I have not had a problem imposing PDFs
using open source software, although sometimes it is difficult to
figure out how to use the software.

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[Craig Bradney-2]

>
> For certain items, such as business cards and letterheads (among other
> items), it is true that I, as shop owner, preferred to do the imposition
> in-house, rather than try to train my customers.  After all, how I would
run
> the job depended on its complexity and quantity, and even, to some extent,
> on other jobs on order.  If a customer brought me (in those days) a
> Pagemaker or Quark file, I would open the file and change the imposition
so
> that it would fit the way I wanted to run the job.
>
> Now I know that the Multiple Duplicate feature in Scribus can accomplish
> this task for such items--provided both customer AND shop have Scribus.
> However, the Scribus development goals appear to exclude use in shops:

Absolutely not. The "Scribus Development Goals" you talk about are currently
defined by the time we have, and as I said, that's about 4h per day total at
the moment, IF that. Goals and plans change depending on peoples' time
available. First things first.

It is 100% the aim to push Scribus documents into print shops, however in
all our experience with print shops (and we have many contacts with pro
printers out there across the world), most of them use very expensive
imposition tools that work with unimposed PDF files. This is part of the
move to PDF - you shouldn't need to care if the document came from Scribus
or Quark or wherever, it should be a well formed PDF (or whatever future
software-independent format).

It is therefore thought that we should spend our little spare time on more
day-to-day features, and usability aspects, etc.

Craig



_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[Lars O. Grobe]

Taking the open source nature and modularity of the free software world
into account, plus the pdf-centred workflow in Scribus (which reflects
what the industry is in at the moment imho), even though I needed it
some weeks ago - I think imposition is not a tool that has to be integrated.

In these pdf-days, you do not create a book any more in DTP - you create
a document. This can be viewed on screen, be printed in offset or on a
a4 laser printer - you do not know it when you create the pdf - and that
is the nature of a device independant document format.

We need a tool doing imposition, but this is its own step in the
workflow, and it is run when printing the document - without changing
it, as it depends on the device. So it is its own element in the chain.
Some folks have it already in their printer driver, some use unix
postscript tools. The big advantage is that the job of the one doing the
print-out, knowing the devices, doesn't collide with the job of the
document creator. And it does not matter if I create my pdf in Scribus,
Openoffice, Inkscape, Tex...

So maybe work has to be done on creating a really nice imposition tool,
with previews, templates, a very graphical GUI showing the user what is
going to happen. But I do not think that this should be part of Scribus,
Openoffice or any other creator tool. Actually there are already tools,
but the "perfect one" yet has to be developed ;-)

CU Lars.

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[John Culleton-3]

On Tuesday 02 September 2008 03:48:11 am Lars O. Grobe wrote:
> Taking the open source nature and modularity of the free software
> world into account, plus the pdf-centred workflow in Scribus (which
> reflects what the industry is in at the moment imho), even though I
> needed it some weeks ago - I think imposition is not a tool that
> has to be integrated.
>


I agree. When I have a Scribus file that needs rearrangement for e.g.,
booklet printing I use other utilities. Here is a real world  example
in a script:

psbook $1.ps $1b.ps
echo 'psnup'
psnup -2 -ptabloid -Pletter $1b.ps $1p.ps
echo 'psselect'
psselect -o   $1p.ps $1o.ps
psselect -e -r  $1p.ps $1e.ps
lpr $1o.ps
echo 'switch paper'
read x
lpr $1e.ps
rm $1p.ps $1e.ps $1o.ps $1b.ps

I am much more concerned with other issues, such as expanding the
paragraph setting capability to resemble that of TeX with optical
alignment and microtypography, and the abiity to put "distiller"
style tags in the pdf output so as to meet the requirements  of LSI,
the largest POD printer in the world.

--
John Culleton
Resources for every author and publisher:
http://wexfordpress.com/tex/shortlist.pdf
http://wexfordpress.com/tex/packagers.pdf
http://www.creativemindspress.com/newbiefaq.htm
http://www.gropenassoc.com/TopLevelPages/reference%20desk.htm

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[Gustavo Homem]

>
> Interesting thought.  And , as an ex-engineer, understandable . . . yet I
> consider Open Office (at least the word processor) as a "finished" product.
> Perhaps the corporate involvement in Open Office provides the additional
> resources, of the right kind, to "finish"  the product.

This is an interesting comment. Maybe we could breifly discuss why you
consider OpenOffice.org more "finished" than Scribus 1.3.3.12 (the stable
version).

I think your answer may provide useful insight.

Cheers
Gustavo

--
Angulo Sólido - Tecnologias de Informação
http://angulosolido.pt

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[John Jason Jordan-2]

On Wed, 3 Sep 2008 21:42:37 +0100
Gustavo Homem <gustavo@...> dijo:

> > Interesting thought.  And , as an ex-engineer, understandable . . . yet I
> > consider Open Office (at least the word processor) as a "finished" product.
> > Perhaps the corporate involvement in Open Office provides the additional
> > resources, of the right kind, to "finish"  the product.

> This is an interesting comment. Maybe we could breifly discuss why you
> consider OpenOffice.org more "finished" than Scribus 1.3.3.12 (the stable
> version).

I tend to agree that OOo is a more finished product. The reason I feel
that way is because of its standing in relation to its competitors.

In the case of OOo, that means MS Office and WordPerfect Office. OOo
has a small but significant market share compared to those two. In fact,
there are more OOo users than users of WordPerfect Office. At my
university all machines in student computer labs have OOo installed.

Another point is the feature parity. OOo pretty well matches its
competitors feature for feature. Sure, the buttons are in different
places and the look and feel is not quite the same, but just about
anything you can do in MS Office or WordPerfect Office can also be done
in OOo.

Now compare this to Scribus. When it comes to market share vs. our
competitors we have a long way to go to catch up to OOo. And when we
compare features with our competitors, we also have quite a ways to go.

I don't meant to demean Scribus or the efforts of the developers. The
longest journey begins with a single step. They have accomplished
amazing things in the time they have been working on Scribus.

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[Lars O. Grobe]

>> This is an interesting comment. Maybe we could breifly discuss why you
>> consider OpenOffice.org more "finished" than Scribus 1.3.3.12 (the stable
>> version).
>>    
;-) Do not forget that Scribus and OpenOffice have a completely
different history. OOo has its roots in a commercial product
(Staroffice, which followed the stand-alone Starwriter, and I remember
working using this tool back in 1993 ;-) ) which was made open-source
after being aquired by Sun. So it is an ongoing development of an Office
Suite that had already been complete in the 90s, with huge companies
contributing to it. You can compare its history somehow to Mozilla.

Yet I think that Scribus is a rather complete tool, too - for a given
workflow you can do all you need. Only to broaden that workflow,
additions may be needed. Besides that, all is about performance and
bug-fixing ;-)

CU Lars.

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[Gustavo Homem]

On Thursday 04 September 2008 05:05, John Jason Jordan wrote:

> On Wed, 3 Sep 2008 21:42:37 +0100
>
> Gustavo Homem <gustavo@...> dijo:
> > > Interesting thought.  And , as an ex-engineer, understandable . . . yet
> > > I consider Open Office (at least the word processor) as a "finished"
> > > product. Perhaps the corporate involvement in Open Office provides the
> > > additional resources, of the right kind, to "finish"  the product.
> >
> > This is an interesting comment. Maybe we could breifly discuss why you
> > consider OpenOffice.org more "finished" than Scribus 1.3.3.12 (the stable
> > version).
>
> I tend to agree that OOo is a more finished product. The reason I feel
> that way is because of its standing in relation to its competitors.

Well, the relation of a product the market is a complex one. The office suite
market is more permeable than the DTP one because it is less technical. Basic
users hardly notice the difference between OO and MSO.

My point was more about whether or not Scribus works as expected for all the
*basic usage* scenarios. I sometimes get the impression that while Scribus
has some very advanced features there are small annoying bugs in basic
operations that prevent it from looking more "finished". However I also feel
that this has been improving *a lot* with latest 1.3.3.X releases:

http://bugs.scribus.net/changelog_page.php

I tend to think that it may be important to maintain the stable branch for
quite some time in order to have a "finished produtct".

Cheers
Gustavo

--
Angulo Sólido - Tecnologias de Informação
http://angulosolido.pt

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus