From cbradney at scribus.info  Wed Dec 10 22:34:02 2014
From: cbradney at scribus.info (Craig Bradney)
Date: Wed, 10 Dec 2014 23:34:02 +0100
Subject: [scribus-dev] Is there a plan for a releasing cycle of 1.5 ?
In-Reply-To: <5AE5AADC-42D7-45FF-B48A-A50CF2591DC7@scribus.info>
References: <CAAt0FRiLsyyRgFZOmAvKzAcSF5zdvwn7jia2U2rz+GwJSW8Dmg@mail.gmail.com>
 <F7C693C6-C4E0-4FE7-8AA9-1F9D5B980FAF@scribus.info>
 <A9D3594B-4211-4CBF-A4E6-6FC1441E889C@gmail.com>
 <546E3BC6.9060504@scribus.info>
 <5AE5AADC-42D7-45FF-B48A-A50CF2591DC7@scribus.info>
Message-ID: <A7578CC2-4839-4290-AE38-D11BDFBEB0F9@scribus.info>


> On 20 Nov 2014, at 23:07, Craig Bradney <cbradney at scribus.info> wrote:
> 
>> 
>> On 20 Nov 2014, at 8:06 pm, Craig Bradney <cbradney at scribus.info> wrote:
>> 
>> On 20/11/2014 6:47 pm, Andreas Vox wrote:
>>> Am 20.11.2014 um 15:02 schrieb Craig Bradney:
>>> 
>>>> Consider features as frozen now. We've been doing only bug fixes for ages.
>>>> 
>>>> However, we can't package for OSX, so I can't see how we can set a date. I'm working on that but still no major breakthroughs.
>>>> 
>>> What's the problem exactly?
>>> 
>>> 
>> 
>> 
>> Your scripts don't work anymore. Ie, they work but the app just crashes when it moves to another
>> machine. I'm building and testing on Qt 5.3.2 on OSX 10.10 with XCode 6.1. I have no plans to
>> release a lower version until I can release 10.10 based version.
>> 
>> macdylibbundler works for dylibs but not frameworks. We need frameworks at this point for linguist
>> tools and webkit (used in about/upgradechecker and help browser).
>> 
>> https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW13
>> says everything (libs/frameworks) needs to be under $app/Contents/Frameworks, so I've built a new
>> version last night to test tonight..
>> 
> 
> 
> New locations didn?t help with your script.. 
> 
> Craig
> 


New process found.. macdeployqt solves the libqcocoa problems, then sort the plugins for our plugins (e.g. libhunspell), then fix the names in our libs for the Qt plugins.

Voila.. I can now deploy 1.5 from my Yosemite machine to a vanilla Yosemite virt.

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20141210/e683a23f/attachment.html>

From cbradney at scribus.info  Wed Dec 10 22:52:17 2014
From: cbradney at scribus.info (Craig Bradney)
Date: Wed, 10 Dec 2014 23:52:17 +0100
Subject: [scribus-dev] Is there a plan for a releasing cycle of 1.5 ?
In-Reply-To: <A7578CC2-4839-4290-AE38-D11BDFBEB0F9@scribus.info>
References: <CAAt0FRiLsyyRgFZOmAvKzAcSF5zdvwn7jia2U2rz+GwJSW8Dmg@mail.gmail.com>
 <F7C693C6-C4E0-4FE7-8AA9-1F9D5B980FAF@scribus.info>
 <A9D3594B-4211-4CBF-A4E6-6FC1441E889C@gmail.com>
 <546E3BC6.9060504@scribus.info>
 <5AE5AADC-42D7-45FF-B48A-A50CF2591DC7@scribus.info>
 <A7578CC2-4839-4290-AE38-D11BDFBEB0F9@scribus.info>
Message-ID: <F3E7D235-00AB-4167-B5E4-CE43267437B6@scribus.info>

>> 
> 
> 
> New process found.. macdeployqt solves the libqcocoa problems, then sort the plugins for our plugins (e.g. libhunspell), then fix the names in our libs for the Qt plugins.
> 
> Voila.. I can now deploy 1.5 from my Yosemite machine to a vanilla Yosemite virt.
> 

Even better, I found out how to do it with just macdeployqt now..

Craig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20141210/22fa409c/attachment.html>

From cbradney at zip.com.au  Tue Dec 16 06:10:03 2014
From: cbradney at zip.com.au (Craig Bradney)
Date: Tue, 16 Dec 2014 07:10:03 +0100
Subject: [scribus-dev] Scribus 1.5.0.svn DMG
Message-ID: <06ECBCB2-89A3-45BC-9883-C608EAE05695@zip.com.au>

Hi

I?ve uploaded a Yosemite built and compatible DMG for 1.5.0.svn to https://sourceforge.net/projects/scribus/files/scribus-svn/1.5.0.svn/ <https://sourceforge.net/projects/scribus/files/scribus-svn/1.5.0.svn/>

Give it a go. shamus is 3ffc0a4ba25544bce4069b3b551b54667be51628 as confirmed by source forge. Checked locally with ClamXav.

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20141216/fedd2cff/attachment.html>

From cbradney at scribus.info  Tue Dec 16 06:22:32 2014
From: cbradney at scribus.info (Craig Bradney)
Date: Tue, 16 Dec 2014 07:22:32 +0100
Subject: [scribus-dev] Scribus 1.5.0.svn DMG
In-Reply-To: <06ECBCB2-89A3-45BC-9883-C608EAE05695@zip.com.au>
References: <06ECBCB2-89A3-45BC-9883-C608EAE05695@zip.com.au>
Message-ID: <879E50B0-2851-4715-8830-01C7A78FF068@scribus.info>

> 
> Hi
> 
> I?ve uploaded a Yosemite built and compatible DMG for 1.5.0.svn to https://sourceforge.net/projects/scribus/files/scribus-svn/1.5.0.svn/ <https://sourceforge.net/projects/scribus/files/scribus-svn/1.5.0.svn/>
> 
> Give it a go. shamus is 3ffc0a4ba25544bce4069b3b551b54667be51628 as confirmed by source forge. Checked locally with ClamXav.
> 

Err.. sha1sum.. 

Craig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20141216/027e763b/attachment.html>

From cbradney at scribus.info  Tue Dec 16 21:33:00 2014
From: cbradney at scribus.info (Craig Bradney)
Date: Tue, 16 Dec 2014 22:33:00 +0100
Subject: [scribus-dev] Announce: String Freeze for Scribus 1.4.5
Message-ID: <FA4381EC-7FB3-4C8C-B09B-799C9A930926@scribus.info>

Hi All Translators

Please note that we are announcing a string freeze for translation of the Scribus GUI for the
1.4.5 release. Updated TS files have been committed to SVN and are available now for download.

Use http://scribus.net/websvn/listing.php?repname=Scribus&path=%2Fbranches%2FVersion14x%2FScribus%2Fresources%2Ftranslations%2Fpo%2F&#aafe89d05739d7488c7fa195a550a9a0e <http://scribus.net/websvn/listing.php?repname=Scribus&path=/branches/Version14x/Scribus/resources/translations/po/&#aafe89d05739d7488c7fa195a550a9a0e> for a direct link for those that don't check out SVN regularly otherwise.

Please submit updated TS files to bugs.scribus.net <http://bugs.scribus.net/> - compress them and upload them into a new bug.
Please only include the TS file.

The time available for the string updates is from now until December 31st.

Thanks
Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20141216/e58c23a0/attachment.html>

From John at wexfordpress.com  Wed Dec 17 18:47:55 2014
From: John at wexfordpress.com (John Culleton)
Date: Wed, 17 Dec 2014 13:47:55 -0500
Subject: [scribus-dev] Need help with python script
Message-ID: <20141217134755.1a57aca8@localb.wexfordpress.net>

I have taken the script spine.py as a starting
point and am creating a new script which is
intended to create a book cover template. It will
serve the same function as the Perfect Bound
Cover extension of Inkscape. Instead of just
printing out values as the spine.py script does
and my own perl-based online template maker does
it will actually create the page with correct
overall dimensions plus guides for the spine
location etc.

Since I am a USA guy I will be dealing in inches
to the degree possible. 

First, is this doable from a python script?

Second, after I have calculated the overall cover
width and height what statements do I need to use
to reset the overall width and height of the
current document. In other words:

??? = W
and
!!! = H

Where ??? and !!! are the addresses of the
appropriate Scribus parameters. 

I need a similar address for placing a vertical
guide on the document. There will be several of
these.

If there is a document somewhere that lists all
the pertinent addresses used in Scribus please
point me in that direction.

I am a beginner with Python but I do have some
years of programming under my belt. I can 
RTFM.

Your assistance is appreciated!

-- 
John Culleton
Wexford Press
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html
Updated PDF e-book: "Create Book Covers with
Scribus 1.4.5" coming soon at
http://www.booklocker.com/!


From jluc at no-log.org  Wed Dec 17 21:11:33 2014
From: jluc at no-log.org (JLuc)
Date: Wed, 17 Dec 2014 22:11:33 +0100
Subject: [scribus-dev] Need help with python script
In-Reply-To: <20141217134755.1a57aca8@localb.wexfordpress.net>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
Message-ID: <m6sri5$8s1$1@ger.gmane.org>

Hello

