File | Export | Save as PDF... - Causes crash SIG11

Previous topic - Next topic

ScribusRibus

Hi all,

As a noob to Scribus, unsurprisingly, I appear to have broken something!  ;D

I've created a new document, which looks just fine, and have been updating it for a few hours - although it has some very bizarre behaviour when editing some of the table cells at the moment, that may be a clue - I seem unable to export the document to PDF.

I can export to any other format, with varying success with the final render, but as soon as I select "File | Export | Save as PDF..." Scribus crashes with SIG11 - although Scribus does manage to save an emergency file before it quits. This happens on both systems, detailed below.

I have managed to export the current version of the document as PostScript, then import that version to export as a PDF, but I've not been able to export to a PDF directly from the current version of the document.  ???

My guess is that the odd behaviour of some of the table cells is caused by some internal file oddities, acquired from just using Scribus (a bug?) that are throwing the PDF export for a loop, but not the PS export et al.

Does anyone have any suggestions on how I can fix/troubleshoot or otherwise help you guys establish the cause to help fix this issue? - btw, I have NOT manually edited the file, although I have viewed it with less, and I have an idea why the table cells are acting up, and that may be what's causing the issue for exporting to PDF - but obviously "what do I know!"  8)

Many thanks  :D




Software version and System details:

* System 1


$ scribus -v
qt5ct: using qt5ct plugin

Scribus, Open Source Desktop Publishing
---------------------------------------
Homepage:       http://www.scribus.net
Documentation:  http://docs.scribus.net
Wiki:           http://wiki.scribus.net
Issues:         http://bugs.scribus.net

Scribus Version 1.5.5



$ inxi -bz
System:    Kernel: 5.4.0-91-generic x86_64 bits: 64 Desktop: Cinnamon 5.0.7 Distro: Linux Mint 20.2 Uma
Machine:   Type: Desktop System: NOVATECH product: BB-91008 v: V1.0 serial: <filter>
           Mobo: Gigabyte model: H310M S2H 2.0 v: x.x serial: <filter> UEFI [Legacy]: American Megatrends v: F14a
           date: 08/18/2020
CPU:       Quad Core: Intel Core i3-9100F type: MCP speed: 1577 MHz min/max: 800/4200 MHz
Graphics:  Device-1: NVIDIA GK208B [GeForce GT 710] driver: nvidia v: 470.86
           Display: x11 server: X.Org 1.20.11 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
           resolution: 1920x1080~60Hz, 1920x1080~60Hz
           OpenGL: renderer: NVIDIA GeForce GT 710/PCIe/SSE2 v: 4.6.0 NVIDIA 470.86
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Drives:    Local Storage: total: 1.61 TiB used: 624.55 GiB (37.9%)
Info:      Processes: 469 Uptime: 2d 5h 16m Memory: 31.31 GiB used: 22.51 GiB (71.9%) Shell: bash inxi: 3.0.38





* System 2


$ scribus -v

Scribus, Open Source Desktop Publishing
---------------------------------------
Homepage:       http://www.scribus.net
Documentation:  http://docs.scribus.net
Wiki:           http://wiki.scribus.net
Issues:         http://bugs.scribus.net

Scribus Version 1.5.7



$ inxi -bz
System:
  Kernel: 5.11.4-1-rt11-MANJARO x86_64 bits: 64 Desktop: Xfce 4.16.3
    Distro: Manjaro Linux
Machine:
  Type: Laptop System: LENOVO product: 20L50000UK v: ThinkPad T480
    serial: <superuser required>
  Mobo: LENOVO model: 20L50000UK v: SDK0J40697 WIN
    serial: <superuser required> UEFI: LENOVO v: N24ET37W (1.12 )
    date: 03/14/2018
Battery:
  ID-1: BAT0 charge: 16.6 Wh (97.6%) condition: 17.0/23.9 Wh (71.0%)
  ID-2: BAT1 charge: 19.4 Wh (100.0%) condition: 19.4/24.1 Wh (80.7%)
