View Issue Details

IDProjectCategoryView StatusLast Update
0000238ScribusGeneralpublic2016-09-09 16:14
Reportermhanski Assigned Tocbradney  
PrioritylowSeverityfeatureReproducibilityN/A
Status assignedResolutionopen 
Product Version1.3 
Target VersionFuture Release - Nice to have 
Summary0000238: New CL option: scribus --to-pdf <scribus-file> <output.pdf>
DescriptionA new command line option that would allow to create on the fly PDF forms or documents without starting the Scribus GUI.
Tags#pending, discussion
PatchNo

Relationships

related to 0001123 acknowledged Save printer settings 
related to 0013311 closedcbradney support for command line arguments to be passed on to python script (-py option) 
related to 0001898 acknowledged Support saving, loading, and verifying sets of PDF settings 
related to 0000967 assignedcbradney CLI option -p 
related to 0003831 acknowledged Metabug: PDF Forms 
related to 0012572 closedcbradney [patch] Add a --python-script command line option to run a script and exit 

Activities

plinnell

2004-02-03 05:04

viewer   ~0000428

moving to 1.3+

The main problem with this, (IMO) is PDF export has many different options, which require many options with command line switches.

Perhaps the swtiches/options can be part of the scribus.sla file. Some PDF options are stored in sla already.

This requires lots of thought before committing time to code.

ale

2004-02-03 10:46

manager   ~0000429

I think that it would be cool if the latest pdf-exporting settings get recorded in the .sla file...

It would be a good feature in the new dtd of the scribus format!

user171

2004-04-15 13:36

  ~0001074

Export parameters could be stored in an "export format" which should be independent of the document; perhaps it could be saved to a profile (user or system) or to a separate file?

That way, you could just give the format name or file as parameter to a pdf-export switch.

subik

2004-05-04 18:46

manager   ~0001350

yes, it's about 90 options (taken from source code)... it's realy uncomfortable to have all of them in CLI option set - IMHO.

mhanski

2004-06-21 12:28

developer   ~0001807

>yes, it's about 90 options (taken from source code)... it's realy >uncomfortable to have all of them in CLI option set - IMHO.

Saving all the PDF options within the .sla file, as proposed by a.l.e, would be a pretty nice solution to that. We wouldn't need any additional CLI options or "external" option files, then - the new DTD would serve this.

malex

2004-06-21 17:06

administrator   ~0001809

Macej,

Good thinking. It's certainly possible to add another namespace for pdf export options to the new DTD. Then, these options will be saved within the .sla file if the document has been exported to PDF at least once. If numerous exports have been done it might be a good idea to save the options from the last export, _unless_ a checkbox somewhere is ticked off to _not_ save this particular export's options. It looks to me to be the most elegant solution at the moment.

user171

2004-06-22 09:15

  ~0001815

The way I use DTP, export formats are in no way connected with a single document, but with intended use, like preview, internet download or print. So a document should store only an identifier for the format it was last exported to, and perhaps those options that were overridden for that export, but not the format itself.

Or perhaps Documents could be made to inherit from each other, so that common options - like export formats - could be stored in the most basic template; different sets of page layout, default frames, logos etc in layers above that?
Could be a nice way to organize your defaults, as long as you don't share documents with anybody else...

cbradney

2004-06-22 10:53

administrator   ~0001816

Last edited: 2004-06-22 10:58

And what if the document has a print and web destination.. you will always export either option in varying orders depending on the day. Storing this in the SLA file is probably not a good idea on first glance, although the idea of a namespace to keep it seperate would be the most appropriate. You could have a print, web and presentation storage sections in the PDF export namespace if it was to be stored in the SLA to keep it seperate.

In the end if you look at a program like ghostscript you have a myriad of options for conversion etc. PDF export IS complex and if there ever were the ability to export from commandline it only makes sense to present all of these options to the user. There would of course be the possiblity of have nice defaults or shortcut options that group some standard options, eg max image quality, least compression etc.