great project !

In http://wiki.scribus.net/canvas/Generate_a_ten_page_layout_with_three_columns_on_each_page
i see
newDoc((185, 250), (12, 20, 15, 28), PORTRAIT, 1, UNIT_MILLIMETERS, FACINGPAGES, FIRSTPAGELEFT)

I'm not sure it fits your needs but you might find what you look for
in other available public scripts ?

JL

Le 17/12/2014 19:47, John Culleton a ?crit :
> I have taken the script spine.py as a starting
> point and am creating a new script which is
> intended to create a book cover template. It will
> serve the same function as the Perfect Bound
> Cover extension of Inkscape. Instead of just
> printing out values as the spine.py script does
> and my own perl-based online template maker does
> it will actually create the page with correct
> overall dimensions plus guides for the spine
> location etc.
>
> Since I am a USA guy I will be dealing in inches
> to the degree possible.
>
> First, is this doable from a python script?
>
> Second, after I have calculated the overall cover
> width and height what statements do I need to use
> to reset the overall width and height of the
> current document. In other words:
>
> ??? = W
> and
> !!! = H
>
> Where ??? and !!! are the addresses of the
> appropriate Scribus parameters.
>
> I need a similar address for placing a vertical
> guide on the document. There will be several of
> these.
>
> If there is a document somewhere that lists all
> the pertinent addresses used in Scribus please
> point me in that direction.
>
> I am a beginner with Python but I do have some
> years of programming under my belt. I can
> RTFM.
>
> Your assistance is appreciated!
>




From gpittman at iglou.com  Thu Dec 18 00:09:32 2014
From: gpittman at iglou.com (Gregory Pittman)
Date: Wed, 17 Dec 2014 19:09:32 -0500
Subject: [scribus-dev] Need help with python script
In-Reply-To: <m6sri5$8s1$1@ger.gmane.org>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org>
Message-ID: <54921B3C.2070402@iglou.com>

On 12/17/2014 04:11 PM, JLuc wrote:
> Hello
> 
> great project !
> 
> In
> http://wiki.scribus.net/canvas/Generate_a_ten_page_layout_with_three_columns_on_each_page
> 
> i see
> newDoc((185, 250), (12, 20, 15, 28), PORTRAIT, 1, UNIT_MILLIMETERS,
> FACINGPAGES, FIRSTPAGELEFT)
> 

If you look at the online manual, you can see that newDoc is deprecated.

Use instead newDocument().

If you use the preferred statement* early in your script:

import scribus

then remember to tell python where to look for commands and constants
with a prefix of 'scribus.', for example:

scribus.newDocument((width, height), (0.25, 0.25, 0.25, 0.25),
scribus.PORTRAIT, 1, scribus.UNIT_INCHES, scribus.PAGE_1, 0, 1)

where width and height are your values for your cover. I am presuming
that even though the width may be larger than height, you want a
PORTRAIT orientation to most easily work with the cover.
The (0.25, 0.25, 0.25, 0.25) specifies margins and could all be zeros if
you don't want any. These parenthetical groups of values are how you
present tuples to the scribus command.
Note that this command returns a boolean response, so you might have
if (scribus.newDocument(...............)):
followed by some things you might want to do to the document, like
adding the vertical guides.

Make vertical guides with:

scribus.setVGuides([v1, v2, v3, ...])

where these represent the distance in your page units from the left edge
of the page. The brackets denote that these values are part of a python
list.

As you may know, instead of the obligatory ';' that Perl uses at the
ends of lines, Python uses nothing. Instead it is very strict about the
use of indentation to understand the structure of your script.

Greg

*You may also see some scripts on the wiki begin with

from scribus import *

which allows you to use commands without the prefix, but what it does is
load all of Scribus's python commands, which really isn't necessary.


From John at wexfordpress.com  Thu Dec 18 13:49:31 2014
From: John at wexfordpress.com (John Culleton)
Date: Thu, 18 Dec 2014 08:49:31 -0500
Subject: [scribus-dev] Need help with python script
In-Reply-To: <54921B3C.2070402@iglou.com>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
Message-ID: <20141218084931.57daa6f8@localb.wexfordpress.net>

On Wed, 17 Dec 2014 19:09:32 -0500
Gregory Pittman <gpittman at iglou.com> wrote:

> On 12/17/2014 04:11 PM, JLuc wrote:
> > Hello
> > 
> > great project !
> > 
> > In
> > http://wiki.scribus.net/canvas/Generate_a_ten_page_layout_with_three_columns_on_each_page
> > 
> > i see
> > newDoc((185, 250), (12, 20, 15, 28),
> > PORTRAIT, 1, UNIT_MILLIMETERS, FACINGPAGES,
> > FIRSTPAGELEFT)
> > 
> 
> If you look at the online manual, you can see
> that newDoc is deprecated.
> 
> Use instead newDocument().
> 
> If you use the preferred statement* early in
> your script:
> 
> import scribus
> 
> then remember to tell python where to look for
> commands and constants with a prefix of
> 'scribus.', for example:
> 
> scribus.newDocument((width, height), (0.25,
> 0.25, 0.25, 0.25), scribus.PORTRAIT, 1,
> scribus.UNIT_INCHES, scribus.PAGE_1, 0, 1)
> 
> where width and height are your values for your
> cover. I am presuming that even though the
> width may be larger than height, you want a
> PORTRAIT orientation to most easily work with
> the cover. The (0.25, 0.25, 0.25, 0.25)
> specifies margins and could all be zeros if you
> don't want any. These parenthetical groups of
> values are how you present tuples to the
> scribus command. Note that this command returns
> a boolean response, so you might have if
> (scribus.newDocument(...............)):
> followed by some things you might want to do to
> the document, like adding the vertical guides.
> 
> Make vertical guides with:
> 
> scribus.setVGuides([v1, v2, v3, ...])
> 
> where these represent the distance in your page
> units from the left edge of the page. The
> brackets denote that these values are part of a
> python list.
> 
> As you may know, instead of the obligatory ';'
> that Perl uses at the ends of lines, Python
> uses nothing. Instead it is very strict about
> the use of indentation to understand the
> structure of your script.
> 
> Greg
> 
> *You may also see some scripts on the wiki
> begin with
> 
> from scribus import *
> 
> which allows you to use commands without the
> prefix, but what it does is load all of
> Scribus's python commands, which really isn't
> necessary.
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
> 
> 
> _______________________________________________________
> Unlimited Disk, Data Transfer, PHP/MySQL Domain
> Hosting http://www.doteasy.com 
Thanks for your comments. Yesterday I had a
program that ran, based largely on spine.py. It
delivers a doc with the right dimensions. I am
surprised at my success with a language I have
never used before, even with wholesale copying
from other people's programs.

 Three things need fixing. I need to figure out how to
put the blue lines in the right place to mark
off the spine area. You offered a solution above.
I need to get the commentary lines at the bottom
of the script to work correctly with my data. And
it would be nice if the data entry fields were on
one window instead of a series of windows. 

Today I have a column to write (It's my
deadline), a dog to take to the vets (maybe) and
finish preparation for the annual family party on
Sunday.

Maybe tomorrow?

Where in the manuals(online or printed) would I
find some extra guidance on these matters?
I looked but did not find. 
-- 
John Culleton
Wexford Press
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html
Updated PDF e-book: "Create Book Covers with
Scribus 1.4.5" coming soon at
http://www.booklocker.com/!


From gpittman at iglou.com  Thu Dec 18 15:38:35 2014
From: gpittman at iglou.com (Gregory Pittman)
Date: Thu, 18 Dec 2014 10:38:35 -0500
Subject: [scribus-dev] Need help with python script
In-Reply-To: <20141218084931.57daa6f8@localb.wexfordpress.net>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net>
Message-ID: <5492F4FB.60003@iglou.com>