CPU:
  Info: quad core Intel Core i5-8250U [MT MCP] speed (MHz): avg: 2000
    min/max: 400/3400
Graphics:
  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel
  Device-2: IMC Networks Integrated Camera type: USB driver: uvcvideo
  Display: x11 server: X.Org 1.21.1.1 driver: loaded: modesetting
    resolution: 1920x1080
  OpenGL: renderer: Mesa Intel UHD Graphics 620 (KBL GT2)
    v: 4.6 Mesa 21.2.5
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e
  Device-2: Intel Wireless 8265 / 8275 driver: iwlwifi
  Device-3: Intel Bluetooth wireless interface type: USB driver: btusb
Drives:
  Local Storage: total: 1.03 TiB used: 438.45 GiB (41.7%)
Info:
  Processes: 465 Uptime: 7d 21h 52m Memory: 31.13 GiB used: 13.62 GiB (43.8%)
  Shell: Bash inxi: 3.3.10

toyotadesigner

If you have placed your tables on different layers, you can disable specific layers for printing/export by removing the check mark in the layers window. This might help you to locate the problematic table.

What I really don't understand: Why do you export a document as an *.eps, then import it again to export it as a PDF? Why can't you just export the documents straightforward as a PDF?



[attachment deleted by admin]

ScribusRibus

Quote from: toyotadesigner on December 17, 2021, 05:02:20 PM
If you have placed your tables on different layers, you can disable specific layers for printing/export by removing the check mark in the layers window. This might help you to locate the problematic table.

Unfortunately I have used only one layer - as the document is quite simple in design. Although, your suggestion has given me an idea! I could use the same idea per table, even though they are all on one layer, as each object has a button in the properties dialog to enable or disable exporting/printing of the object! - So thanks for that! I may be able to establish that a table is indeed the cause, and possibly narrow down the root cause of my issue in the process.

Quote from: toyotadesigner on December 17, 2021, 05:02:20 PM
What I really don't understand: Why do you export a document as an *.eps, then import it again to export it as a PDF? Why can't you just export the documents straightforward as a PDF?

Indeed, I would under normal circumstances export directly to PDF, but unfortunately that is precisely my issue - with the current document as it is I cannot export to PDF, the moment I select the menu item to export to PDF, Scribus crashes and exits.  :(

So, exporting the current document to any other format, which works - even though it has issues exporting to PDF - although some formats were more successful in terms of what is rendered in the output than others. The EPS format was the only format that would export and render from the current document as required - but, I ultimately needed a PDF format, hence export current document to EPS, import the resulting EPS, then export that to PDF. Voila! a PDF! 8)

toyotadesigner

Just create one or several new layers. Then select one (or more) table(s), right click -> Send to layer <layer name>, then disable the layer for printing/exporting.

ScribusRibus

#4
Quote from: toyotadesigner on December 17, 2021, 05:42:07 PM
Just create one or several new layers. Then select one (or more) table(s), right click -> Send to layer <layer name>, then disable the layer for printing/exporting.

Okay. I just tried that idea, and no luck.

First, I disabled export/printing of all text and table objects - priview mode showed nothing (all good) but attempting to export still crashed Scribus.
Second, I moved all those objects to a layer of their own - still disabled for export/printing - plus one other layer for some notes, and then also disabled the layer from export/printing - preview mode showed nothing (all good) but attempting to export still crashed Scribus.

Okay, It seems I can print, even blank pages because everything is disabled from export/printing! I can export a new empty document from start-up to PDF though! lol

