View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000238 | Scribus | General | public | 2004-02-02 14:40 | 2016-09-09 16:14 |
| Reporter | mhanski | Assigned To | cbradney | ||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | assigned | Resolution | open | ||
| Product Version | 1.3 | ||||
| Target Version | Future Release - Nice to have | ||||
| Summary | 0000238: New CL option: scribus --to-pdf <scribus-file> <output.pdf> | ||||
| Description | A new command line option that would allow to create on the fly PDF forms or documents without starting the Scribus GUI. | ||||
| Tags | #pending, discussion | ||||
| Patch | No | ||||
| related to | 0001123 | acknowledged | Save printer settings | |
| related to | 0013311 | closed | cbradney | 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 | assigned | cbradney | CLI option -p |
| related to | 0003831 | acknowledged | Metabug: PDF Forms | |
| related to | 0012572 | closed | cbradney | [patch] Add a --python-script command line option to run a script and exit |
|
|
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. |
|
|
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! |
|
|
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. |
|
|
yes, it's about 90 options (taken from source code)... it's realy uncomfortable to have all of them in CLI option set - IMHO. |
|
|
>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. |
|
|
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. |
|
|
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... |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
Also see bug 1123 |
|
|
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. |
|
|
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 :) |
|
|
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. |
|
|
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. |
|
|
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 ... |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
I'd be willing to have a go at this. I'd need to know your constraints and requirements before committing 100% to it. |
|
|
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 ;-) |
|
|
Does anyone know if any progress has been made on this? |
|
|
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. |
|
|
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. |
|
|
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). |
|
|
I have a patch to do this from someone.. need the time to investigate the method properly. |
|
|
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! :) |
|
|
No longer has any assigned developer, fixing assigned status. |
|
|
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. |
|
|
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) |
|
|
is there any piece of news about this? is the patch publicly available? any information would be really appreciated. |
|
|
is there any new piece of information available ? |
|
|
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? |
|
|
This would be a nice feature. Is there any development on this? |
|
|
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... |
|
|
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 |
|
|
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 |
|
|
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... |
|
|
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. |
|
|
linked 0013311 |
|
|
0013311 is now merged and allows to pass command line arguments to the called script. |
|
|
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... :-) |
|
|
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. |
|
|
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)
|
|
|
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 |
|
|
greg, would you take a look at 0000238:0039687 ? |
|
|
gregp, ping |
|
|
Documentation for scribus 1.5 command line scripting : https://wiki.scribus.net/canvas/Command_line_scripts |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-02-02 14:40 | mhanski | New Issue | |
| 2004-02-03 05:04 |
|
Note Added: 0000428 | |
| 2004-02-03 05:04 |
|
Priority | normal => low |
| 2004-02-03 05:04 |
|
Projection | none => major rework |
| 2004-02-03 05:04 |
|
ETA | none => > 1 month |
| 2004-02-03 05:04 |
|
Product Version | => 1.3 |
| 2004-02-03 10:46 | ale | Note Added: 0000429 | |
| 2004-04-15 13:36 |
|
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 |
|
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 |
|
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 |
|
Note Added: 0003817 | |
| 2005-04-08 04:43 |
|
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 |
|
Note Added: 0005708 | |
| 2005-07-25 05:50 |
|
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 |
|
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 |
|
Note Added: 0009032 | |
| 2006-03-03 11:21 |
|
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 |