On 12/18/2014 08:49 AM, John Culleton wrote:
> On Wed, 17 Dec 2014 19:09:32 -0500
> Gregory Pittman <gpittman at iglou.com> wrote:
> 
>> On 12/17/2014 04:11 PM, JLuc wrote:
>>> Hello
>>>
>>> great project !
>>>
>>> In
>>> http://wiki.scribus.net/canvas/Generate_a_ten_page_layout_with_three_columns_on_each_page
>>>
>>> i see
>>> newDoc((185, 250), (12, 20, 15, 28),
>>> PORTRAIT, 1, UNIT_MILLIMETERS, FACINGPAGES,
>>> FIRSTPAGELEFT)
>>>
>>
>> If you look at the online manual, you can see
>> that newDoc is deprecated.
>>
>> Use instead newDocument().
>>
>> If you use the preferred statement* early in
>> your script:
>>
>> import scribus
>>
>> then remember to tell python where to look for
>> commands and constants with a prefix of
>> 'scribus.', for example:
>>
>> scribus.newDocument((width, height), (0.25,
>> 0.25, 0.25, 0.25), scribus.PORTRAIT, 1,
>> scribus.UNIT_INCHES, scribus.PAGE_1, 0, 1)
>>
>> where width and height are your values for your
>> cover. I am presuming that even though the
>> width may be larger than height, you want a
>> PORTRAIT orientation to most easily work with
>> the cover. The (0.25, 0.25, 0.25, 0.25)
>> specifies margins and could all be zeros if you
>> don't want any. These parenthetical groups of
>> values are how you present tuples to the
>> scribus command. Note that this command returns
>> a boolean response, so you might have if
>> (scribus.newDocument(...............)):
>> followed by some things you might want to do to
>> the document, like adding the vertical guides.
>>
>> Make vertical guides with:
>>
>> scribus.setVGuides([v1, v2, v3, ...])
>>
>> where these represent the distance in your page
>> units from the left edge of the page. The
>> brackets denote that these values are part of a
>> python list.
>>
>> As you may know, instead of the obligatory ';'
>> that Perl uses at the ends of lines, Python
>> uses nothing. Instead it is very strict about
>> the use of indentation to understand the
>> structure of your script.
>>
>> Greg
>>
>> *You may also see some scripts on the wiki
>> begin with
>>
>> from scribus import *
>>
>> which allows you to use commands without the
>> prefix, but what it does is load all of
>> Scribus's python commands, which really isn't
>> necessary.
>>
>> _______________________________________________
>> scribus-dev mailing list
>> scribus-dev at lists.scribus.net
>> http://lists.scribus.net/mailman/listinfo/scribus-dev
>>
>>
>> _______________________________________________________
>> Unlimited Disk, Data Transfer, PHP/MySQL Domain
>> Hosting http://www.doteasy.com 
> Thanks for your comments. Yesterday I had a
> program that ran, based largely on spine.py. It
> delivers a doc with the right dimensions. I am
> surprised at my success with a language I have
> never used before, even with wholesale copying
> from other people's programs.
> 
>  Three things need fixing. I need to figure out how to
> put the blue lines in the right place to mark
> off the spine area. You offered a solution above.
> I need to get the commentary lines at the bottom
> of the script to work correctly with my data. And
> it would be nice if the data entry fields were on
> one window instead of a series of windows. 
> 
> Today I have a column to write (It's my
> deadline), a dog to take to the vets (maybe) and
> finish preparation for the annual family party on
> Sunday.
> 
> Maybe tomorrow?
> 
> Where in the manuals(online or printed) would I
> find some extra guidance on these matters?
> I looked but did not find. 
> 
In the online manual (F1), look under For Developers > Scripter API.
The detail and presence of examples is limited. Beyond that, going to
the wiki and looking at various example scripts that show more
specifically how to use the various commands is sometimes essential.
Make sure you go back to the online manual, though, to make sure some
command hasn't changed (like the deprecation of newDoc()).

Greg


From John at wexfordpress.com  Thu Dec 18 20:18:45 2014
From: John at wexfordpress.com (John Culleton)
Date: Thu, 18 Dec 2014 15:18:45 -0500
Subject: [scribus-dev] cover.py script for perfect bound book cover
 design is ready.
In-Reply-To: <5492F4FB.60003@iglou.com>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net>
 <5492F4FB.60003@iglou.com>
Message-ID: <20141218151845.006563fa@localb.wexfordpress.net>


With the very welcome advice of JLuc and
Gregory Pittman and the availability of the
spine.py script as a model I have a production
version of the script cover.py.

In gross this script terms does what what the
Perfect Bound Cover extension does for Inkscape
users and what my previous template.html did in
more limited fashion for Scribus users. 

The data fields are:
1. Number of pages
2. Pages per inch (PPI) of the interior pages.
3. Finished book width.
4. Finished book height
5. Allowance for the thickness of the cover
stock plus some additional distance for the fold. 
A recommended value is 0.017 inch.

The one improvement that I see as useful would be
to combine all the data entry fields into one
window instead of producing a separate window
sequentially for each data field. I don't know
how to do this.

When the fields are filled out a base document
correctly sized becomes the current document for
Sribus. 

FEATURES
There are two vertical guides marking off
the edges of the spine. There are also vertical
guides bisecting  the back cover, the
spine and the front cover.

There are solid blue margins spaced 0.375 inch
from each edge. These margin guides are designed
to prevent text and similar entities from
approaching too close to the finished edges. The
distance consists of the bleed of 0.125 inch plus
a safety margin of 0.250 inch. 

I tested it with Scribus 1.4.5, 1.5.0. 
Now who wants a copy of the script to bash it
around before I submit it for inclusion with the 
two releases? I'll post it at
http://wexfordpress.net 
Your comments are most welcome.

BTW my draft update of the e-book mentioned below
suddenly go a lot simpler.


John Culleton
Wexford Press
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html
Updated PDF e-book: "Create Book Covers with
Scribus 1.4.5" coming soon at
http://www.booklocker.com/!


From louis.desjardins at gmail.com  Thu Dec 18 22:11:39 2014
From: louis.desjardins at gmail.com (Louis Desjardins)
Date: Thu, 18 Dec 2014 17:11:39 -0500
Subject: [scribus-dev] cover.py script for perfect bound book cover
 design is ready.
In-Reply-To: <20141218151845.006563fa@localb.wexfordpress.net>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net>
 <5492F4FB.60003@iglou.com>
 <20141218151845.006563fa@localb.wexfordpress.net>
Message-ID: <CAM9PYkbU6Yfmc0sxp7jJaZOyu2DhEokmHCZaFsmjeoYTd5i6bw@mail.gmail.com>

Hi John,

I am very pleased to see that this awesome idea made it into a usable
script! It?s great.

I haven?t had the time to test the script but by your notes, a question
came across my mind:
Does (or can) the script create a small text frame to show the data used to
create the pages in human reading? In other words, to make the
communication complete between the actors of the graphic chain, a summary
of those values, including the resulting value for the spine, printed just
below the horizontal crop marks? This could include a few other values from
fields like Name of job, number of pages, date of creation, the mention
"Made with Scribus & the Script cover.py", etc.

This would allow quality control on any value and if there are any changes,
it?s easy to tell if a value is still valid or not and if the proof we have
in hand still corresponds to the reality of the job.

Subsidiary question:
While I am happy to see the PPI there, some printers will simply give the
spine value and thus could the user be given the choice of entering either
values (mutually exclusive) to obtain the desired result?

Are there plans to add an option of the flaps?

I like the security margins. Does the user get an electrical shock when
text is placed too close to the edge? :-D

Many thanks for this work and to all who gave a hand!

Louis

2014-12-18 15:18 GMT-05:00 John Culleton <John at wexfordpress.com>:
>
>
> With the very welcome advice of JLuc and
> Gregory Pittman and the availability of the
> spine.py script as a model I have a production
> version of the script cover.py.
>
> In gross this script terms does what what the
> Perfect Bound Cover extension does for Inkscape
> users and what my previous template.html did in
> more limited fashion for Scribus users.
>
> The data fields are:
> 1. Number of pages
> 2. Pages per inch (PPI) of the interior pages.
> 3. Finished book width.
> 4. Finished book height
> 5. Allowance for the thickness of the cover
> stock plus some additional distance for the fold.
> A recommended value is 0.017 inch.
>
> The one improvement that I see as useful would be
> to combine all the data entry fields into one
> window instead of producing a separate window
> sequentially for each data field. I don't know
> how to do this.
>
> When the fields are filled out a base document
> correctly sized becomes the current document for
> Sribus.
>
> FEATURES
> There are two vertical guides marking off
> the edges of the spine. There are also vertical
> guides bisecting  the back cover, the
> spine and the front cover.
>
> There are solid blue margins spaced 0.375 inch
> from each edge. These margin guides are designed
> to prevent text and similar entities from
> approaching too close to the finished edges. The
> distance consists of the bleed of 0.125 inch plus
> a safety margin of 0.250 inch.
>
> I tested it with Scribus 1.4.5, 1.5.0.
> Now who wants a copy of the script to bash it
> around before I submit it for inclusion with the
> two releases? I'll post it at
> http://wexfordpress.net
> Your comments are most welcome.
>
> BTW my draft update of the e-book mentioned below
> suddenly go a lot simpler.
>
>
> John Culleton
> Wexford Press
> Free list of books for self-publishers:
> http://wexfordpress.net/shortlist.html
> Updated PDF e-book: "Create Book Covers with
> Scribus 1.4.5" coming soon at
> http://www.booklocker.com/!
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20141218/f21052a9/attachment.html>

From jluc at no-log.org  Thu Dec 18 22:44:09 2014
From: jluc at no-log.org (JLuc)
Date: Thu, 18 Dec 2014 23:44:09 +0100
Subject: [scribus-dev] cover.py script for perfect bound book cover
	design is ready.
In-Reply-To: <20141218151845.006563fa@localb.wexfordpress.net>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net> <5492F4FB.60003@iglou.com>
 <20141218151845.006563fa@localb.wexfordpress.net>
Message-ID: <m6vlbq$i9j$1@ger.gmane.org>

Hello

John, that reads great.

Here are some elements on feedbacks :

If i had to create a dialog with more than one entry,
i would study and probably use tkinter.
See for example http://wiki.scribus.net/canvas/Drawing_a_grid