The command line option could have "--exportwithsavedprint", "--exportwithsavedweb", "--exportwithsavedpresentation" type options that would use the saved values if they existed.

edited on: 06-22-04 12:58

ringerc

2004-09-05 19:07

reporter   ~0002297

Lots of the critical settings are provided already in a format already supported by Acro Distiller and GhostScript - the .joboptions format.

I realise that when you're not doing your PDF conversion as part of a PostScript interpreter process, that is less convenient. Nonetheless, joboptions files are already "the standard" and provided by a lot of press houses etc. I've already spoken to one person on IRC who did not know what to do with it - and whose printer, somewhat pathetically, provided no other information.

Unfortunately, a JobOptions file is not really going to be sufficiently expressive. If another PDF settings format evolves for Scribus, consider this to be me putting my hand up to code a simple Python settings converter.

packetbell

2004-09-24 15:01

reporter   ~0002507

Every print/export dialog should have the option to save settings to a file. This will help with batch jobs from the command line:

scribus --to-pdf <scribus.sla> <output.pdf> <settings.set>

scribus --to-printer <scribus.sla> <printer-name> <settings.set>

Also very handy with for normal use. Just save your settings once, and load 'em in next time you need to print a document with the same settings.

packetbell

2004-09-24 15:04

reporter   ~0002509

Also see bug 1123

jmh

2004-09-24 19:51

reporter   ~0002518

I guess I should chime in here and say that this is a feature I think would be great for scribus. Since DTP is a bit on the resource intensive side, it might be be necessary to make a daemon or something, even without a GUI. At least a cronscript or something which caches the font information so that doesnt have to be determined each time scribus is run.

mglauche

2004-10-07 09:09

reporter   ~0002647

Now that scribus has pdf-export in the scripter, it might be a good way to implemet a "--run-script name.py", that starts scribus, runs the script, and exits.

You would still need a X-Server, but that could be a virtual frame buffer one :)

ringerc

2005-02-25 06:54

reporter   ~0003817

This and other application automation tasks can probably be done with dcop once some changes are made to better support it. That will only work where the KDE libs are present, but is better than nothing.

ringerc

2005-04-08 04:43

reporter   ~0004141

DCOP doesn't look so promising, it turns out - mostly because it looks likely to be phased out in KDE4. Some sort of external scripting/IPC will be desirable ... maybe based on D-BUS if something emerges in KDE for that.

christoph_s

2005-07-14 22:25

administrator   ~0005587

I realise the isssue is already assigned to subik and probably under development, but here are some random thoughts on the issue:

- since FUP is willing to financially support the development of this feature, it might be useful to ask them what they need.

- many options mentioned here don't seem mutually exclusive to me:

-- if the new file format allows for storing all PDF settings, a command like scribus -pdf input.sla output.pdf would simply produce a PDF with the settings of the sla file

-- default preferences might be useful as well (-print, -web, -presentation ...)

-- saving PDF settings separately and using them with the CLI would be *very* useful.

-- to provide maximum flexibility, *all* of scribus' PDF options should be available. The complexity wouldn't be a problem IMHO (at least on the side of the user) since it is mostly required in automation/scripting. The people who need this feature are used to applying hundreds of command line options.

-- thinking beyond 1.3/1.4, one day, the CLI might one day also provide all options for converting to EPS, SVG, bitmaps, PS, (X)HTML ...

BarryB

2005-07-25 04:41

reporter   ~0005707

Last edited: 2005-07-25 05:50

I'm another user who'd like this feature. My specific application is the creation of cover pages for reports. I use Scribus to create a layout then programmatically modify the SLA file to customize it for a specific report. I need to make around 1,000 cover pages a day so programatically is the only option.

In the past I've used FrameMaker for this and it's command-line print capability did whatever the last thing you did when printing the report from the GUI. Not sophisticated, but good enough for me.

It looks like solidifing how you're going to do this may be some time out. How feasable is it for me to create a new main that loads a file and calls the printing routines with my specific options? If it can be done quick and dirty,
I'd rather do so now than be forced to find some solution other than Scribus.

