sla2pdf

[mara004]

Hello,

I would like to notify the Scribus community of a small SLA to PDF converter I've written. It's powered by Scribus scripts and can be used both via command line or Python API:
https://github.com/sla2pdf-team/sla2pdf

I believe it's kind of more sophisticated/convenient than the already existing examples.
Due to the subprocess wrapper, it can also be used as library in an independent Python interpreter.

Perhaps it would be useful to mention sla2pdf somewhere in this repository, or in the Scribus docs?

[aoloe]

hi mara004

thanks for reaching me : - )

here some notes while i'm going through your repository:

• you don't need to be compatible with python 2: modern scribus only works with python 3
• i would not separate the input and output file names in two different lists, but create a list of pairs [input.sla, output.pdf], where you might use only one values ([input.sla]) and automatically set the output by replacing the sla by pdf.
• since your goal is to process multiple files, i would suggest to put the arguments to convert in a json file instead. in this way you can give a name to your configuration and reuse for later batches.
• i did not know about the -platform offscreen!
  nice one. sadly, a comment i've found on stackoverflow seems to warn against using it... do you have further information?

this having been said, i can see where i can add a mention of your "library".

the simplest way to do it, is probably to add a "light" version of your script in here and refer there to your script.
i already have a sla2pdf script in this repository. that script is more about imposing the sla file, so i can think of renaming it and free the name for your script.

personally, i see an interest in having here a sla2pdf that batch converts multiple files according to a specific profile.
would you be interested in working on such a script?

[mara004]

Hi Ale,

thanks for your notes. Here are my comments:

you don't need to be compatible with python 2: modern scribus only works with python 3

The concern was Scribus builds shipped by Linux distributions. For instance, Scribus as provided by Ubuntu 20.04 is still built against Python 2. Note that not the whole codebase is Python 2 comptaible, only those parts that run inside Scribus. Keeping it like that isn't difficult, anyway.

i would not separate the input and output file names in two different lists, but create a list of pairs [input.sla, output.pdf], where you might use only one values ([input.sla]) and automatically set the output by replacing the sla by pdf.

The CLI (__main__.py) already does auto-naming (changing the suffix to pdf). I could certainly move that code to make output_paths optional in the Python API. However, I'm not sure if I want to join inputs and outputs - I don't see any advantage in that (quite the contrary). (But I yet need to assert equal length, thanks for the reminder.)

since your goal is to process multiple files, i would suggest to put the arguments to convert in a json file instead. in this way you can give a name to your configuration and reuse for later batches.

personally, i see an interest in having here a sla2pdf that batch converts multiple files according to a specific profile.
would you be interested in working on such a script?

I don't think there's any point at involving JSON here? The way I usually invoke sla2pdf is just

sla2pdf *.sla -o out/

If you've got a more complex command you can simply save it as a bash script.
Or in case you want to do something more sophisticated, you can also call convert() in a Python script and benefit from the extended capabilities.

I also plan to add an option for explicit output paths to the CLI, beside the current output directory option.

i did not know about the -platform offscreen!
nice one. sadly, a comment i've found on stackoverflow seems to warn against using it... do you have further information?

Thanks for pointing me at this thread. So far, I haven't had any problem with -platform offscreen / QT_QPA_PLATFORM=offscreen, but there's the show_gui/--show-gui parameter that lets you opt out. I don't intend to make this default behaviour, though, since an API function shouldn't unexpectedly launch a GUI.

the simplest way to do it, is probably to add a "light" version of your script in here and refer there to your script.

Well, you already have that "light" version. The whole point of my code is that it's not just a single script, but instead an easy to install/use and independently accessible Python module, thanks to the separation into a part that runs inside Scribus and a convenient subprocess wrapper around it.

[mara004]

See also this announcement I wrote: pypdfium2-team/pypdfium2#162

[mara004]

since your goal is to process multiple files, i would suggest to put the arguments to convert in a json file instead. in this way you can give a name to your configuration and reuse for later batches.

Ah, I now think I understand you better. Your comment hints at this problem that we currently have a restricted set of options implemented explicitly as argparse parameters. In the future, it would be nicer if we could just take a dictionary-like data structure and allow the caller to set arbitrary attributes on the PDFFile object using setattr(). Once we have that, your JSON idea might actually make sense.

I'll work on that.

[mara004]

What do you think of this suggestion?
sla2pdf-team/sla2pdf#1

[aoloe]

ok , i guess it's easier if i show you what i had in mind : - )

it should not take too long...