And as for me and quite a bunch of people also,
i dont grasp inches fully, apart for dot per inches.
I'd appreciate a 'cm' or 'mm' version...
But, AMOF :
- both the data inputs AND for the computations
would be the same whatever the units
(unchanged, since formulas are the same whether unit is cm or inches).
- Once the computations are done, the rest of the script
to create the document would also  probably be the same
but in a different unit
- When setUnit is not explicitely used in the script,
then the application defined preference for the defaut unit
is used for the unit in the script, isnt ?
Then your script is not only managing inches because
inces are your default units !
and when on my machine, it will be using mm, not inches !
That's only, of course, if the script doesnt use setUnit().
So my advices would be
- dont mention inches or cm but "defaut unit" in the inputs labels
- dont use setUnit so the script uses the application's default user-defined unit

In case i'm wrong, setUnit(UNIT_CM) or  setUnit(UNIT_INCHES)
would do the trick
some more scripts use setUnit
http://wiki.scribus.net/canvas/Infobox_in_column
or units
http://wiki.scribus.net/canvas/Automatic_story_formatting

JLuc
I see this script

Le 18/12/2014 21:18, John Culleton a ?crit :
>
> With the very welcome advice of JLuc and
> Gregory Pittman and the availability of the
> spine.py script as a model I have a production
> version of the script cover.py.
>
> In gross this script terms does what what the
> Perfect Bound Cover extension does for Inkscape
> users and what my previous template.html did in
> more limited fashion for Scribus users.
>
> The data fields are:
> 1. Number of pages
> 2. Pages per inch (PPI) of the interior pages.
> 3. Finished book width.
> 4. Finished book height
> 5. Allowance for the thickness of the cover
> stock plus some additional distance for the fold.
> A recommended value is 0.017 inch.
>
> The one improvement that I see as useful would be
> to combine all the data entry fields into one
> window instead of producing a separate window
> sequentially for each data field. I don't know
> how to do this.
>
> When the fields are filled out a base document
> correctly sized becomes the current document for
> Sribus.
>
> FEATURES
> There are two vertical guides marking off
> the edges of the spine. There are also vertical
> guides bisecting  the back cover, the
> spine and the front cover.
>
> There are solid blue margins spaced 0.375 inch
> from each edge. These margin guides are designed
> to prevent text and similar entities from
> approaching too close to the finished edges. The
> distance consists of the bleed of 0.125 inch plus
> a safety margin of 0.250 inch.
>
> I tested it with Scribus 1.4.5, 1.5.0.
> Now who wants a copy of the script to bash it
> around before I submit it for inclusion with the
> two releases? I'll post it at
> http://wexfordpress.net
> Your comments are most welcome.
>
> BTW my draft update of the e-book mentioned below
> suddenly go a lot simpler.
>
>
> John Culleton
> Wexford Press
> Free list of books for self-publishers:
> http://wexfordpress.net/shortlist.html
> Updated PDF e-book: "Create Book Covers with
> Scribus 1.4.5" coming soon at
> http://www.booklocker.com/!
>




From gpittman at iglou.com  Fri Dec 19 01:02:23 2014
From: gpittman at iglou.com (Gregory Pittman)
Date: Thu, 18 Dec 2014 20:02:23 -0500
Subject: [scribus-dev] cover.py script for perfect bound book cover
 design is ready.
In-Reply-To: <20141218151845.006563fa@localb.wexfordpress.net>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net> <5492F4FB.60003@iglou.com>
 <20141218151845.006563fa@localb.wexfordpress.net>
Message-ID: <5493791F.60901@iglou.com>

On 12/18/2014 03:18 PM, John Culleton wrote:
> With the very welcome advice of JLuc and
> Gregory Pittman and the availability of the
> spine.py script as a model I have a production
> version of the script cover.py.
>
> In gross this script terms does what what the
> Perfect Bound Cover extension does for Inkscape
> users and what my previous template.html did in
> more limited fashion for Scribus users.
>
> The data fields are:
> 1. Number of pages
> 2. Pages per inch (PPI) of the interior pages.
> 3. Finished book width.
> 4. Finished book height
> 5. Allowance for the thickness of the cover
> stock plus some additional distance for the fold.
> A recommended value is 0.017 inch.
>
> The one improvement that I see as useful would be
> to combine all the data entry fields into one
> window instead of producing a separate window
> sequentially for each data field. I don't know
> how to do this.
I know JLuc has advocated tkinter, but I find tkinter rather obtuse and 
complex.
These days my preferred method for multiple data entry in one dialog is 
to have data entered separated by white space, for example, from 
http://wiki.scribus.net/canvas/A_Standard_Form_with_Barcodes_and_Custom_Entries 
:

adm_hospnum = scribus.valueDialog('Admit Date + Hospital Number','Admission Date (MM/DD/YYYY) and\n 10-digit Hospital No.\n(Separate with white space only)')
adm_hosp = adm_hospnum.split()

Using this .split function creates a list, which can then be accessed 
with adm_hosp[0], adm_hosp[1], and adm_hosp[2] (remember these are 
string values that would need to be converted to numerical with int() or 
float() to use in a formula).
The script that you're making is for an experienced user, or someone who 
quickly becomes an experienced user. Data entry is on a single line, 
with each value separated by white space (it doesn't matter how big - 
one space or many). In your case, you're only talking about 5 values. 
Even so, it's important to put specifics in the valueDialog text to 
explain the order of expected information, so you might have:

book_data = scribus.valueDialog('Book Data', 'No. of Pages, Pages per 
Inch, Book width, Book height, Cover stock thickness (separated by white 
space only)')
book_values = book_data.split()

> When the fields are filled out a base document
> correctly sized becomes the current document for
> Sribus.
>
> FEATURES
> There are two vertical guides marking off
> the edges of the spine. There are also vertical
> guides bisecting  the back cover, the
> spine and the front cover.
>
> There are solid blue margins spaced 0.375 inch
> from each edge. These margin guides are designed
> to prevent text and similar entities from
> approaching too close to the finished edges. The
> distance consists of the bleed of 0.125 inch plus
> a safety margin of 0.250 inch.
You may have to allow for other units to be used. It could be 
semiautomated by detecting the native units of the document. Generally 
it's going to be a problem not to consider that many if not most Scribus 
users are using EU measurements or points.
>
> I tested it with Scribus 1.4.5, 1.5.0.
> Now who wants a copy of the script to bash it
> around before I submit it for inclusion with the
> two releases? I'll post it at
> http://wexfordpress.net
> Your comments are most welcome.
>
>
I'd like to take a look at it. With your permission, this would be a 
good addition to the wiki. I think we need some collective feedback that 
this deserves to be an included script before we commit it to Scribus.

Greg


From John at wexfordpress.com  Fri Dec 19 12:36:28 2014
From: John at wexfordpress.com (John Culleton)
Date: Fri, 19 Dec 2014 07:36:28 -0500
Subject: [scribus-dev] cover.py script for perfect bound book cover
 design is ready.
In-Reply-To: <CAM9PYkbU6Yfmc0sxp7jJaZOyu2DhEokmHCZaFsmjeoYTd5i6bw@mail.gmail.com>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net>
 <5492F4FB.60003@iglou.com>
 <20141218151845.006563fa@localb.wexfordpress.net>
 <CAM9PYkbU6Yfmc0sxp7jJaZOyu2DhEokmHCZaFsmjeoYTd5i6bw@mail.gmail.com>
Message-ID: <20141219073628.4163afb6@localb.wexfordpress.net>

On Thu, 18 Dec 2014 17:11:39 -0500
Louis Desjardins <louis.desjardins at gmail.com>
wrote:

> Hi John,
> 
> I am very pleased to see that this awesome idea
> made it into a usable script! It?s great.
> 
> I haven?t had the time to test the script but
> by your notes, a question came across my mind:
> Does (or can) the script create a small text
> frame to show the data used to create the pages
> in human reading? In other words, to make the
> communication complete between the actors of
> the graphic chain, a summary of those values,
> including the resulting value for the spine,
> printed just below the horizontal crop marks?
> This could include a few other values from
> fields like Name of job, number of pages, date
> of creation, the mention "Made with Scribus &
> the Script cover.py", etc.
> 
> This would allow quality control on any value
> and if there are any changes, it?s easy to tell
> if a value is still valid or not and if the
> proof we have in hand still corresponds to the
> reality of the job.
> 
> Subsidiary question:
> While I am happy to see the PPI there, some
> printers will simply give the spine value and
> thus could the user be given the choice of
> entering either values (mutually exclusive) to
> obtain the desired result?
> 
> Are there plans to add an option of the flaps?
> 
> I like the security margins. Does the user get
> an electrical shock when text is placed too
> close to the edge? :-D
> 
> Many thanks for this work and to all who gave a
> hand!
> 
> Louis
> 
> 2014-12-18 15:18 GMT-05:00 John Culleton
> <John at wexfordpress.com>:
> >
> >
> > With the very welcome advice of JLuc and
> > Gregory Pittman and the availability of the
> > spine.py script as a model I have a production
> > version of the script cover.py.
> >
> > In gross this script terms does what what the
> > Perfect Bound Cover extension does for
> > Inkscape users and what my previous
> > template.html did in more limited fashion for
> > Scribus users.
> >
> > The data fields are:
> > 1. Number of pages
> > 2. Pages per inch (PPI) of the interior pages.
> > 3. Finished book width.
> > 4. Finished book height
> > 5. Allowance for the thickness of the cover
> > stock plus some additional distance for the
> > fold. A recommended value is 0.017 inch.
> >
> > The one improvement that I see as useful
> > would be to combine all the data entry fields
> > into one window instead of producing a
> > separate window sequentially for each data
> > field. I don't know how to do this.
> >
> > When the fields are filled out a base document
> > correctly sized becomes the current document
> > for Sribus.
> >
> > FEATURES
> > There are two vertical guides marking off
> > the edges of the spine. There are also
> > vertical guides bisecting  the back cover, the
> > spine and the front cover.
> >
> > There are solid blue margins spaced 0.375 inch
> > from each edge. These margin guides are
> > designed to prevent text and similar entities
> > from approaching too close to the finished
> > edges. The distance consists of the bleed of
> > 0.125 inch plus a safety margin of 0.250 inch.
> >
> > I tested it with Scribus 1.4.5, 1.5.0.
> > Now who wants a copy of the script to bash it
> > around before I submit it for inclusion with
> > the two releases? I'll post it at
> > http://wexfordpress.net
> > Your comments are most welcome.
> >
> > BTW my draft update of the e-book mentioned
> > below suddenly go a lot simpler.
> >
> >
> > John Culleton
> > Wexford Press
> > Free list of books for self-publishers:
> > http://wexfordpress.net/shortlist.html
> > Updated PDF e-book: "Create Book Covers with
> > Scribus 1.4.5" coming soon at
> > http://www.booklocker.com/!
> >
> > _______________________________________________
> > scribus-dev mailing list
> > scribus-dev at lists.scribus.net
> > http://lists.scribus.net/mailman/listinfo/scribus-dev
> >

Flaps come in two flavors, what we call French
flaps on a perfect bound cover and the dust
jacket with flaps on a hard case book. In either
case to avoid an overly complex and error prone
script I would prefer to offer a separate script
for each case.

After our annual Christmas Party on Sunday I will
cogitate on each. For the data table I will
investigate tkinter.

-- 
John Culleton
Wexford Press
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html
Updated PDF e-book: "Create Book Covers with
Scribus 1.4.5" coming soon at
http://www.booklocker.com/!


From christoph-schaefer at gmx.de  Sat Dec 20 07:48:35 2014
From: christoph-schaefer at gmx.de (=?UTF-8?Q?=22Christoph_Sch=C3=A4fer=22?=)
Date: Sat, 20 Dec 2014 08:48:35 +0100
Subject: [scribus-dev] cover.py script for perfect bound book cover
 design is ready.
In-Reply-To: <20141218151845.006563fa@localb.wexfordpress.net>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net>
 <5492F4FB.60003@iglou.com>,
 <20141218151845.006563fa@localb.wexfordpress.net>
Message-ID: <trinity-e9d822af-65da-4dc4-9a21-b0c63731c169-1419061715723@3capp-gmx-bs27>

> Gesendet: Donnerstag, 18. Dezember 2014 um 21:18 Uhr
> Von: "John Culleton" <John at wexfordpress.com>
> An: scribus-dev at lists.scribus.net
> Betreff: Re: [scribus-dev] cover.py script for perfect bound book cover design is ready.
>
> 
> With the very welcome advice of JLuc and
> Gregory Pittman and the availability of the
> spine.py script as a model I have a production
> version of the script cover.py.
> 
> In gross this script terms does what what the
> Perfect Bound Cover extension does for Inkscape
> users and what my previous template.html did in
> more limited fashion for Scribus users. 
> 
> The data fields are:
> 1. Number of pages
> 2. Pages per inch (PPI) of the interior pages.
> 3. Finished book width.
> 4. Finished book height
> 5. Allowance for the thickness of the cover
> stock plus some additional distance for the fold. 
> A recommended value is 0.017 inch.
> 
> The one improvement that I see as useful would be
> to combine all the data entry fields into one
> window instead of producing a separate window
> sequentially for each data field. I don't know
> how to do this.
> 
> When the fields are filled out a base document
> correctly sized becomes the current document for
> Sribus. 
> 
> FEATURES
> There are two vertical guides marking off
> the edges of the spine. There are also vertical
> guides bisecting  the back cover, the
> spine and the front cover.
> 
> There are solid blue margins spaced 0.375 inch
> from each edge. These margin guides are designed
> to prevent text and similar entities from
> approaching too close to the finished edges. The
> distance consists of the bleed of 0.125 inch plus
> a safety margin of 0.250 inch. 
> 
> I tested it with Scribus 1.4.5, 1.5.0. 
> Now who wants a copy of the script to bash it
> around before I submit it for inclusion with the 
> two releases? I'll post it at
> http://wexfordpress.net 
> Your comments are most welcome.
> 
> BTW my draft update of the e-book mentioned below
> suddenly go a lot simpler.

Hi John,

Thanks a lot for your work. It is definitely something we can build upon and hopefully include in 1.4.5 and 1.5.0.

I didn't find the script on your website, so my comments are based on your description, as well as the reactions by others.

And now the criticism starts:

1) Your role model for the script seems to be Inkscape's "Perfect Bound Cover" extension. That's a bad idea, because it's completely useless outside the North-American market (and I doubt it's of much use in North America).

2) As JLuc already noted, the world outside North America uses the metric system, and even if some countries are still working with the irrational Imperial System, it's not likely to be identical with the the North American version. Hence my suggestion to add centimetres, millimetres and micrometres to the script.

3) In Europe and large parts of Asia it isn't enough to work with a "recommended", assumed or average paper thickness. A cover designer needs to operate with exact values, either per sheet or per a 1000 sheet (or a fraction of the latter). If you're interested in a European-style calculation, you may want to have a look at http://www.print-assistant.de/tools_press_berechnung_papier_staerke.html (you can use Google Translate to learn what it does).


As for the other features, I applaud your efforts. All you and the Scripter gurus have to do now is making it perfect :)


Kind regards,

Christoph


From John at wexfordpress.com  Sat Dec 20 21:23:37 2014
From: John at wexfordpress.com (John Culleton)
Date: Sat, 20 Dec 2014 16:23:37 -0500
Subject: [scribus-dev] cover.py script for perfect bound book cover
 design is ready.
In-Reply-To: <trinity-e9d822af-65da-4dc4-9a21-b0c63731c169-1419061715723@3capp-gmx-bs27>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net>
 <5492F4FB.60003@iglou.com>
 <20141218151845.006563fa@localb.wexfordpress.net>
 <trinity-e9d822af-65da-4dc4-9a21-b0c63731c169-1419061715723@3capp-gmx-bs27>
Message-ID: <20141220162337.1b5a4b12@localb.wexfordpress.net>

On Sat, 20 Dec 2014 08:48:35 +0100
"Christoph Sch?fer" <christoph-schaefer at gmx.de>
wrote:

> > Gesendet: Donnerstag, 18. Dezember 2014 um
> > 21:18 Uhr Von: "John Culleton"
> > <John at wexfordpress.com> An:
> > scribus-dev at lists.scribus.net Betreff: Re:
> > [scribus-dev] cover.py script for perfect
> > bound book cover design is ready.
> >
> > 
> > With the very welcome advice of JLuc and
> > Gregory Pittman and the availability of the
> > spine.py script as a model I have a production
> > version of the script cover.py.
> > 
> > In gross this script terms does what what the
> > Perfect Bound Cover extension does for
> > Inkscape users and what my previous
> > template.html did in more limited fashion for
> > Scribus users. 
> > 
> > The data fields are:
> > 1. Number of pages
> > 2. Pages per inch (PPI) of the interior pages.
> > 3. Finished book width.
> > 4. Finished book height
> > 5. Allowance for the thickness of the cover
> > stock plus some additional distance for the
> > fold. A recommended value is 0.017 inch.
> > 
> > The one improvement that I see as useful
> > would be to combine all the data entry fields
> > into one window instead of producing a
> > separate window sequentially for each data
> > field. I don't know how to do this.
> > 
> > When the fields are filled out a base document
> > correctly sized becomes the current document
> > for Sribus. 
> > 
> > FEATURES
> > There are two vertical guides marking off
> > the edges of the spine. There are also
> > vertical guides bisecting  the back cover, the
> > spine and the front cover.
> > 
> > There are solid blue margins spaced 0.375 inch
> > from each edge. These margin guides are
> > designed to prevent text and similar entities
> > from approaching too close to the finished
> > edges. The distance consists of the bleed of
> > 0.125 inch plus a safety margin of 0.250
> > inch. 
> > 
> > I tested it with Scribus 1.4.5, 1.5.0. 
> > Now who wants a copy of the script to bash it
> > around before I submit it for inclusion with
> > the two releases? I'll post it at
> > http://wexfordpress.net 
> > Your comments are most welcome.
> > 
> > BTW my draft update of the e-book mentioned
> > below suddenly go a lot simpler.
> 
> Hi John,
> 
> Thanks a lot for your work. It is definitely
> something we can build upon and hopefully
> include in 1.4.5 and 1.5.0.
> 
> I didn't find the script on your website, so my
> comments are based on your description, as well
> as the reactions by others.
> 
> And now the criticism starts:
> 
> 1) Your role model for the script seems to be
> Inkscape's "Perfect Bound Cover" extension.
> That's a bad idea, because it's completely
> useless outside the North-American market (and
> I doubt it's of much use in North America).
> 
> 2) As JLuc already noted, the world outside
> North America uses the metric system, and even
> if some countries are still working with the
> irrational Imperial System, it's not likely to
> be identical with the the North American
> version. Hence my suggestion to add
> centimetres, millimetres and micrometres to the
> script.
> 
> 3) In Europe and large parts of Asia it isn't
> enough to work with a "recommended", assumed or
> average paper thickness. A cover designer needs
> to operate with exact values, either per sheet
> or per a 1000 sheet (or a fraction of the
> latter). If you're interested in a
> European-style calculation, you may want to
> have a look at
> http://www.print-assistant.de/tools_press_berechnung_papier_staerke.html
> (you can use Google Translate to learn what it
> does).
> 
> 
> As for the other features, I applaud your
> efforts. All you and the Scripter gurus have to
> do now is making it perfect :)
> 
> 
> Kind regards,
> 
> Christoph
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
> 
> 
> _______________________________________________________
>
Actually my model was my own online package
http://wexfordpress.com/template.html. It was
the companion to my currently deceased pdf e-book
"Create Book Covers With Scribus" which was
written in 2009 and distributed via
Booklocker.com. The e-book is currently deceased
because a buyer objected to the antique
illustrations taken from Scribus 1.3.3.13 or
thereabouts. The distributor, Booklocker, returned
the buyer's money and at my suggestion took it
out of availability. 