ringerc

2005-07-25 05:50

reporter   ~0005708

No matter what, with the current architecture the whole app will still need the full app to start up, and will still require an X server. However, it shouldn't be excessively difficult to achieve cmdline PDF export within those restrictions. I've already added the code to save and load PDF settings, so what's required is to:

   - Eliminate the requirement for an interactive GUI pdf export dialog
   - Enable command line access to load settings, open a doc, and print a PDF,
     probably by extending main.cpp .

I'm hoping to do this by implementing the new plug-in API (0002097) to provide the ability to run scripts from the command line. With that, plus some improved PDF export from the scripter that should provide optimal flexibility, and a default export script can probably be provided too. With improved PDF export via scripter it'll be worth looking into XML-RPC based client/server export, too.

A simpler command-line option from main.cpp might be good later, but it might be hard to make one flexible enough to handle all the likely requirements, especially since folks will want to export many PDFs in a batch (due to the start-up time).

In future, Riku is hoping to refactor things so that a subset of functionality is available without full GUI startup, so further down the track that should be good.

rgpublic

2005-08-01 09:24

reporter   ~0005797

As no one has stepped up to our offer yet, I'd like to reinforce my
company's commitment to support this financially.
In case I dont get a response soon, I will try to resort to
emulate this via Python scripting but this is of course not the
desired solution. This bug shows that there are plans to implement
this anyway so I cannot imagine that nobody wants to do it a bit
earlier and at least contact me to agree on a time-frame and the money
required. We would then have to evaluate if this is acceptable for us
anyway. So far, I dont even have an idea how much this might cost.

cbradney

2005-08-01 09:47

administrator   ~0005798

I'd be willing to have a go at this. I'd need to know your constraints and requirements before committing 100% to it.

rgpublic

2005-08-02 08:44

reporter   ~0005824

Just for the record:
The details of this are now probably better worked out via private e-mail.
I therefore sent a mail to cbradney (at) scribus (dot) info
yesterday. I hope that's the right cbradney as I got the e-mail address
from the bug page footer ;-)

BarryB

2005-11-11 16:52

reporter   ~0007391

Does anyone know if any progress has been made on this?

ringerc

2005-11-11 17:13

reporter   ~0007392

Reminder sent to: BarryB

Any progress will generally be noted here. This isn't really the best place for general discussion (as opposed to suggestions, comments on the bug, clarifications, updates, etc); it's probably better to head over to the mailing list.

cbradney

2005-11-11 20:29

administrator   ~0007395

Progress will be noted when made in the direction of the issue. There has been a lot of progress made internally, but not yet exactly in this direction.

stroppytux

2006-03-02 10:02

reporter   ~0008991

Another option that might be worth while would be to enable you to specify the text (or image) for a certain object whilst exporting. Eg. './scribus --export-pdf --filename=~/invoicetemplate.sla --object bankdetails=barkleysbank.txt'. You could then recurse over a directory of 'customers for example' and auto-generate there addresses. (You could also probably do this with 'sed').

The next issue with this would be the ability to create a conversion library without the gui interface. This would enable large corporations to run a batch server to generate there invoices,templates,.... With so many applications written on the gnu/linux platform lately, they are forgetting that not all instalations are desktop machines. There should be no reason to install Xorg/gtk/qt/kde to do a conversion from one document format to another. The document parsing code should be contained within a standalone library, the interfaces should then be exactly that, (an interface between the user and the library).

cbradney

2006-03-02 10:03

administrator   ~0008992

I have a patch to do this from someone.. need the time to investigate the method properly.

TimH

2006-03-03 05:05

reporter   ~0009022

Being able to convert a scribus XML file to postscript on the command line would revolutionize my company's bill printing capabilities. This would allow us to use simeple XML templates to create complex documents and then easily send them by the hundreds to our postscript printer.

I currently can't think of anything as powerful or simple for the same task.

I whole-heartedly support a --to-ps option or some kind of scribus2ps program.

Please! :)

ringerc