...but even with all layers disabled for export/printing, I cannot export the current document to PDF.  :(

ScribusRibus

CORECTION:

I made a mistake in my explanation - I actually used Scribus to print the document, but to file instead of to printer.
The result was a PostScript file - NOT that I used Scribus to export to EPS (apologies if that confused anyone!)





Quote from: ScribusRibus on December 17, 2021, 04:45:25 PM
Hi all,

As a noob to Scribus, unsurprisingly, I appear to have broken something!  ;D

I've created a new document, which looks just fine, and have been updating it for a few hours - although it has some very bizarre behaviour when editing some of the table cells at the moment, that may be a clue - I seem unable to export the document to PDF.

I can export to any other format, with varying success with the final render, but as soon as I select "File | Export | Save as PDF..." Scribus crashes with SIG11 - although Scribus does manage to save an emergency file before it quits. This happens on both systems, detailed below.

I have managed to export the current version of the document as PostScript, then import that version to export as a PDF, but I've not been able to export to a PDF directly from the current version of the document.  ???

My guess is that the odd behaviour of some of the table cells is caused by some internal file oddities, acquired from just using Scribus (a bug?) that are throwing the PDF export for a loop, but not the PS export et al.

Does anyone have any suggestions on how I can fix/troubleshoot or otherwise help you guys establish the cause to help fix this issue? - btw, I have NOT manually edited the file, although I have viewed it with less, and I have an idea why the table cells are acting up, and that may be what's causing the issue for exporting to PDF - but obviously "what do I know!"  8)

Many thanks  :D




Software version and System details:

* System 1


$ scribus -v
qt5ct: using qt5ct plugin

Scribus, Open Source Desktop Publishing
---------------------------------------
Homepage:       http://www.scribus.net
Documentation:  http://docs.scribus.net
Wiki:           http://wiki.scribus.net
Issues:         http://bugs.scribus.net

Scribus Version 1.5.5



$ inxi -bz
System:    Kernel: 5.4.0-91-generic x86_64 bits: 64 Desktop: Cinnamon 5.0.7 Distro: Linux Mint 20.2 Uma
Machine:   Type: Desktop System: NOVATECH product: BB-91008 v: V1.0 serial: <filter>
           Mobo: Gigabyte model: H310M S2H 2.0 v: x.x serial: <filter> UEFI [Legacy]: American Megatrends v: F14a
           date: 08/18/2020
CPU:       Quad Core: Intel Core i3-9100F type: MCP speed: 1577 MHz min/max: 800/4200 MHz
Graphics:  Device-1: NVIDIA GK208B [GeForce GT 710] driver: nvidia v: 470.86
           Display: x11 server: X.Org 1.20.11 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
           resolution: 1920x1080~60Hz, 1920x1080~60Hz
           OpenGL: renderer: NVIDIA GeForce GT 710/PCIe/SSE2 v: 4.6.0 NVIDIA 470.86
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Drives:    Local Storage: total: 1.61 TiB used: 624.55 GiB (37.9%)
Info:      Processes: 469 Uptime: 2d 5h 16m Memory: 31.31 GiB used: 22.51 GiB (71.9%) Shell: bash inxi: 3.0.38





* System 2


$ scribus -v

Scribus, Open Source Desktop Publishing
---------------------------------------
Homepage:       http://www.scribus.net
Documentation:  http://docs.scribus.net
Wiki:           http://wiki.scribus.net
Issues:         http://bugs.scribus.net

Scribus Version 1.5.7



$ inxi -bz
System:
  Kernel: 5.11.4-1-rt11-MANJARO x86_64 bits: 64 Desktop: Xfce 4.16.3
    Distro: Manjaro Linux
Machine:
  Type: Laptop System: LENOVO product: 20L50000UK v: ThinkPad T480
    serial: <superuser required>
  Mobo: LENOVO model: 20L50000UK v: SDK0J40697 WIN
    serial: <superuser required> UEFI: LENOVO v: N24ET37W (1.12 )
    date: 03/14/2018
Battery:
  ID-1: BAT0 charge: 16.6 Wh (97.6%) condition: 17.0/23.9 Wh (71.0%)
  ID-2: BAT1 charge: 19.4 Wh (100.0%) condition: 19.4/24.1 Wh (80.7%)
CPU:
  Info: quad core Intel Core i5-8250U [MT MCP] speed (MHz): avg: 2000
    min/max: 400/3400
Graphics:
  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel
  Device-2: IMC Networks Integrated Camera type: USB driver: uvcvideo
  Display: x11 server: X.Org 1.21.1.1 driver: loaded: modesetting
    resolution: 1920x1080
  OpenGL: renderer: Mesa Intel UHD Graphics 620 (KBL GT2)
    v: 4.6 Mesa 21.2.5
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e
  Device-2: Intel Wireless 8265 / 8275 driver: iwlwifi
  Device-3: Intel Bluetooth wireless interface type: USB driver: btusb
Drives:
  Local Storage: total: 1.03 TiB used: 438.45 GiB (41.7%)
Info:
  Processes: 465 Uptime: 7d 21h 52m Memory: 31.13 GiB used: 13.62 GiB (43.8%)
  Shell: Bash inxi: 3.3.10


Nermander

Quote from: ScribusRibus on December 17, 2021, 05:38:11 PM
The EPS format was the only format that would export and render from the current document as required - but, I ultimately needed a PDF format, hence export current document to EPS, import the resulting EPS, then export that to PDF. Voila! a PDF! 8)