The major difference between my earlier attempt
and the current effort was that my online
facility provided numbers for the overall width
and height and for the vertical guides which the
user had to key in by hand in Scribus. 

It did have the advantage, shared by my/our latest
attempt, to bisect the three panels with three
additional vertical guides to make centering
things easier. Just maneuver the text block or
whatever so that the little red squares fall on
the added guides. No other cover design aid has
this little helper. 

You and one other person thus far have asked for
a Non-North American version. Well although I
began programming in 1968 before many of my
listmates were out of kindergarten the world
of Python and object oriented design is totally
new to me. So I am in favor of learning how to
crawl before I walk.  If/when I participate in a
metric version I would prefer to make it a
separate program. It would be easier for me
to code and debug and less cumbersome for the
user to manipulate. 

I totally agree that both the interior paper
thickness and the cover paper thickness should be
figured exactly and not guessed at. In my once
and future e-book I have a table showing the ppi
numbers for the most popular interior papers used
by Lightning Source International (LSI),
CreateSpace and a more complete set of ppi
numbers for my favorite small printer, 360
Digital Design. I took the recommendation of
0.017 inches from 360 Digital's handbook, where
the recommend an overall allowance of 0.034 for
both sides of the spine including cover stock 
thickness and an allowance for the fold. 0.034
inches divided by 2 is 0.017 for one side. Their
covers are usually 0.010 stock although 0.012
caliper paper is also available. Contrast this
with the Amazon owned printer/publisher
Createspace, where they provide canned values for
various spine widths in their comparable cover
template program to the nearest ten pages! Bottom
line, the printer's numbers should be used for
both interior ppi and cover thickness, with a
little extra allowed for the folds on each side.
I did not and do not recommend guestimates or
Createspace style approximations.

I have more thoughts but family concerns have
arisen for this evening. 

Thanks for your comments. I will send you a copy
of the current cover.py script under separate
cover.  
-- 
John Culleton
Wexford Press
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html
Updated PDF e-book: "Create Book Covers with
Scribus 1.4.5" coming soon at
http://www.booklocker.com/!
I


From John at wexfordpress.com  Tue Dec 23 17:24:04 2014
From: John at wexfordpress.com (John Culleton)
Date: Tue, 23 Dec 2014 12:24:04 -0500
Subject: [scribus-dev] cover.py script for perfect bound book cover
 design is ready.
In-Reply-To: <20141220162337.1b5a4b12@localb.wexfordpress.net>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net>
 <5492F4FB.60003@iglou.com>
 <20141218151845.006563fa@localb.wexfordpress.net>
 <trinity-e9d822af-65da-4dc4-9a21-b0c63731c169-1419061715723@3capp-gmx-bs27>
 <20141220162337.1b5a4b12@localb.wexfordpress.net>
Message-ID: <20141223122404.72acd630@localb.wexfordpress.net>

On Sat, 20 Dec 2014 16:23:37 -0500
John Culleton <John at wexfordpress.com> wrote:



Some printers  (Createspace is one) prefer to
specify the thickness of their book interior
stock as a very small fraction of an inch. 
This fraction is easily converted to ppi by
dividing the fractional amount into 2.

When it comes to metric measurement I am a bit at
sea. What number comparable to ppi do printers
offer? 

Similarly for perfect bound cover stock thickness
in the USA 0.10 inch or 0.012 inch are standard
measures. what thicknesses are common in Europe?

Finally what added width and height for trim is
common in Europe? In the USA 0.125 is the
standard expectation.

I set margins in inches at 0.25 + 0.125 = 0.375.
What would be the comparable expectation in a
cover template in a metric environment? 

I will rename my inch version of the script to 
softcover_inch.py and the metric version as
softcover_mm.py.

I will publish the versions as they are completed
whenever I get a wiki account. I have asked twice
now.

-- 
John Culleton
Wexford Press
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html
Updated PDF e-book: "Create Book Covers with
Scribus 1.4.5" coming soon at
http://www.booklocker.com/!


From louis.desjardins at gmail.com  Tue Dec 23 21:27:10 2014
From: louis.desjardins at gmail.com (Louis Desjardins)
Date: Tue, 23 Dec 2014 16:27:10 -0500
Subject: [scribus-dev] cover.py script for perfect bound book cover
 design is ready.
In-Reply-To: <20141223122404.72acd630@localb.wexfordpress.net>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net>
 <5492F4FB.60003@iglou.com>
 <20141218151845.006563fa@localb.wexfordpress.net>
 <trinity-e9d822af-65da-4dc4-9a21-b0c63731c169-1419061715723@3capp-gmx-bs27>
 <20141220162337.1b5a4b12@localb.wexfordpress.net>
 <20141223122404.72acd630@localb.wexfordpress.net>
Message-ID: <CAM9PYkadepUN+pPpXE_3dnRTO8dpQTcvwXtd7FccuFKR5Ans5w@mail.gmail.com>

2014-12-23 12:24 GMT-05:00 John Culleton <John at wexfordpress.com>:

> On Sat, 20 Dec 2014 16:23:37 -0500
> John Culleton <John at wexfordpress.com> wrote:
>
>
>
> Some printers  (Createspace is one) prefer to
> specify the thickness of their book interior
> stock as a very small fraction of an inch.
> This fraction is easily converted to ppi by
> dividing the fractional amount into 2.
>
> When it comes to metric measurement I am a bit at
> sea. What number comparable to ppi do printers
> offer?


> Similarly for perfect bound cover stock thickness
> in the USA 0.10 inch or 0.012 inch are standard
> measures. what thicknesses are common in Europe?
>

Hi,

Europe uses GSM (grams per square meter) and thus printers seem to use a
different formulae to get the spine thickness. One is described here (in
French but I guess a Google Translation could be of some help; it?s not
overwhelmingly complicated to figure out):
http://www.graphitec.org/epaisseur.html

The following table could be of some use as well:
http://www.paper-paper.com/weight.html

I guess we have a few paths to consider with this script. Either we give
the user the mean to "calculate" the spine value (which in fact may seem
more "open source" by it?s "pedagogic" angle), or we give the user the mean
to set the cover with the proper spine as provided by the printer (which
puts all the responsibility of the exactness of that calculation in the
hands of the printer, something a lot of designers will be very glad with).

Louis


>
> Finally what added width and height for trim is
> common in Europe? In the USA 0.125 is the
> standard expectation.
>
> I set margins in inches at 0.25 + 0.125 = 0.375.
> What would be the comparable expectation in a
> cover template in a metric environment?
>
> I will rename my inch version of the script to
> softcover_inch.py and the metric version as
> softcover_mm.py.
>
> I will publish the versions as they are completed
> whenever I get a wiki account. I have asked twice
> now.
>
> --
> John Culleton
> Wexford Press
> Free list of books for self-publishers:
> http://wexfordpress.net/shortlist.html
> Updated PDF e-book: "Create Book Covers with
> Scribus 1.4.5" coming soon at
> http://www.booklocker.com/!
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20141223/b816d890/attachment.html>

From jluc at no-log.org  Wed Dec 24 11:25:34 2014
From: jluc at no-log.org (JLuc)
Date: Wed, 24 Dec 2014 12:25:34 +0100
Subject: [scribus-dev] cover.py script for perfect bound book cover
	design is ready.
In-Reply-To: <CAM9PYkadepUN+pPpXE_3dnRTO8dpQTcvwXtd7FccuFKR5Ans5w@mail.gmail.com>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net> <5492F4FB.60003@iglou.com>
 <20141218151845.006563fa@localb.wexfordpress.net>
 <trinity-e9d822af-65da-4dc4-9a21-b0c63731c169-1419061715723@3capp-gmx-bs27>
 <20141220162337.1b5a4b12@localb.wexfordpress.net>
 <20141223122404.72acd630@localb.wexfordpress.net>
 <CAM9PYkadepUN+pPpXE_3dnRTO8dpQTcvwXtd7FccuFKR5Ans5w@mail.gmail.com>