2006-03-03 11:21

reporter   ~0009032

No longer has any assigned developer, fixing assigned status.

dell

2006-08-12 16:51

reporter   ~0012164

I concur, I would love to be able to process/generate large volumes of pdfs from Scribus format (to Press Quality Standards) as we dont have the money to invest in the likes of Adobe Server products.

mglauche

2006-08-30 14:36

reporter   ~0012376

cbradney: you said you have a patch for that, i'm currently looking into this issue as well, can you send me the patch (mg@connection-net.de)

kriks

2007-07-10 07:15

reporter   ~0016764

is there any piece of news about this?

is the patch publicly available?

any information would be really appreciated.

kriks

2010-07-08 14:14

reporter   ~0024299

is there any new piece of information available ?

bastio84

2011-02-12 16:48

reporter   ~0025566

Command line PDF export capability would be a very powerful tool!
Could be a Python start-up script, passed via CLI, of-course, running automatically with the document open...
News about this?

StefanM

2011-07-26 09:02

reporter   ~0026644

This would be a nice feature. Is there any development on this?

ale

2011-07-26 11:28

manager   ~0026645

yep, stefanM... and help is welcome!

i was planning to work on this this summer, but i had to change my plans...

i got two different patches to enable the command line creation of PDF and they must be fixed / tested / enhanced and -- most of all -- ported to 1.5svn!

i plan to work on this later in the summer / during fall and have a working prototype at the beginning of 2012...

jzeleny

2012-02-28 21:39

reporter   ~0027767

ale, I'd like to ask about this feature as well. Has the development moved somewhere? I noticed on several places that this is on your plan but it is being rescheduled for quite some time. How much work do you think remains for proof-of-concept or something like that? I'd like to know if I might be of any assistance.

Thanks in advance.
Jan

ale

2012-11-19 12:37

manager   ~0029215

hi jan,

personally, i'd like to work on it after 1.6 has been released. the fact that there is no 1.6 in sight, explains why there are no news on this from my side.

but if somebody wants to work on it, i can share the main ideas i've had...

personally, i'd like to go for a "scribus-console" application (like gimp does with "gimp-console").
this would allow a simpler, step by step, approach, where we can see some results without having to wait for the patches being integrated into the main application. this should be doable without having to scramble too much the main code and allow people to better cooperate.
at the end i can imagine that scribus-console and scribus are made a unique application again.

the first steps would be:

- create a git project called "scribus-console".
- create the cpp files needed for an empty "scribus-console" program and patch the cmake file in order to let compile both "scribus" and "scribus-console" in the same project.
- the "scribus" and "scribus-console" programs will link to the same .h files
- start to put basic commands into the "scribus-console" sub-project, test the code in there and, when needed, propose patches for the main "scribus" libraries in order to make it better fit the "console" use.

any thoughts?

i can create the "scribus-console" branch and give you write access to it...
the question is: do you have the skills to work on the first steps to launch the "gimp-console" program?

ciao
a.l.e

ale

2012-11-20 20:26

manager   ~0029219

i have created a scribus-console branch on the scribus git server.

i will try to create a github repositoriy for each patch set i got in the past...

JLuc

2014-10-24 18:16

developer   ~0034137

We are very close to it now. The 0012572 has added the --python-script command line option and enables to do so with appropriate script.
Even if not scrictly necessary, a --to-pdf option would still be userfriendly and much appreciated for the non-nerds users.

Kunda

2015-08-31 00:33

updater   ~0036127

linked 0013311

JLuc

2015-09-13 07:53

developer   ~0036202

0013311 is now merged and allows to pass command line arguments to the called script.

ale

2015-09-14 15:14

manager   ~0036218

personally, i don't see the interest of having a --to-pdf switch.