I guess you would be better off for example using ghostscript to convert the EPS (or postscript) to PDF, instead if importing it into Scribus.

As for why your PDF export does not work, there must be something wrong with your installation, because otherwise there would be hundreds of users reporting the same issue.

ScribusRibus

Quote from: Nermander on December 18, 2021, 11:48:17 AM
Quote from: ScribusRibus on December 17, 2021, 05:38:11 PM
The EPS format was the only format that would export and render from the current document as required - but, I ultimately needed a PDF format, hence export current document to EPS, import the resulting EPS, then export that to PDF. Voila! a PDF! 8)
I guess you would be better off for example using ghostscript to convert the EPS (or postscript) to PDF, instead if importing it into Scribus.

As for why your PDF export does not work, there must be something wrong with your installation, because otherwise there would be hundreds of users reporting the same issue.

Thanks for your response, I understand where you are coming from. The issue I have isn't that I'm doing something "wrong", or that I "shouldn't" do a certain something in a certain way, and should be doing it some other way.

QuoteThe issue is that Scribus in not functioning as expected with this particular file. :(

I guess I should provide a more succinct summary of the issue and pose my question more clearly so that we can focus on the issue and what the cause may be rather than a work around or a debate about the merits, or not, of any such workaround. The workaround I describe is not a solution, even though it provides me with what I need, it was done out of necessity because Scribus is not working as expected.

Okay, I will dive into more details so that it may help people assist in diagnosing the underlying issue, which to my mind is clearly something to do with the inner workings of Scribus...

The observation:

  • I have a very basic Scribus document that I CANNOT export to PDF - Scribus immediately crashes with SIG11, upon clicking OK, Scribus exits
  • I have also noticed some odd behaviour when applying paragraph styles to some of table cells of any of the repeating tables mentioned
  • I am either unable to edit the cell content, or the style just does not take, and I get some default font size that isn't a default
  • I also notice that the cursor gets stuck at the end of the line in the problem cells, if the cell is empty, the only way to enter text into the cell is to copy and paste into it
  • The same issue is observed on two different Linux installations, of two different distributions, and two different versions of Scribus (see initial post)

The document:

  • The document comprises of 5 pages, made with a few text boxes, and a few tables that are a repeat of 3 cells for the top line, with two cells below spanning the width of the 3 cells on the top line, repeated 15 times as separate objects
  • There are no images or other "fancy" things going on - no linking of text boxes, no LaTeX renders, or flowing of text around shapes etc

The troubleshooting so far:

  • Initially all objects were on one layer
  • I have since split them up over three layers, as per suggestion by toyotadesigner as an aid to troubleshooting and isolating the issue
  • I have then used the enable/disable toggle, for export/printing options per layer and per object/layer in a multitude of combinations
  • All of the above combinations result in Scribus crashing in exactly the same way, ie. immediately upon selecting "File | Export | Save as PDF..." with this single document

The things I can and have done:

  • I can print the document normally
  • I can print the document to file, which yields a .ps file
  • I can import the resultant .ps file into Scribus - which appears to render perfectly
  • I can then use that imported .ps file to export to PDF - no crash, and the resultant .pdf file appears to render perfectly
  • I can create a new document and print or export to all formats as expected - no crash, with reliable rendering (mostly for my needs at least)
  • I can open an existing document, someone else's document, and print or export to all formats as expected - no crash, with reliable rendering (mostly for my needs at least)

What I believe to be the issue:

  • I believe I have an edge case Scribus configuration combination that effects only this file - unlikely, but not entirely impossible
  • I am more inclined to believe that there is an internal file structure issue that Scribus is NOT dealing with, which triggers the crash upon attempting to export this particular document to PDF

The question:

  • How can I help?  8)