Message-ID: <m7e7re$3pj$1@ger.gmane.org>

Le 23/12/2014 22:27, Louis Desjardins a ?crit :
> Europe uses GSM (grams per square meter) and thus printers seem to use a different formulae to get the spine thickness.

Paper with same 'grammage' (GSM = g/m?) can have different thickness.

According to provided link http://www.graphitec.org/epaisseur.html,
thickness formula for inner pages is :
specialpaperfactor x grammage x nbpage / 2

With "standard papier", specialpaperfactor = 1

With "papier couch?", specialpaperfactor goes 0.85 to 1.15
With "papier offset", specialpaperfactor goes 1.05 to 1.25
With "papier bouffant", specialpaperfactor goes from 1.15 to 1.70

JLuc

> One is described here (in French but I guess a Google Translation could be of some help; it?s not overwhelmingly
> complicated to figure out):
> http://www.graphitec.org/epaisseur.html
>
> The following table could be of some use as well:
> http://www.paper-paper.com/weight.html
>
> I guess we have a few paths to consider with this script. Either we give the user the mean to "calculate" the spine
> value (which in fact may seem more "open source" by it?s "pedagogic" angle), or we give the user the mean to set the
> cover with the proper spine as provided by the printer (which puts all the responsibility of the exactness of that
> calculation in the hands of the printer, something a lot of designers will be very glad with).
>
> Louis
>
>
>     Finally what added width and height for trim is
>     common in Europe? In the USA 0.125 is the
>     standard expectation.
>
>     I set margins in inches at 0.25 + 0.125 = 0.375.
>     What would be the comparable expectation in a
>     cover template in a metric environment?
>
>     I will rename my inch version of the script to
>     softcover_inch.py and the metric version as
>     softcover_mm.py.
>
>     I will publish the versions as they are completed
>     whenever I get a wiki account. I have asked twice
>     now.
>
>     --
>     John Culleton
>     Wexford Press
>     Free list of books for self-publishers:
>     http://wexfordpress.net/shortlist.html
>     Updated PDF e-book: "Create Book Covers with
>     Scribus 1.4.5" coming soon at
>     http://www.booklocker.com/!
>
>     _______________________________________________
>     scribus-dev mailing list
>     scribus-dev at lists.scribus.net
>     <mailto:scribus-dev at lists.scribus.net>
>     http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>
>
>




From gpittman at iglou.com  Wed Dec 24 12:58:43 2014
From: gpittman at iglou.com (Gregory Pittman)
Date: Wed, 24 Dec 2014 07:58:43 -0500
Subject: [scribus-dev] cover.py script for perfect bound book cover
 design is ready.
In-Reply-To: <m7e7re$3pj$1@ger.gmane.org>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net> <5492F4FB.60003@iglou.com>
 <20141218151845.006563fa@localb.wexfordpress.net>
 <trinity-e9d822af-65da-4dc4-9a21-b0c63731c169-1419061715723@3capp-gmx-bs27>
 <20141220162337.1b5a4b12@localb.wexfordpress.net>
 <20141223122404.72acd630@localb.wexfordpress.net>
 <CAM9PYkadepUN+pPpXE_3dnRTO8dpQTcvwXtd7FccuFKR5Ans5w@mail.gmail.com>
 <m7e7re$3pj$1@ger.gmane.org>
Message-ID: <549AB883.20804@iglou.com>

On 12/24/2014 06:25 AM, JLuc wrote:
> Le 23/12/2014 22:27, Louis Desjardins a ?crit :
>> Europe uses GSM (grams per square meter) and thus printers seem to use
>> a different formulae to get the spine thickness.
> 
> Paper with same 'grammage' (GSM = g/m?) can have different thickness.
> 
> According to provided link http://www.graphitec.org/epaisseur.html,
> thickness formula for inner pages is :
> specialpaperfactor x grammage x nbpage / 2
> 
> With "standard papier", specialpaperfactor = 1
> 
> With "papier couch?", specialpaperfactor goes 0.85 to 1.15
> With "papier offset", specialpaperfactor goes 1.05 to 1.25
> With "papier bouffant", specialpaperfactor goes from 1.15 to 1.70
> 

Another approach to consider might be to create the script as
envisioned, after which the user presents the results to his printer,
then adjust the cover's spine if needed.

Greg



From louis.desjardins at gmail.com  Thu Dec 25 17:22:11 2014
From: louis.desjardins at gmail.com (Louis Desjardins)
Date: Thu, 25 Dec 2014 12:22:11 -0500
Subject: [scribus-dev] cover.py script for perfect bound book cover
 design is ready.
In-Reply-To: <549AB883.20804@iglou.com>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net>
 <5492F4FB.60003@iglou.com>
 <20141218151845.006563fa@localb.wexfordpress.net>
 <trinity-e9d822af-65da-4dc4-9a21-b0c63731c169-1419061715723@3capp-gmx-bs27>
 <20141220162337.1b5a4b12@localb.wexfordpress.net>
 <20141223122404.72acd630@localb.wexfordpress.net>
 <CAM9PYkadepUN+pPpXE_3dnRTO8dpQTcvwXtd7FccuFKR5Ans5w@mail.gmail.com>
 <m7e7re$3pj$1@ger.gmane.org> <549AB883.20804@iglou.com>
Message-ID: <CAM9PYkab=3ZuysC_N1FSFmFFiqF8506zWUvQ6HDNFJYJpuNZCg@mail.gmail.com>

2014-12-24 7:58 GMT-05:00 Gregory Pittman <gpittman at iglou.com>:

> On 12/24/2014 06:25 AM, JLuc wrote:
> > Le 23/12/2014 22:27, Louis Desjardins a ?crit :
> >> Europe uses GSM (grams per square meter) and thus printers seem to use
> >> a different formulae to get the spine thickness.
> >
> > Paper with same 'grammage' (GSM = g/m?) can have different thickness.
> >
> > According to provided link http://www.graphitec.org/epaisseur.html,
> > thickness formula for inner pages is :
> > specialpaperfactor x grammage x nbpage / 2
> >
> > With "standard papier", specialpaperfactor = 1
> >
> > With "papier couch?", specialpaperfactor goes 0.85 to 1.15
> > With "papier offset", specialpaperfactor goes 1.05 to 1.25
> > With "papier bouffant", specialpaperfactor goes from 1.15 to 1.70
> >
>
> Another approach to consider might be to create the script as
> envisioned, after which the user presents the results to his printer,
> then adjust the cover's spine if needed.
>

Encouraged by a few offlist discussions, here?s yet another approach to
this whole issue. I would call it the "unscript approach", if you allow me!

The other way I thought for Scribus (back a few years ago) was to address
this case by asking the developers to allow us to use spreads in a
combination of pages of different sizes. By the way, this would not be
limited to covers and spines but would be useful in all cases where pages
need not to be of equal size, for example with pamphlets where flaps are
not equal to allow the paper to fold correctly. Back to spine, the middle
page being the spine, you can simply change the page size when you need to.
By adding the possibility of enlarging or reducing the page width from a
reference point that could be the center of the page, the elements on that
page would remain centered. And there would be no need for a script. And
you can have flaps too, by adding 2 pages to the first 3. I wouldn?t say
the possibilities are countless but given the fact that those are pretty
common cases in the printing world, I think it would be great to address
this in a more efficient way. And I would put the calculation for the spine
as an article in the wiki.

Related topic in the bug tracker
http://bugs.scribus.net/view.php?id=5372

>From the mailing list a discussion between John and I and a few other
suspects (!) on july 21, 2011. Subject line : Printing as Spread.

Andreas also made a comment on that topic in the same discussion.

Something to put on the heat for 2015?

Cheers!

Louis


>
> Greg
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20141225/cf27cae1/attachment.html>

From John at wexfordpress.com  Thu Dec 25 17:58:06 2014
From: John at wexfordpress.com (John Culleton)
Date: Thu, 25 Dec 2014 12:58:06 -0500
Subject: [scribus-dev] cover.py script for perfect bound book cover
 design is ready.
In-Reply-To: <CAM9PYkab=3ZuysC_N1FSFmFFiqF8506zWUvQ6HDNFJYJpuNZCg@mail.gmail.com>
References: <20141217134755.1a57aca8@localb.wexfordpress.net>
 <m6sri5$8s1$1@ger.gmane.org> <54921B3C.2070402@iglou.com>
 <20141218084931.57daa6f8@localb.wexfordpress.net>
 <5492F4FB.60003@iglou.com>
 <20141218151845.006563fa@localb.wexfordpress.net>
 <trinity-e9d822af-65da-4dc4-9a21-b0c63731c169-1419061715723@3capp-gmx-bs27>
 <20141220162337.1b5a4b12@localb.wexfordpress.net>
 <20141223122404.72acd630@localb.wexfordpress.net>
 <CAM9PYkadepUN+pPpXE_3dnRTO8dpQTcvwXtd7FccuFKR5Ans5w@mail.gmail.com>
 <m7e7re$3pj$1@ger.gmane.org> <549AB883.20804@iglou.com>
 <CAM9PYkab=3ZuysC_N1FSFmFFiqF8506zWUvQ6HDNFJYJpuNZCg@mail.gmail.com>
Message-ID: <20141225125806.0cfa63e9@localb.wexfordpress.net>

