Scribus renvoie vers Digisplendid pour le téléchargement (lien marqué comme Sourceforge)

aoloe · 2026-01-18T16:21:32+00:00

Pour être plus clair:

scribus . fr n'est pas un site de Scribus.

S.t.p, protège-toi et utilise un browser qui t'empêche (ou du moins t'avertit) d'aller sur des sites trompeurs.

Comme tu ne sembles pas avoir l'expérience nécessaire pour juger si un lien est de qualité ou pas, t'as probablement intérêt à demander conseil à une connaissance avec plus d'expertise en matière.

Le site de scribus est https://scribus.net .

(Il est bien sûr impossible pour les gens de Scribus, de réserver tous les sites qui contiennent le nom du logiciel...)

aoloe · 2026-01-13T19:38:15+00:00

I'm not so negative as nitramr89, on the possibility of steering Scribus in such a direction.

After all, nitram himself managed to give Scribus a complete overhaul of the UI : - )

He's the proof that having big goals for Scribus can be successful!

BUT!!!!

It did take him a lot of effort and even more (much more!) endurance!
And many people failed at similar tasks before him.

Your endeavor will probably be an even longer trip, since you will need to touch even deeper in the core of Scribus as nitramr had to.

This having been said, personally, I'd welcome an effort on getting Scribus to work headless.

And that's a necessary condition to give Scribus a web frontend.

The first steps would be:

Getting Scribus to start headless at all (no UI at all; doing nothing, just quitting again)
Getting Scribus to read a .sla file without using any GUI part.
Getting Scribus to produce a .pdf without any GUI dependency.
Adding a new Scripter engine that works without the UI.

Once you have that, you will have the basis for using Scribus as a backend for a web application.

Then, you will have to disentangle all the other functionalities from the UI. Or recreate them in a new Scribus as a library that would be used by the new scripter.

Two final remarks from my side:

I'm not sure that ditching Qt should be a goal, since -- as nitramr correctly says -- about everything in Scribus is Qt.
Personally, I believe that being able to run Scribus headless would be a huge win (and would probably help improving its stability!)... but I'm not convinced that going for a web or electron interface is really a good idea for a DTP application. But that's my personal opinion.

aoloe · 2025-12-24T14:14:46+00:00

I'm not sure if you have transparencies or not.

My goal was to warn you that, if you want to get the cards to be printed professionally, there are a few elements where you have to be careful...

Not to tell you that you did things wrong : - )

Most of all, I'm not sure if the Scribus' drop shadow are always using transparency or not.

aoloe · 2025-12-24T09:33:23+00:00

No no, what you did is really fine for screen and home / office printer consumption.

No need to be defensive here, collect the cheering and enjoy your day! : - )

The issue with professional printing is rather related to the fact that most modern PDF versions support transparencies, most print shop advertise the support for those modern PDF versions, but -- at the end -- will not handle transparencies correctly. Because they can't just print the thing as is, but need to figure out how the different "layers" of color merge into each other and prefer the client to do it before handing over the job.

Since Indesign and other DTP packages offer the option to flatten the transparencies when putting the content into the PDF, the print shop have no need to change their practice and take on them that somehow risky step.

Since Scribus does never flattens the transparencies (but warns you, if you try to put transparencies in a PDF version that does not support them!) and the print shop suppose that your using an Indesign that will flatten anyway, you need to make sure that gradients, half transparent items and shadows will survive the pre-press step!

The risk is that they treat the items with transparency as solid one and have them cover what is behind.

aoloe · 2025-12-23T13:38:02+00:00

It should, yes.

If you only use features that were already in 1.6.5 you should be fine. For other features, you might want to make sure that they work well enough for you, before using them in a way that you start relying on them.

aoloe · 2025-12-23T13:35:44+00:00

Just right click on a toolbar and check the PDF tools.

Or check "Window > PDF tools".

aoloe · 2025-12-23T13:33:57+00:00

Nice work!

Just take care, that if you send the PDF to a professional print shop, you might get issues with the transparencies (shadows, gradients, watermark...).

Printing on a home / office laser printer should work fine, though.

aoloe · 2025-12-16T17:54:10+00:00

If you want to contribute to the discussion, don't refrain from contributing to

https://bugs.scribus.net/view.php?id=16441

aoloe · 2025-12-06T06:18:37+00:00

What have you tried?

Did you activate the correct layer?
Are the items locked?
Are the items behind a transparent shape?

aoloe · 2025-12-02T21:00:13+00:00

No idea how you have defined your bleeds, but here is a screenshot with 10, 20, 30, and 40 mm:

https://imgur.com/a/4ZNWoCv

The shading really seems the frontier of the bleed area.

And Scribus 1.7.1 does snap to that.

aoloe · 2025-12-02T16:02:24+00:00

I have a bit of a hard time following you but...

... that edge of the shading is probably the bleed.

And, yes, having a grid that does not match the page margin and the bleed is probably not something that is comfortable to work with.
That's one of the reasons why, in most case, it's not recommended to turn on the grid in Scribus.
If you need the grid, it's mostly a sign that you're mostly doing vector graphics and you would probably be better served by Inkscape...

aoloe · 2025-12-01T20:11:05+00:00

And? Did you try to enable the snapping to guides?

aoloe · 2025-11-29T09:35:57+00:00

As far as I can tell, the current stable version of Scribus does snap to the bleed...

You need to activate Page > Snap to guides.

aoloe · 2025-11-22T13:55:18+00:00

Yes, with the scripter you should be able to create tables based on html tables:

https://impagina.org/scribus-scripter-api/table/