toyotadesigner

If you have access to another Linux installation and distro, you might check if Scribus will run without problems on that system.

You might check your current Linux installation for bugs.

You might re-install Linux, GhostScript and Scribus (This is what I would consider first).

You might search for the string »signal 11« in the Search function in this forum — there are several hits, and maybe they can point you into the right direction.

For friends, I have installed and configured Scribus on Ubuntu and Debian systems and never experienced any issues.

Other than that, I don't have any ideas.


ScribusRibus

Quote from: toyotadesigner on December 18, 2021, 02:17:01 PM
If you have access to another Linux installation and distro, you might check if Scribus will run without problems on that system.

You might check your current Linux installation for bugs.

I would be inclined to agree - except all other aspects of Scrubus, along with all other applications etc, work fine in both cases.

Quote
You might re-install Linux, GhostScript and Scribus (This is what I would consider first).

I would be inclined to agree, if I had any issues with Ghostscript or Scribus - except all other aspects of Ghostscript & Scribus work fine in both cases (remember the printing to .ps above, that was Scribus sending to Ghostscript. So successfully that the very same .ps file was used to import back into Scribus to enable me to save to PDF without crashing. So the options for where the fault exists are reducing fast...)

Quote
You might search for the string »signal 11« in the Search function in this forum — there are several hits, and maybe they can point you into the right direction.

I have done this, and I have not been able to find anything remotely like this issue so far.

Quote
For friends, I have installed and configured Scribus on Ubuntu and Debian systems and never experienced any issues.

Indeed, one system is Ubuntu based (Linux Mint), the other is Arch based (Manjaro) - neither are demonstrating issues with Scribus per se, except for this one file I have created with Scribus... the culprit here appears to be Scribus - whether anyone likes that or not is somewhat irrelevant and utterly unhelpful to boot.

Quote
Other than that, I don't have any ideas.

...and I wholeheartedly appreciate your feedback, but I am convinced it is a Scribus issue, more specifically, I believe it is a structure issue with the file itself, or how something about the file is NOT being handled properly by Scribus.

Narrowing down the cause of this issue is the challenge here, of which I am now a little closer!

I decided to make a copy (Save As...) of the original file - which still demonstrates the exact same behaviour, ie attempting to save to PDF causes Scribus to crash - and selectively delete content from it until I could successfully save to PDF.

Well now, when I deleted the content of the first text box, saved the file, then attempted to print to PDF - Scribus did NOT crash!

I then restored the content and went through it character by character (in Scribus) looking for oddities... there was one, where the font type changed at the end of the line.

I proceeded to remove all formatting and style from the text, but it made no difference. I even went through the process of deleting a character, saving the document, attempting to save as PDF, enduring the crash, restarting Scribus to delete another character, save, print, crash, repeat... until I no longer crashed when attempting to save to PDF.

This took a while, and I only succeeded to save to PDF when all text in the text box was removed.

The pre-flight check flagged 1 issue, and empty text box (surprise, surprise!) and I was able to save to PDF.