On Thu, 25 Dec 2014 12:22:11 -0500
Louis Desjardins <louis.desjardins at gmail.com>
wrote:

> 2014-12-24 7:58 GMT-05:00 Gregory Pittman
> <gpittman at iglou.com>:
> 
> > On 12/24/2014 06:25 AM, JLuc wrote:
> > > Le 23/12/2014 22:27, Louis Desjardins a
> > > ?crit :
> > >> Europe uses GSM (grams per square meter)
> > >> and thus printers seem to use a different
> > >> formulae to get the spine thickness.
> > >
> > > Paper with same 'grammage' (GSM = g/m?) can
> > > have different thickness.
> > >
> > > According to provided link
> > > http://www.graphitec.org/epaisseur.html,
> > > thickness formula for inner pages is :
> > > specialpaperfactor x grammage x nbpage / 2
> > >
> > > With "standard papier", specialpaperfactor
> > > = 1
> > >
> > > With "papier couch?", specialpaperfactor
> > > goes 0.85 to 1.15 With "papier offset",
> > > specialpaperfactor goes 1.05 to 1.25 With
> > > "papier bouffant", specialpaperfactor goes
> > > from 1.15 to 1.70
> > >
> >
> > Another approach to consider might be to
> > create the script as envisioned, after which
> > the user presents the results to his printer,
> > then adjust the cover's spine if needed.
> >
> 
> Encouraged by a few offlist discussions, here?s
> yet another approach to this whole issue. I
> would call it the "unscript approach", if you
> allow me!
> 
> The other way I thought for Scribus (back a few
> years ago) was to address this case by asking
> the developers to allow us to use spreads in a
> combination of pages of different sizes. By the
> way, this would not be limited to covers and
> spines but would be useful in all cases where
> pages need not to be of equal size, for example
> with pamphlets where flaps are not equal to
> allow the paper to fold correctly. Back to
> spine, the middle page being the spine, you can
> simply change the page size when you need to.
> By adding the possibility of enlarging or
> reducing the page width from a reference point
> that could be the center of the page, the
> elements on that page would remain centered.
> And there would be no need for a script. And
> you can have flaps too, by adding 2 pages to
> the first 3. I wouldn?t say the possibilities
> are countless but given the fact that those are
> pretty common cases in the printing world, I
> think it would be great to address this in a
> more efficient way. And I would put the
> calculation for the spine as an article in the
> wiki.
> 
> Related topic in the bug tracker
> http://bugs.scribus.net/view.php?id=5372
> 
> From the mailing list a discussion between John
> and I and a few other suspects (!) on july 21,
> 2011. Subject line : Printing as Spread.
> 
> Andreas also made a comment on that topic in
> the same discussion.
> 
> Something to put on the heat for 2015?
> 
> Cheers!
> 
> Louis
> 
> 
> >
> > Greg
> >
> >
> > _______________________________________________
> > scribus-dev mailing list
> > scribus-dev at lists.scribus.net
> > http://lists.scribus.net/mailman/listinfo/scribus-dev
> >

I am retreating into my North American cave and
sticking with my original product, now called
softcover_inch.py, with due credit to those who
educated me up to now on various aspects of
Python and the Scribus interface thereto. I have
received an acknowledgement to my request to post
on wiki as suggested on this thread. I would
post this product there except I need a password
to my page on wiki, and that hasn't appeared
yet. I'll check my junk folder to be sure.

Thanks to all, and have at it Europeans! I will
follow your discussion with interest.


-- 
John Culleton
Wexford Press
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html
Updated PDF e-book: "Create Book Covers with
Scribus 1.4.5" coming soon at
http://www.booklocker.com/!


From John at wexfordpress.com  Thu Dec 25 21:20:12 2014
From: John at wexfordpress.com (John Culleton)
Date: Thu, 25 Dec 2014 16:20:12 -0500
Subject: [scribus-dev] Perfect book cover template script softcover_inch.py
Message-ID: <20141225162012.3f3f9b40@localb.wexfordpress.net>

I have opened up a wiki page JCulleton and placed
the description of the script and the script
itself on that page. The wiki software tends to
do strange things to program text so a safer
source for the script source  is:
http://www.wexfordpress.com/softcover_inch.py

This completes my work on this project. Hopefully
the script will in time be included in Scribus
releases.
-- 
John Culleton
Wexford Press
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html
Updated PDF e-book: "Create Book Covers with
Scribus 1.4.5" coming soon at
http://www.booklocker.com/!


From gpittman at iglou.com  Fri Dec 26 00:08:34 2014
From: gpittman at iglou.com (Gregory Pittman)
Date: Thu, 25 Dec 2014 19:08:34 -0500
Subject: [scribus-dev] Perfect book cover template script
	softcover_inch.py
In-Reply-To: <20141225162012.3f3f9b40@localb.wexfordpress.net>
References: <20141225162012.3f3f9b40@localb.wexfordpress.net>
Message-ID: <549CA702.9090100@iglou.com>

On 12/25/2014 04:20 PM, John Culleton wrote:
> I have opened up a wiki page JCulleton and placed
> the description of the script and the script
> itself on that page. The wiki software tends to
> do strange things to program text so a safer
> source for the script source  is:
> http://www.wexfordpress.com/softcover_inch.py
> 
> This completes my work on this project. Hopefully
> the script will in time be included in Scribus
> releases.
> 
I cleaned up the wiki page a bit.
One thing was to surround your script with tags:
<syntaxhighlight lang="python"> at the beginning,

</syntaxhighlight> at the end. This takes care of making the script look
as it should and be able to be copied from the wiki.

You don't really need the '#!/usr/bin/env python' at the beginning since
this only runs in Scribus (and you left out the ! so it would have been
interpreted as a comment anyway).

I deleted the line 'import from scribus *', since you already had
'import scribus' and your syntax conforms to that method.

Its simplicity is nice. Typically we recommend a section at the
beginning, starting and ending with 3 double quotes ("""). What you put
between them is a description of what the script is for, and something
about usage, requirements, etc. This text will show up when someone uses
Script > About Script... from the menu.

At some point you may want to move it to its own page instead of on your
user page. Then you might add (as a wiki edit)

{{Scripting Index}}

at the top of the page, to get it to show up in the index of scripts.
Those who find it useful may wish to expand it to allow for using other
units. Those not familiar with inches may not be sure what to enter for
some values.

Greg


From wtxnh-scribus at yahoo.com.au  Sat Dec 27 14:11:49 2014
From: wtxnh-scribus at yahoo.com.au (Juraj Fedel)
Date: Sat, 27 Dec 2014 15:11:49 +0100
Subject: [scribus-dev] Adding missing members to PDFfile scripter object
Message-ID: <20141227141149.GD2584@alfa>

Hello,

Few days ago William had uploaded one patch to #8959 that enable to use
bleeds from python script for 1.4.5 version. After that I added the rest
of missing members to PDFfile object (more than 20 of them). If it is
not too late maybe those patches could be included in 1.4.5 release too.
Patches with small test script are included in attachment.

Also I am wondering if bugfixes included in issue #12594 were applied to
1.4.4 source. It is OK if you do not want to include patches that
introduce new features, but I think that some patches that fixes
existing bugs could be applied.

Namely:
from file patch_bundle_v144-25aug14.tar.gz
0002-sys.path-in-scripter-console-fixed.patch
0003-Do-not-use-and-xB0-as-identifier-in-python.patch
0004-Fix-module-name-for-objects-created-in-scripter.patch
0005-Fix-broken-handling-of-prefs-option.patch
0006-Startup-script-does-not-work.patch

from monster_beheaded_v144-20sep14.tar.gz
0008-Run-startup-script-only-after-Scribus-is-fully-initi.patch

This last patch should be slightly modified as noted in README file
included also in monster_beheaded_v144-20sep14.tar.gz if it is to be
applied without other patches in that archive.

Happy New Year
Juraj



----- End forwarded message -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdffile_v144.tar.gz
Type: application/octet-stream
Size: 6836 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20141227/df97f00e/attachment.obj>

From jghali at libertysurf.fr  Mon Dec 29 13:02:10 2014
From: jghali at libertysurf.fr (Jean Ghali)
Date: Mon, 29 Dec 2014 14:02:10 +0100
Subject: [scribus-dev] Adding missing members to PDFfile scripter object
In-Reply-To: <20141227141149.GD2584@alfa>
References: <20141227141149.GD2584@alfa>
Message-ID: <54A150D2.9030407@libertysurf.fr>

Le 27/12/2014 15:11, Juraj Fedel a ?crit :
> Hello,
> 
> Few days ago William had uploaded one patch to #8959 that enable to use
> bleeds from python script for 1.4.5 version. After that I added the rest
> of missing members to PDFfile object (more than 20 of them). If it is
> not too late maybe those patches could be included in 1.4.5 release too.
> Patches with small test script are included in attachment.

Hi Juraj,

Thanks for your patches. I have now ported and applied the first three patches to trunk,
and the first to 1.4.x. The patch related to #8959 triggers a change of behavior and may
change the result of existing scripts, so this patch is not quite suited for being
included in a stable branch such as 1.4.x. The third patch however add some new options
without modifying behavior, so I may well have a look at applying it to 1.4.x in the next
few days.

Jean