the script should open the file and create a pdf, probably using a specific export profile (this feature has still to be created... but i'm sure that it will come soon, now that one can somehow run scribus from the terminal).

once everything is on place, the pdf conversion is a trivial script that we can put in the wiki and everybody can use it as:

$ scribus -py to-pdf.py my-file.sla

i mean: every line of code we don't add is a line less that could have a bug... and given the size of the project, i'm really happy for each line that is not writte (of course, if we still get the feature... :-)

ale

2015-09-14 18:32

manager   ~0036234

this small script can replace the -to-pdf command line argument:

https://github.com/aoloe/scribus-script-repository/tree/master/to-pdf

the usage is

scribus -g -py to-pdf.py my-file.sla

and it then creates a my-file.pdf file.

william

2016-04-01 19:52

updater  

export_to_pdf.py (1,705 bytes)   
#!/usr/bin/env python
# -*- coding: utf-8 -*-

""" 
Convert a document to a PDF

Run with a command like
        scribus -g -py export_to_pdf.py -version 13 -useDocBleeds 0 -bleedr 2 -compress 1 -info 'test title' -file 'test.pdf' -pages '[1, 2]' -- testdoc.sla

You can set any "pdf" attribute with "-attribute value".

Tested with scribus 1.5.2.svn r21147

Author: William Bader, Director of Research and Development, SCS, http://www.newspapersystems.com
15Sep15 wb		initial version
31Mar16 Jural Fedel	simplified, added support for page ranges

"""

import scribus
import sys
import ast

def main(argv):
        pdf = scribus.PDFfile()
        i = 1
        while i < len(argv):
                if (argv[i][0] != '-'):
                        raise Exception("PDF option expected instead of: '{0}'".format(argv[i]))
                name = argv[i][1:]
                pdf_attr = getattr(pdf, name)
                i = i + 1
                try:
                        value = argv[i]
                except:
                        msg = "Option '{0}' require value".format(name)
                        raise Exception(msg)
                if isinstance(pdf_attr, basestring):
                        setattr(pdf, name, value)
                else:
                        val = None
                        try:
                                val = ast.literal_eval(value)
                        except:
                                msg = "'{0}' =/= '{1}'".format(name, value)
                                raise ValueError(msg)
                        setattr(pdf, name, val)
                i = i + 1
        pdf.save()

# start the script
if __name__ == '__main__':
        main(sys.argv)

export_to_pdf.py (1,705 bytes)   

william

2016-04-01 20:04

updater   ~0039687

I uploaded a version of export_to_pdf.py modified by Juraj Fedel.
It adds support for printing selected pages from a document.
The example command line below uses -pages '[2,4]' to print pages 2 and 4 of a multi-page document. As before, you can set any attribute documented under Help -> Scribus Manual -> Contents -> For Developers -> Scripter API -> PDF Export.
Use 0 or 1 to set boolean values.

scribus -g -py export_to_pdf.py -version 13 -useDocBleeds 0 -bleedr 2 -compress 1 -info 'test title' -file 'test.pdf' -pages '[2,4]' -- testmultipage.sla

Kunda

2016-04-01 21:42

updater   ~0039690

greg, would you take a look at 0000238:0039687 ?

Kunda

2016-05-19 23:12

updater   ~0041239

gregp, ping

JLuc

2016-06-06 17:35

updater   ~0041619

Documentation for scribus 1.5 command line scripting : https://wiki.scribus.net/canvas/Command_line_scripts

Issue History

Date Modified Username Field Change
2004-02-02 14:40 mhanski New Issue
2004-02-03 05:04 plinnell Note Added: 0000428
2004-02-03 05:04 plinnell Priority normal => low
2004-02-03 05:04 plinnell Projection none => major rework
2004-02-03 05:04 plinnell ETA none => > 1 month
2004-02-03 05:04 plinnell Product Version => 1.3
2004-02-03 10:46 ale Note Added: 0000429
2004-04-15 13:36 user171 Note Added: 0001074
2004-05-04 18:46 subik Note Added: 0001350
2004-06-21 12:28 mhanski Note Added: 0001807
2004-06-21 17:06 malex Note Added: 0001809
2004-06-22 09:15 user171 Note Added: 0001815
2004-06-22 10:53 cbradney Note Added: 0001816
2004-06-22 10:58 cbradney Note Edited: 0001816
2004-09-05 19:07 ringerc Note Added: 0002297
2004-09-24 15:01 packetbell Note Added: 0002507
2004-09-24 15:04 packetbell Note Added: 0002509
2004-09-24 17:44 deejay1 Relationship added related to 0001123
2004-09-24 19:51 jmh Note Added: 0002518
2004-10-07 09:09 mglauche Note Added: 0002647
2004-10-10 12:56 subik Status new => assigned
2004-10-10 12:56 subik Assigned To => subik
2005-02-25 06:54 ringerc Note Added: 0003817
2005-04-08 04:43 ringerc Note Added: 0004141
2005-04-21 09:11 mhanski Relationship added related to 0001898
2005-07-14 08:26 mhanski Description Updated
2005-07-14 22:25 christoph_s Note Added: 0005587
2005-07-25 04:41 BarryB Note Added: 0005707
2005-07-25 05:50 ringerc Note Added: 0005708
2005-07-25 05:50 ringerc Note Edited: 0005707
2005-08-01 09:24 rgpublic Note Added: 0005797
2005-08-01 09:47 cbradney Note Added: 0005798
2005-08-01 09:47 cbradney Assigned To subik =>
2005-08-02 08:44 rgpublic Note Added: 0005824
2005-11-11 16:52 BarryB Note Added: 0007391
2005-11-11 17:13 ringerc Note Added: 0007392
2005-11-11 20:29 cbradney Note Added: 0007395
2006-03-01 14:38 mhanski Description Updated
2006-03-02 10:02 stroppytux Note Added: 0008991
2006-03-02 10:03 cbradney Note Added: 0008992
2006-03-03 05:05 TimH Note Added: 0009022
2006-03-03 11:21 ringerc Note Added: 0009032
2006-03-03 11:21 ringerc Status assigned => acknowledged
2006-03-03 12:35 cbradney Status acknowledged => assigned
2006-03-03 12:35 cbradney Assigned To => cbradney
2006-04-07 18:36 mhanski Relationship added related to 0000967
2006-05-17 17:51 mhanski Relationship added related to 0003831
2006-08-12 16:51 dell Note Added: 0012164
2006-08-30 14:36 mglauche Note Added: 0012376
2007-07-10 07:15 kriks Note Added: 0016764
2010-07-08 14:14 kriks Note Added: 0024299
2011-02-12 16:48 bastio84 Note Added: 0025566
2011-07-26 09:02 StefanM Note Added: 0026644
2011-07-26 11:28 ale Note Added: 0026645
2012-02-28 21:39 jzeleny Note Added: 0027767
2012-11-19 12:37 ale Note Added: 0029215
2012-11-20 20:26 ale Note Added: 0029219
2014-07-08 04:03 Kunda Target Version => 1.7 milestone
2014-07-21 00:08 Kunda Relationship added related to 0009331
2014-07-21 00:09 Kunda Relationship deleted related to 0009331
2014-07-30 03:47 Kunda Relationship added related to 0012572
2014-10-24 18:16 JLuc Note Added: 0034137
2015-03-05 17:05 Kunda Patch => No
2015-03-05 17:05 Kunda Target Version 1.7 milestone => Future Release - Nice to have
2015-08-31 00:32 Kunda Relationship added related to 0013311
2015-08-31 00:33 Kunda Note Added: 0036127
2015-09-13 07:53 JLuc Note Added: 0036202
2015-09-14 15:14 ale Note Added: 0036218
2015-09-14 18:32 ale Note Added: 0036234
2016-04-01 19:52 william File Added: export_to_pdf.py
2016-04-01 20:04 william Note Added: 0039687
2016-04-01 21:42 Kunda Note Added: 0039690
2016-05-19 23:12 Kunda Note Added: 0041239
2016-05-19 23:12 Kunda Tag Attached: #pending
2016-05-19 23:13 Kunda Tag Attached: discussion
2016-06-06 17:35 JLuc Note Added: 0041619