[scribus] Jpeg Files and PNG files

[John Culleton]

On Wed, 29 Jul 2015 15:07:22 +0200
"a.l.e" <ale.comp_06 at xox.ch> wrote:

> hi john
> > Sorry John,
> >
> > I do not enjoy to contradict, but I need to
> > give credit to Scribus here:
> >
> > What you say about vectors being better is
> > true, but even in our workflow there are
> > occasions, where we can quickly do with a
> > high-rez PNG file, what would be complicated
> > with a PDF (for example just cut a page
> > precisely in Gimp and only print a portion).
> >
> > Scribus does have a great bitmap-export
> > dialogue and can generate many flavours:
> >
> > bmp, ico, jpeg, jpg, png, tif, tiff, ppm,
> > xbm, xpm
> >
> > You can also set the quality, resolution,
> > size and select which page or pages you need
> > to export.
> >
> > I love the fact, that I (now) have a choice
> > whether to name my files jpg or jpeg. Because
> > one of our websites has an import script with
> > a fixed naming-convention. In the past I
> > needed to batch-rename my Scribus exports but
> > now I can just generate exactly what I need.
> >
> > So, well done developers!
> >
> 
> on my side i love to contradict :-)
> 
> while i'm pleased to see your enthusiasm for
> being able to avoid the tedious post
> processing, sometimes i wonder if it would be
> not better for scribus to do one thing and do
> it well.
> 
> i mean: every line of code removed is a correct
> line of code, a line of code that has not to be
> maintained... we don't have huge resources
> available: it can make a difference! most of
> all if we start to apply this idea also to
> other parts of scribus....
> 
> being able to export a preview of the page is
> probably something useful, but i wonder if
> having more formats than png is really that
> useful... there are lot of good tools for doing
> the conversion!
> 
> personally, i would exchange bmp, ico, jpeg,
> jpg, tiff, ppm, xbm and xpm export against
> scribus 1.6 being published one day earlier :-)
> 

From my earliest days as a programmer (1968) I
always worked with in a subset of the language
that I knew well and could use effectively. I
agree that things done easily elsewhere can be
left out of Scribus. I used to use a neat little
web page creation program called Quanta Plus
(part of the KDE suite) that did one thing and
did it well. Then the author decided to extend
it to cover the waterfront of application
editing. I no longer use it. I can use a plain
text editor like Gvim instead.
 
The same error extends to the entire KDE suite,
with a mail program in KDE4 that didn't work
initially because of a tie-in with a general
personal data program not needed to run the mail
program. Integration of apps is often more a
hindrance than a help. I call it the Microsoft
Windows error.

In Scribus I am concerned about facets like a
manual that is both too thick and woefully out
of date. Also a screen presentation with 50 or
more icons is a bit of a turn-off for Joe or
Jane Newbies.

There are areas in the Desk Top Program area
that need attention with respect to Scribus. 
Speed of execution on long documents is one.
A clumsy TOC system is another. Indexing is a
third. When discussing Scribus I refer
developers to the corresponding features in
TeX not because I want to convert users to that
program but because I want to leave TeX behind
(after a decade or more of use). On my current
project I did it in Context first, but as more
and more pages needed massaging with inserts,
tables and the like I end up using Scribus on
individual pages.But I still used Context for
generation of the TOC and plain pdftex for index
generation. 

As one of my supervisors told me years ago
we need to distinguish between "nice to have"
and "got to have." These gnarly things like
TOC and Index are worthy of attention not
because they are easy to implement but because
they are difficult.   
-- 
John Culleton
Wexford Press
Book layout, typesetting and Indexing
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html