I then removed the text box, saved the file, and once again Scribus would crash instantly when attempting to save to PDF - as far as I can establish, this is definitely a Scribus issue, probably a file structure issue, or  an error handling issue - or both.

Putting the text box back - a new one - allowed me to get to the pre-flight check okay, but as soon as I hit "Ignore errors" Boom! Scribus crashes.

So whilst I wholeheartedly appreciate all the feedback and the suggestions from you guys, I am less concerned with the issue being with the installation of Linux and the supporting applications, including Scribus, and more so with the function (or lack thereof) of Scribus when attempting to save to PDF.

If someone can tell me specifically what I can do with the installation of two machines - that for all other purposes including Scribus work just fine - that will fix this issue, then the problem certainly resides with Scribus for the time being.

Perhaps there is a better place for me to highlight this issue where a developer might have deeper insight into how Scribus is possibly failing - or whether indeed I am failing somehow!

Thanks.

utnik

hi scribusribus

if you can reproduce the crash with another file, you should open a bug report. if it's just this single file, it's up to you. but that's the place where the developers might jump in...

utnik

ScribusRibus

Quote from: utnik on December 19, 2021, 03:47:09 PM
hi scribusribus

if you can reproduce the crash with another file, you should open a bug report. if it's just this single file, it's up to you. but that's the place where the developers might jump in...

utnik


Hi utnik,

I'm having trouble re-creating the problem, although I have no problem observing the behaviour with a minimal document.

It seems that it is a combination of a deleted character style, that is still applied to some of the text in a table cell (even though when I removed the style the option to apply "No Style" was offered and accepted), that has no borders (which was a case of Russian Roulette as to whether it worked or not), will cause Scribus to crash when exporting to PDF.

I have one table with one cell left of the original document as a working example of what causes the crash.

Also, there is a subtle additional issue that when the deleted, but still applied somewhere, character style is present in the document, when attempting to export to PDF and selecting the "Fonts" tab to "Embed all" or "Subset all" fonts in the PDF export dialog, this will also cause Scribus to crash with a SIG11. - Reproducing this is a level of Russian Roulette that is beyond me! :-/

Removing the borders from a table or cell seems to be very "hit and miss" or perhaps a "convoluted" and nuanced affair for me with Scribus v1.5.5 - the UI suggests the border has been removed, ie. no lines are selected in the "Properties" dialog and the line is apparently removed, yet when I preview, or move away from the table object, the settings do not stick. ???

Sometimes making the line width 0 and colour None does the trick - but that's not really removing the border line. :-/

It appears that when you select a table or enter a cell, all borders are active in the preferences dialog - regardless of what you had previously selected to be active - and sometimes they are how you left them, as desired. This is not always the case, I presume I must be missing something...

The only way to remove or change what you had previously selected to be active borders, need to be selected exactly as you had intended them to be - before you can amend the line width or colour, or even remove the desired border setting from the cell or table entirely. Additionally the table borders overlap with each other, which actually prevents being able to have cells with a full border of a specific colour that differs from it's neighbours.

I challenge someone to provide me with the steps needed to selectively produce a combination of borders to a table and/or cell, with varying colour and width and/or style that I can apply and get the same result as they did by following said steps. :-) lol

Just to be clear, I'm not bashing Scribus in any way, I just happen to find issues with things... be that either a bug, or a process for something.

Again, I wholeheartedly appreciate all of your suggestions/help - Scribus is a breath of fresh air when compared to MS Word, or even LibreOffice Writer when it comes to layout!  8)


Thanks

PS. I have attached two files demonstrating the issues I see. Hopefully nobody experiences the same issues, but if you do please report what version of Scribus you are using and I will gladly update.  8)

[attachment deleted by admin]

martonlente

Hello,

@ScribusRibus did you manage to resolve this issue? I've exactly the same problem with one particular file that I put a lot of work into.

If you didn't find a perfect solution, what did finally work for you?

Thanks for sharing your experience in advance!