Inkscape crashes on printing a file with text

Bug #1201902 reported by H. Bastian
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
High
jazzynico
Inkscape Devlibs
Fix Released
High
jazzynico

Bug Description

Tried to print an svg direkt from Inkscape. If it contains text, Inkscape crashes.
Error window comes up. Title is "Microsoft Visual C++ Runtime Library", The message box contains a symbol consisting of white X in a circle with a red background. Text is:
Assertion failed!

Programm: ...
File: cairo-scaled-font.c
Line: 2957

Expression: scaled_font-> cache_frozen
[Text goes on]
[3 buttons: ]Abbrechen, Wiederholen, Ignorieren [Yes, in german! Meaning is Cancel, Retry, Ignore]
[End of message box]

Ignore resultzs in printing an empty page.
Retry results in a crash.
Cancel results in an error pop-up of Inkscape, saying in german:
Inkscape ist auf einen internen Fehler gestoßen und wird nun geschlossen.
[Translation: Because of an internal error inkscape will be closed now.][Don't know why they say passiv, maybe indeed something else will close Inkscape.]

So it could be a bug in cairo, not inkscape itself. If I'm wrong here, please excuse me.

I'm using Windows 7 x64, German Language. Fails on all 3 printers here (Canon, FreePDF and FritzFax (kind of Fax over IP))
I get Inkscape via OSS-Marketplace. Reproduced crash on inkscape_r12395-201306291223 (newest build aviable via OSS-Marketplace at the moment). I tried some older builds:
r12340 crashes
r12248 does not crash.
r11515 does not crash.

Revision history for this message
H. Bastian (horst-bastian+launchpad) wrote :
su_v (suv-lp)
tags: added: win32
Revision history for this message
Alvin Penner (apenner) wrote :

not reproduced on Windows XP, HP Deskjet printer, Inkscape rev 12420, built from trunk

Revision history for this message
H. Bastian (horst-bastian+launchpad) wrote :

@Alvin Penner.
Is rev 12420 avaible for public? Then I could test it.

I've tested also Stabile Release 0.48.4, (rev 9939, as inkscape-0.48.4-1-win32.exe from inkscape.org). Did not crash.
Tested PDF and PS export, because it also uses cairo. It worked on all 5 testet revisions.

Tried running rev 12395 from DOS-Prompt (hind found here: https://bugs.launchpad.net/inkscape/+bug/613410/comments/5).
On Startup:
(inkscape.exe:1344): Pango-WARNING **: couldn't load font "???_HKSCS-ExtB 10", falling back to "Sans 10", expect ugly output.

(inkscape.exe:1344): Gdk-CRITICAL **: inner_clipboard_window_procedure: assertion `success' failed

First Message appeared on ~60 different Fonts (of 224 installed on my system). Took a look at these fonts an found, that they start at size 12, so - as the warning says - size 10 is not avaiable.

Tried to print now, Inkscape behaves like described as above (i. e. error window comes up), but no additional output to the DOS-prompt.

###
Nothing to this "bug":
Run Stabile Release 0.48.4, (rev 9939) from DOS-Prompt:

** (inkscape.exe:3024): WARNING **: Unimplemented style property SP_PROP_CLIP_RULE: value: nonzero

** (inkscape.exe:3024): WARNING **: Unimplemented style property SP_PROP_INTERPOLATION_FILTERS: value: lin

** (inkscape.exe:3024): WARNING **: Unimplemented style property SP_PROP_COLOR_INTERPOLATION: value: sRGB

[These 3 lines are repeated 6 times]

Revision history for this message
H. Bastian (horst-bastian+launchpad) wrote :

Took a look at %APPDATA%\Inkscape\extension-errors.log - nothing added here.
Reset my prference (hind found here: https://bugs.launchpad.net/inkscape/+bug/724221/comments/6), changed nothing.
Export to bitmap worked well.

Tried to uninstall fonts mentioned in the warning from above (#3), but some of them are system-fonts (says my windows), for example "Fixedsys" (not avaiable in size 10).

Found out, some other guy had this warnings to:
http://sourceforge.net/mailarchive/message.php?msg_id=30615892
Unfortunately he got no Solutuion or answer.

Revision history for this message
Alvin Penner (apenner) wrote :

>> Is rev 12420 avaible for public?
This rev was built from trunk, meaning I compiled it myself from scratch. Instructions at:
http://wiki.inkscape.org/wiki/index.php/CompilingInkscape

- on looking at the file example.svg I found the syntax a bit unusual, so I re-saved it on my computer. Could you try printing this new version? The text -inkscape-font-specification:Arial Bold has been changed compared to your version.

- with respect to the messages: (inkscape.exe:1344): Pango-WARNING **: couldn't load font "???_HKSCS-ExtB 10", falling back to "Sans 10", expect ugly output:
these messages should be ignored, they do not necessarily mean anything, and I would not attempt to uninstall any fonts based on them. See Bug 1186414.

similarly, ignore "WARNING **: Unimplemented style property SP_PROP_COLOR_INTERPOLATION: value: sRGB"

Revision history for this message
H. Bastian (horst-bastian+launchpad) wrote :

>> building from trunk
I'll try(!) this at the weekend.

>> example3.svg
Exactly the same result as before.

>> ignore the warnings
Okay. I just thought of a link because they are also about fonts.

A correction to my first post: Error window says
Expression: scaled_font-> cache_frozen
(I had misspelled cache)
Screenshot of error window with example3.svg and rev 12395: http://abload.de/img/errorwindow5jyu9.png

Tried to find out, what happens.
0) If I change Inkscapes language to english, the error window's buttons are still german, no changes in behaviour.
1) If I move the text out of the page so that it is not inside the printed area (=page), printing works fine, all other elements (added to the given minimal example for test) appear
2) Changing the Font type or its size does not change anything
3) Changing the color results as follows: only if it is pur white on background printing works fine, if it is colored on an object with the same color (black on a black rectangle), printing crashes like before. (That seems not very clear to me - white on background is sure invisible, colored on background needs to be rendered to decide if visible)

4) Changing the text from fillled with no outline to filled with outline does not change anything, but if I just set it to not filled but with outline, printing works fine.

Now something weird:
5) if I have only the text an change it's opacity to a value in the middle (50% for example), printing works, but result is wrong! (see http://abload.de/img/printingopaque1cvzde.png, left side is print preview of my Canon printer (PDF-printer and fax are the same), right inkscape)
If I change the alpha to a value in the middle (127 for example) and opaque to 100%, printing results in error again.
I'll try more at the weekend.

Revision history for this message
Pehaloc (web-4) wrote :

I got exactly the same error with any build higher than the 12274 (the last working for me). This is on both, a Windows 7 Notebook and a Windows 8 Desktop (german OS), at home. But unfortunatly, on my Windows 7 Pro Dektop at work also the newest build are ok.

The main difference with my home and work pcs was the installation of PDF Creator, a PDF printer service, so i uninstalled the program - without improvements.

Revision history for this message
Pehaloc (web-4) wrote :

Tested also with a Windows XP (german User Interface) Virtual Machine inside Oracles Virtual Box with the newest build from the OSS. It was a clean install, without any other programs - the error showed up.

Revision history for this message
Alvin Penner (apenner) wrote :

- confirmed on OSS downloaded file inkscape_r12427-201307211243.7z. The attached error message was obtained:
- not reproduced on Inkscape trunk build 12417.

It seems likely that this is related to the cairo library version. The file cairo-scaled-font.c is part of the source code for cairo-1.10.2, it is not part of the Inkscape trunk source code. Also there is a discrepancy between the file sizes of the cairo files in these two cases.

OSS build cairo files:

04/19/2013 01:02 PM 809,984 libcairo-2.dll
06/20/2012 02:21 PM 1,317,226 libcairomm-1.0-1.dll

build from trunk cairo files:

02/02/2013 10:11 AM 925,304 libcairo-2.dll
02/02/2013 10:05 AM 1,317,226 libcairomm-1.0-1.dll

The file libcairo-2.dll is different. Unfortunately, I do not know how to directly obtain the cairo version number by interrogating these files, I would be very interested to know how to do that.

Revision history for this message
Alvin Penner (apenner) wrote :

unfortunately, my devlibs was out-of-date, retracting previous comments:

- not reproduced on Inkscape rev 12417, devlibs rev 43
- reproduced on Inkscape rev 12417, devlibs rev 46, same error message as above.

it seems likely that this was introduced in devlibs rev 46, since that changed the file libcairo-2.dll

Changed in inkscape:
status: New → Confirmed
Revision history for this message
LucaDC (lucadc) wrote :

I'm still compiling trunk against rev 45 too, because of the tremendous slowdown with rev 46 and I haven't seen any problem till now.
Please try rev 45 because if it works it would be another reason to switch back to it.
By the way: what should be the advantage of rev 46? Up to now I've only experienced problems.

Revision history for this message
H. Bastian (horst-bastian+launchpad) wrote :

As mentioned in Comment #6 I tried to compile, but failed. (I'm normally "programming" just with Octave or Latex - so C/C++ and the workflow with it is a miracle for me, so my failure doesn't say anything about Inkscape!)

But many thanks to Alvin and Pehaloc for confirming this and explaning it a little bit. Don't know where (or find it again), but I remember that I have read about this cairo-version-is-different-in-devel thing somewhere else.

I don't know which version the/my libcairo-2.dll has, but is has a function called cairo_version. Maybe you could "ask" the dll?
For Windows there is a tool from Microsoft, which can list DLLs and their version, but libcairo-2.dll has no version-information. (http://technet.microsoft.com/en-us/sysinternals/bb896656)

To the bug itself I could add some odd behaviour.
As said in #6, playing with opacity and blur and alpha gives irritating results.
I wrote some white text and played with alpha and opacity and blur.
textcolor alpha opacity blur result
white 0 100 0 works
white 0 100 10 works, but wrong, black rectangle
white 0 50 0 works
white 0 50 10 works, but wrong, full black
white 0 0 0 works
white 0 0 10 works
white 255 100 0 error
white 255 100 10 works, but wrong, white blurred text in black rectangle
white 255 50 0 works, but wrong, white text in black rectangle
white 255 50 10 works, but wrong, full black
white 255 0 0 works
white 255 0 10 works
white 127 100 0 error
white 127 100 10 works, but wrong, greyish blurred text in black rectangle
white 127 50 0 works, but wrong, greyish unblurred text in full black page
white 127 50 10 works, but wrong, full black
white 127 0 0 works
white 127 0 10 works
Works means a blank white page as desired. Needless to say, that in all cases in Inkscape the page is pure white.

Revision history for this message
Alvin Penner (apenner) wrote :

fwiw, the crash appears to happen only if the text has a fill color assigned to it, no crash if you assign a stroke color with no fill

jazzynico (jazzynico)
tags: added: regression
Changed in inkscape-devlibs:
status: New → Triaged
importance: Undecided → High
assignee: nobody → JazzyNico (jazzynico)
Revision history for this message
H. Bastian (horst-bastian+launchpad) wrote :

@Alvin / #13
> only if the text has a fill color assigned to it, no crash if you assign a stroke color with no fill
Correct. (Textcolor in my table was fill, no stroke. )

jazzynico (jazzynico)
Changed in inkscape:
importance: Undecided → High
status: Confirmed → Triaged
description: updated
Revision history for this message
jazzynico (jazzynico) wrote :

Tested again with Cairo 1.12.14 (local build), but printing still fails (and Inkscape is still too slow, I'm afraid).

Revision history for this message
jazzynico (jazzynico) wrote :

> Tested again with Cairo 1.12.14
Correction: with Caito 1.12.16.

su_v (suv-lp)
Changed in inkscape:
milestone: none → 0.49
Revision history for this message
jazzynico (jazzynico) wrote :

Should be fixed with devlibs r47 (reverts Cairo to its devlibs r45 version).

Changed in inkscape-devlibs:
status: Triaged → Fix Released
Changed in inkscape:
assignee: nobody → JazzyNico (jazzynico)
milestone: 0.49 → none
status: Triaged → Fix Released
Revision history for this message
su_v (suv-lp) wrote :

Upstream bug report:
- 81709 – Win32 printer backend fails with scaled_font->cache_frozen assertion
  <https://bugs.freedesktop.org/show_bug.cgi?id=81709>

Is this upstream bug potentially another blocker for Inkscape 0.91?

Revision history for this message
jazzynico (jazzynico) wrote :

~suv> Is this upstream bug potentially another blocker for Inkscape 0.91?

Since the official devlibs still use 1.11.4, no.
But it could affect the unofficial 64 bits version (I didn't check the 64 bits devlibs).

Revision history for this message
su_v (suv-lp) wrote :

On 2014-08-02 11:52 , jazzynico wrote:
> Since the official devlibs still use 1.11.4, no.

But 0.91 will need a newer cairo version anyway - at least for anyone to whom bug #804162 matters (currently a release blocker).
See also related discussion on inkscape-devel about whether or not make next cairo release a requirement …
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/41830/focus=41831>

Revision history for this message
jazzynico (jazzynico) wrote :

~suv> But 0.91 will need a newer cairo version anyway

It would be great to update to a recent cairo version, but we still have performance issues with cairo-12+ and Intel graphic cards that could also be (an even worse?) release blocker (remember http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-td4966631.html).

And apparently using the old cairo lib is considered a valid workaround (see http://inkscape.13.x6.nabble.com/Status-of-Inkscape-0-91-Release-td4969769.html).

Revision history for this message
jazzynico (jazzynico) wrote :

Tested again with Cairo 1.14.6, Windows XP (32-bit) and Inkscape trunk rev. 14648, and printing now works as expected (according to the upstream report, it's fixed in Cairo 1.12.16).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.