Mantis Issue Tracking for Scribus
· Hosting provided by Anduin.net / Øverby Consulting ·

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000238ScribusGeneralpublic04-Feb-02 15:4014-Jul-21 02:08
Reportermhanski 
Assigned Tocbradney 
PrioritylowSeverityfeatureReproducibilityN/A
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version1.3 
Target Version1.7 milestoneFixed in Version 
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.
TagsNo tags attached.
Attached Files

- Relationships
related to 0001123acknowledged Save printer settings 
related to 0001898acknowledged Support saving, loading, and verifying sets of PDF settings 
related to 0000967assignedcbradney CLI option -p 
related to 0003831acknowledged Metabug: PDF Forms 

-  Notes
(0000428)
plinnell (administrator)
04-Feb-03 06:04

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.
(0000429)
ale (manager)
04-Feb-03 11:46

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!
(0001074)
hus (reporter)
04-Apr-15 15:36

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.
(0001350)
subik (manager)
04-May-04 20:46

yes, it's about 90 options (taken from source code)... it's realy uncomfortable to have all of them in CLI option set - IMHO.
(0001807)
mhanski (developer)
04-Jun-21 14:28

>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.
(0001809)
malex (administrator)
04-Jun-21 19:06

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.
(0001815)
hus (reporter)
04-Jun-22 11:15

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...
(0001816)
cbradney (administrator)
04-Jun-22 12:53
edited on: 04-Jun-22 12: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
(0002297)
ringerc (administrator)
04-Sep-05 21:07

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.
(0002507)
packetbell (reporter)
04-Sep-24 17:01

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.
(0002509)
packetbell (reporter)
04-Sep-24 17:04

Also see bug 1123
(0002518)
jmh (reporter)
04-Sep-24 21:51

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.
(0002647)
mglauche (reporter)
04-Oct-07 11:09

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 :)
(0003817)
ringerc (administrator)
05-Feb-25 07:54

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.
(0004141)
ringerc (administrator)
05-Apr-08 06:43

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.
(0005587)
christoph_s (administrator)
05-Jul-15 00:25

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 ...
(0005707)
BarryB (reporter)
05-Jul-25 06:41
edited on: 05-Jul-25 07: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.

(0005708)
ringerc (administrator)
05-Jul-25 07:50

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.
(0005797)
rgpublic (reporter)
05-Aug-01 11:24

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.
(0005798)
cbradney (administrator)
05-Aug-01 11:47

I'd be willing to have a go at this. I'd need to know your constraints and requirements before committing 100% to it.
(0005824)
rgpublic (reporter)
05-Aug-02 10:44

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 ;-)
(0007391)
BarryB (reporter)
05-Nov-11 17:52

Does anyone know if any progress has been made on this?
(0007392)
ringerc (administrator)
05-Nov-11 18:13

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.
(0007395)
cbradney (administrator)
05-Nov-11 21:29

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.
(0008991)
stroppytux (reporter)
06-Mar-02 11:02

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).
(0008992)
cbradney (administrator)
06-Mar-02 11:03

I have a patch to do this from someone.. need the time to investigate the method properly.
(0009022)
TimH (reporter)
06-Mar-03 06:05

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! :)
(0009032)
ringerc (administrator)
06-Mar-03 12:21

No longer has any assigned developer, fixing assigned status.
(0012164)
dell (reporter)
06-Aug-12 18:51

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.
(0012376)
mglauche (reporter)
06-Aug-30 16:36

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)
(0016764)
kriks (reporter)
07-Jul-10 09:15

is there any piece of news about this?

is the patch publicly available?

any information would be really appreciated.
(0024299)
kriks (reporter)
10-Jul-08 16:14

is there any new piece of information available ?
(0025566)
bastio84 (reporter)
11-Feb-12 17:48

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?
(0026644)
StefanM (reporter)
11-Jul-26 11:02

This would be a nice feature. Is there any development on this?
(0026645)
ale (manager)
11-Jul-26 13:28

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...
(0027767)
jzeleny (reporter)
12-Feb-28 22:39

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
(0029215)
ale (manager)
12-Nov-19 13:37

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
(0029219)
ale (manager)
12-Nov-20 21:26

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...