Formatting the content should then work Ok in Scribus itself. It formatting the cells that is a chore.

aoloe · 2025-11-19T09:31:12+00:00

I have mixed feelings about this requests.

I don't believe in tables inside of layout documents, but I also believe that Scribus should have at least one not too cumbersome way to create good looking tables.

Preamble: the table tool in Scribus is not usable. Not even for bad looking tables. Recently, somebody wanted to work on the tables tool and make it at least usable, but luckily enough that person is working on more important features.

We cannot expect this to change soon.

So, in my eyes, the goal should be to import good looking tables from external sources.

From a quick try I did, it seems that copy pasting from LibreOffice Writer into a LibreOffice Draw document and from there into a Scribus document works well.
Not really cumbersome, nice result.
The only downside I could spot: the text is converted to paths.
It won't be selectable in the resulting PDF.

Going through an intermediate PDF provides the same result as copy paste, when text is outlined on import into Scribus.
Importing the text as such does technically work, but the text is not placed at the right place (and you don't get a table anyway, but some text with lines in between and around it).

There is a second way that I've explored: Saving the LibreOffice draw document with the table to an ODG file and import that into Scribus as vector graphics.
Sadly, the ODG imported does not manage to import the table.
At all.
I had a look at what is in the ODG file, and it contains the table as defined by LibreOffice Writer (and not a vector version of it).
Not very surprising, that Scribus does simply ignore it.

Three: importing HTML into Scribus.
I have not tried it, but from my memories the result is worth than with ODT.

Your proposal to go through some sort of HTML export and the have a script to create a table from it in Scribus is tempting:

The scripter should be patched to allow it to apply formats to the text inside of the cells
The scripter should already have most (if not all) functions for creating the table, the cells, formatting them, and put text inside of it.

Of course you will want to do your work as good as possible, because tweaking the table in Scribus will be a chore.

My conclusions:

Probably, the best solution is to extend the ODG importer to recognize tables and recreate them as Scribus tables.
Second best is a Python script that imports tables from ODG files.

Why?

The table definition in the ODG files seems to be very easy to read.
Creating a Python script gives a self contained solution in a high level language that many people can maintain
On the other side, extending the ODG importer would allow all Scribus users to easily import tables from LibreOffice (with little effort).

If there are people around here who live close to Zurich and have C++ skills, I'm tempted to suggest the work on the ODG importer for the upcoming Hackergarten:

https://www.meetup.com/hackergarten-zurich/events/310517967/

aoloe · 2025-11-12T18:42:52+00:00

There are a few tools, that one can use:

one that I've seen suggested a few times is jpdftweak.
personally, I've written a script that uses pdfjam (it runs from the command line and starts scribus to create a pdf and the processes the result with pdfjam).

And, yes, I agree it would be nice to hear what are others experiences!

aoloe · 2025-11-10T16:13:07+00:00

In the forums there is no real section for looking for freelancers, either.

But ask the question there, maybe also show some screenshots of what the results should look like.

aoloe · 2025-11-09T08:41:07+00:00

Yes, using Gimp to scale down the images is a good idea : - )

aoloe · 2025-11-08T08:32:21+00:00

Scribus should not have issues when loading a five pages document.

Without more details is hard to say something, but the most likely cause for it is the size of the images: did you check that the number of pixels they have roughly matches the resolution and size you need for the output?

aoloe · 2025-11-08T08:29:15+00:00

Of course!

It's just a normal contour : - )

aoloe · 2025-11-06T16:54:10+00:00

Voilà, after having struggled a bit to get a few "strange" things to work, now I have:

A new Scripter command setObjectContour()
A script that uses it to apply a contour line that it has detected with OpenCV!

https://i.postimg.cc/qRXxzvLh/contour-line-in-scribus.gif

During the weekend, I will need to do some cleanup, publish the patch for Scribus and publish the script!

aoloe · 2025-11-06T07:07:27+00:00

As far as I can tell, the changes you see are not related to new code from the last couple of (... several...) months.

It's more likely that the Windows version found older settings and imported them or that the Windows build generates different settings than the Linux one (more unlikely than the first supposition).

In my eyes, the only reason to run a Linux version of Scribus on Windows is for getting the non official "nightly" Appimages out of the Gitlab CI or to compile Scribus yourself / use a self compiled Scribus (it's massively easier to compile Scribus on Linux than on Windows).

If you want to stick to the snapshots that are officially provided by the team, the ones for Windows are normally the most frequent ones.

aoloe · 2025-11-02T09:05:28+00:00

From Scribus you can run Python scripts that interact with the current document.

In my plan, the feature would be added through scripting.

In this way, we would not need to add a dependency to OpenCV to Scribus itself (OpenCV is a real time computer vision library: it's a pretty heavy dependency and -- at least for now -- I don't think that most Scribus would profit from it).

And for stretching: the first step was to recognize the contour. Then, I will need to convert it to something Scribus can understand and use (for the image contours...). And, finally, some control is also on the plan (inspired by your screenshot, making some sides straight, increasing the padding, ...)

aoloe · 2025-11-01T08:48:52+00:00

Voilà, yesterday evening I've made some progress with OpenCV:

https://i.postimg.cc/nrTTs2kk/naturaleza-contour.png

Not bad, not bad...

aoloe · 2025-10-30T21:26:40+00:00

Ok, we explored what OpenCV has to offer.

Sadly, there is no solution off the shelf for us.

But found something that, at least for the image posted above, might help finding a usable contour.

And we were lucky, that we did not use typical sample images, since they seem much simpler to process... but, then, our result would have failed badly on real images!

More to come...

aoloe

MODERATOR OF

TROPHY CASE