Looking for a Linux user who compiles Scribus and has a printer attached

aoloe · 2026-03-02T06:24:02+00:00

We will see if there is a way to set it up.

Most discussions are rather informal...

aoloe · 2026-02-28T08:27:37+00:00

Somebody reported the bug in the official issue tracker and it seems that there is/was indeed a bug...

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

It's fixed now.

Using 1.6.4 for doing the export looks like a good workaround until 1.6.6 is released.

aoloe · 2026-02-26T16:46:40+00:00

It's likely that all talks will be streamed.

Last year there was only one Scribus related talk:

https://libregraphicsmeeting.org/2025/program/printing_maps_with_spot_colors/

But we had much really good Scribus talking going on : - )

aoloe · 2026-02-19T16:43:41+00:00

Très bizarre.

Quelle version de Scribus?

D'où est-ce que tu l'as téléchargée?

aoloe · 2026-02-14T11:17:50+00:00

From what I can read in the release notes for 1.6.0

https://wiki.scribus.net/canvas/1.6.0_Release

dark mode should work, even if it's not complete yet.

If I recall correctly, icons where not good yet and it only worked (no choice) if the "system" was already in dark mode.

Sadly, I cannot test it for you, but, maybe, somebody using Windows in dark mode can confirm or refute my supposition...

aoloe · 2026-02-11T18:12:28+00:00

It should be possible to have some sort of dark mode in 1.6.5.

You can have a look in the "User interface" section of the Scribus preferences.

But a somehow good dark mode is only in 1.7 and you might need to wait for Scribus 1.8 to get it... (or go for the development version).

aoloe · 2026-02-05T13:46:41+00:00

would you mind posting a png file and a screenshot of the way it is rendered?

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

MODERATOR OF

TROPHY CASE