- Issue History
Date Modified Username Field Change
04-Feb-02 15:40 mhanski New Issue
04-Feb-03 06:04 plinnell Note Added: 0000428
04-Feb-03 06:04 plinnell Priority normal => low
04-Feb-03 06:04 plinnell Projection none => major rework
04-Feb-03 06:04 plinnell ETA none => > 1 month
04-Feb-03 06:04 plinnell Product Version => 1.3
04-Feb-03 11:46 ale Note Added: 0000429
04-Apr-15 15:36 hus Note Added: 0001074
04-Apr-20 12:57 mhanski Note Added: 0001132
04-Apr-20 12:58 mhanski Note Edited: 0001132
04-May-04 20:46 subik Note Added: 0001350
04-Jun-21 14:28 mhanski Note Added: 0001807
04-Jun-21 19:06 malex Note Added: 0001809
04-Jun-22 11:15 hus Note Added: 0001815
04-Jun-22 12:53 cbradney Note Added: 0001816
04-Jun-22 12:58 cbradney Note Edited: 0001816
04-Jul-14 15:38 mhanski Note Added: 0001967
04-Jul-17 09:44 mhanski Note Edited: 0001967
04-Sep-05 21:07 ringerc Note Added: 0002297
04-Sep-24 10:40 mhanski Note Added: 0002506
04-Sep-24 17:01 packetbell Note Added: 0002507
04-Sep-24 17:04 packetbell Note Added: 0002509
04-Sep-24 19:44 deejay1 Relationship added related to 0001123
04-Sep-24 21:51 jmh Note Added: 0002518
04-Oct-07 11:09 mglauche Note Added: 0002647
04-Oct-10 14:56 subik Status new => assigned
04-Oct-10 14:56 subik Assigned To => subik
04-Oct-29 18:48 mhanski Note Added: 0002778
05-Feb-25 07:54 ringerc Note Added: 0003817
05-Apr-08 06:43 ringerc Note Added: 0004141
05-Apr-21 11:11 mhanski Relationship added related to 0001898
05-Jul-12 17:36 ringerc Relationship added related to 0002231
05-Jul-14 09:37 mhanski Note Added: 0005582
05-Jul-14 09:37 mhanski Note Edited: 0005582
05-Jul-14 10:24 mhanski Note Edited: 0001132
05-Jul-14 10:25 mhanski Note Edited: 0001967
05-Jul-14 10:25 mhanski Note Edited: 0002506
05-Jul-14 10:25 mhanski Note Edited: 0002778
05-Jul-14 10:26 mhanski Description Updated
05-Jul-15 00:25 christoph_s Note Added: 0005587
05-Jul-25 06:41 BarryB Note Added: 0005707
05-Jul-25 07:50 ringerc Note Added: 0005708
05-Jul-25 07:50 ringerc Note Edited: 0005707
05-Aug-01 11:24 rgpublic Note Added: 0005797
05-Aug-01 11:47 cbradney Note Added: 0005798
05-Aug-01 11:47 cbradney Assigned To subik =>
05-Aug-02 10:44 rgpublic Note Added: 0005824
05-Nov-11 17:52 BarryB Note Added: 0007391
05-Nov-11 18:13 ringerc Note Added: 0007392
05-Nov-11 21:29 cbradney Note Added: 0007395
06-Mar-01 15:36 mhanski Note Deleted: 0001132
06-Mar-01 15:36 mhanski Note Deleted: 0001967
06-Mar-01 15:37 mhanski Note Deleted: 0002506
06-Mar-01 15:37 mhanski Note Deleted: 0005582
06-Mar-01 15:38 mhanski Description Updated
06-Mar-01 15:38 mhanski Note Deleted: 0002778
06-Mar-02 11:02 stroppytux Note Added: 0008991
06-Mar-02 11:03 cbradney Note Added: 0008992
06-Mar-03 06:05 TimH Note Added: 0009022
06-Mar-03 12:21 ringerc Note Added: 0009032
06-Mar-03 12:21 ringerc Status assigned => acknowledged
06-Mar-03 13:35 cbradney Status acknowledged => assigned
06-Mar-03 13:35 cbradney Assigned To => cbradney
06-Apr-07 20:36 mhanski Relationship added related to 0000967
06-May-17 19:51 mhanski Relationship added related to 0003831
06-Aug-12 18:51 dell Note Added: 0012164
06-Aug-30 16:36 mglauche Note Added: 0012376
07-Jul-10 09:15 kriks Note Added: 0016764
10-Jul-08 16:14 kriks Note Added: 0024299
11-Feb-12 17:48 bastio84 Note Added: 0025566
11-Jul-26 11:02 StefanM Note Added: 0026644
11-Jul-26 13:28 ale Note Added: 0026645
12-Feb-28 22:39 jzeleny Note Added: 0027767
12-Nov-19 13:37 ale Note Added: 0029215
12-Nov-20 21:26 ale Note Added: 0029219
14-Jul-08 06:03 Kunda Target Version => 1.7 milestone
14-Jul-21 02:08 Kunda Relationship added related to 0009331
14-Jul-21 02:09 Kunda Relationship deleted related to 0009331



Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker