no printing from Windows

Bug #179988 reported by Alvin Penner
66
Affects Status Importance Assigned to Milestone
GTK+
Fix Released
Critical
Inkscape
Fix Released
High
Rygle
0.46.x
Fix Released
Critical
Rygle
Old
Fix Released
High
Rygle

Bug Description

Running Windows XP, and Inkscape0712311750.7z
When I use File|Print, I get no printout, and no crash.
In DOS I get a one line message :
C:\Python25\APP>python inkcl.py
cairo_win32_surface_create: The handle is invalid.

P.S. this is a major improvement over Dec18 Windows build, which would crash on printout, and would not allow me to save anything as 'Plain SVG' or 'Compressed Plain SVG', both of these now work well, congratulations!

P.P.S. I believe the file \inkscape\share\extensions\svgz_output.inx is redundant.
It leads to a duplicate entry under File|Save As ...|Compressed Inkscape SVG (*.svgz)

[Changing title to not be build-specific, since the problem persists in later builds... -Tom Davidson]

nightrow (jb-benoit)
Changed in inkscape:
importance: Undecided → Medium
Revision history for this message
Peter Lewerin (vermeil-deactivatedaccount) wrote :

Confirmed on WinXP, Inkscape0801111659. Backtrace:

#0 0x63c90f28 in FcPatternObjectPosition ()
   from c:\Program\Inkscape\libfontconfig-1.dll
#1 0x63c90f81 in FcPatternObjectFindElt ()
   from c:\Program\Inkscape\libfontconfig-1.dll
#2 0x63c9142c in FcPatternObjectGet ()
   from c:\Program\Inkscape\libfontconfig-1.dll
#3 0x63c91626 in FcPatternObjectGetString ()
   from c:\Program\Inkscape\libfontconfig-1.dll
#4 0x68deb560 in _cairo_ft_unscaled_font_create_for_pattern ()
   from c:\Program\Inkscape\libcairo-2.dll
#5 0x68deef12 in cairo_ft_font_face_create_for_pattern ()
   from c:\Program\Inkscape\libcairo-2.dll
#6 0x006bfc5f in intl!bind_textdomain_codeset ()
#7 0xfffffe00 in ?? ()
#8 0x07ebdc68 in ?? ()
#9 0x003f0000 in ?? ()
#10 0x00000000 in ?? ()

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

Confirmed here too on Inkscape 0.45+devel+devel, built Jan 29 2008 under Windows XP. Only difference: Inkscape simply crashes after showing a message "Inkscape encountered an internal error and will close now."

This is independant of the printer.

Simon

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

Running Windows XP, Inkscape 0.46pre1-1win32.7z, Feb 1, 2008.

the error message is now somewhat enhanced :

C:\Python25\APP>python inkcl.py

(inkscape.exe:708): Gtk-CRITICAL **: gtk_file_system_win32_get_info: assertion `
g_path_is_absolute (filename)' failed

** (inkscape.exe:708): WARNING **: Family name Sans does not have an entry in th
e font lister.

** (inkscape.exe:708): WARNING **: Family name Sans does not have an entry in th
e font lister.
cairo_win32_surface_create: The handle is invalid.

Revision history for this message
Tom Davidson (tjd-mit) wrote :

The 'Family name Sans does not have an entry in the font lister error' may be a red herring: it's due to the default font in your preferences.xml file being specified as 'Sans', when you don't have a font by that name installed on your system. Can you confirm that at least that warning goes away when you edit preferences.xml? (replace Sans with 'Arial' or something... Preferences.xml should also be updated if you open a document, create some text using an installed font, then close Inkscape normally...

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

yes, indeed.
I modified the font-family to be Arial, and created some normal text and saved it, and now when I attempt to print, the only message I get is the following:

C:\Python25\APP>python inkcl.py

(inkscape.exe:180): Gtk-CRITICAL **: gtk_file_system_win32_get_info: assertion `
g_path_is_absolute (filename)' failed
cairo_win32_surface_create: The handle is invalid.

thanks for the help !

Tom Davidson (tjd-mit)
description: updated
Revision history for this message
Tom Davidson (tjd-mit) wrote :

Milestoning since seems to be a pretty big regression that has been confirmed by several users now... not sure who to assign to, though...

Changed in inkscape:
importance: Medium → High
milestone: none → 0.46
Revision history for this message
do1eh (rnh) wrote :

In 0.46pre I get no printout and no crash as decribed in the initial bug report
but if I render a "lorem ipsum"-Text or a barcode before printing Inkscape crashes.

Revision history for this message
do1eh (rnh) wrote :

I'm sorry please forget what I wrote before:

Inkscape 0.45.1+0.46pre1+devel, built Feb 1 2008 crashes everytime when I try to print a document that contains text.

(As lorem ipsum and barcodes both contain text I didn't realize that is wasn't the pythonscripts but actually the text)

That never happened in previous versions (0.45.1, built Mar 21 2007)

Revision history for this message
Bryce Harrington (bryce) wrote :

In order for this to remain milestoned, we must have an assignee for the bug, who will take ownership of getting it fixed.

We cannot block the release on platform-specific bugs that have no owner.

Revision history for this message
Duositex (duositex) wrote :

I'm not positive but I believe this also may prevent other applications from printing properly once an attempt is made from Inkscape. I will attempt to provide evidence of this if it seems further to be the case.

One comment:

"We cannot block the release on platform-specific bugs that have no owner."

While I understand this attitude, having a bug of this nature in the 0.46 release on a non-obscure platform seems ill-advised, especially given that if it's possible to print from a previous version without this problem. Losing such a basic (from the user's perspective) feature could potentially be very frustrating. As someone who uses Inkscape for professional work and regularly espouses its virtues, I hope that fixing a seemingly trivial feature like this is considered a top priority by whoever has the ability to remedy the matter.

Thanks!

Revision history for this message
micool (flightsim) wrote :

on win 2000, each attempt to print a file result to "Inkscape encountered an internal error and will close now"... so can't print from inkscape.
This bug, added to the Bug #178803, where the save as PDF via cairo can't be done without converting text to path is a real problem ( useless huge pdf files can be generated this way )

Revision history for this message
Duositex (duositex) wrote :

In Windows XP I *can* save PDF via cairo but the text in the resultant PDF is upside-down. The rest of the PDF turns out fine. It only crashed once when I attempted this. I was going to make mention of that in my previous comment but I assumed a bug report for that existed already and it seemed off-topic. Thanks!

Revision history for this message
David Bower (dave-koales) wrote :

I also confirm that it's not working for me on Windows XP with Inkscape-0.45.1+0.46pre1-1.win32.exe.

I created a fairly simple page (two straight lines, two boxes, grouped, and then cloned to create 16 tiles in all, i.e. a label template!). When printed, all I got was a solid black square 2.5cm x 3.2cm in the bottom right corner of the page, suggesting that the page has also been rotated 180 degrees, as previously suggested).

I've tried printing to a physical printer and also to PDF Creator (just in case). Same output in both cases.

Also, I would agree with Duositex, releasing with this bug would not do the project any favours...!

Revision history for this message
Bryce Harrington (bryce) wrote :

Obviously, it makes no sense to block a release indefinitely on an issue no one has committed to fix, else we would never release.

I will be dropping the milestone on this bug within a few days unless someone steps forward to take ownership of it. (I don't care if the owner lacks the technical skill to fix it, if they're at least willing to seek out and motivate someone who does to provide a patch.)

Keep in mind that the Windows version of Inkscape is actually just a port - one produced by the valiant efforts of a number of Windows users who wished to see it available on their platform. Our core focus has been Linux, and so for bugs that are specific just to Windows we are entirely dependent on Windows-based contributors to support it.

Note that even if you are not a technical person, there are still a LOT of open questions that a non-technical person could probably investigate. Does this issue affect all windows users, or only those using a specific printer driver? Or a specific windows version? Only one person has provided a backtrace; do others experiencing this issue also see the same backtrace, or something different? The backtrace provided looks like the user didn't install the debug symbols for Inkscape... if this is true, how does it look if these symbols are included? Most of the backtrace given seems to involve cairo and fontconfig - are the issues specific to fontconfig or cairo? If newer or older versions of each are used, would that resolve it? If so, then the fix could simply be a packaging issue, by including newer versions of these things.

Changed in inkscape:
milestone: 0.46 → none
Revision history for this message
Duositex (duositex) wrote :

It would seem to me that the popularity of Inkscape as a cross-platform tool somewhat hinges on the ability for the software to be used uncrippled on Windows. My uneducated guess would be that a 0.46 release with an asterisk next to the Windows download that says, "This software crashes when you attempt to print." would not benefit the project. I would imagine that some Windows users would gladly trade some of the newer, more obscure features for basic functionality. Is it possible to add a bounty to this bug to get it squashed?

I understand if you feel as though you've been put on the defensive, but tone of your response could be interpreted as that of someone who is apparently putting the burden of solving the problem on the people that were kind enough to identify it. Perhaps I was mistaken when I assumed that our work with this software is analogous to beta-testing commercial software, and that my role ends and you pick up when I report the problem and state, with much hope and optimism, "This is going to be a fantastic piece of software when it's released, I just hope this one nagging issue is resolved."

Revision history for this message
Okko7 (okko7) wrote :

I was actually looking forward to introduce Inkscape in our company as standard drawing programme. The ability to inmport would have made this possible, but of course, since my company is (unluckily) windows based, that would be impossible without printing.

Anyway, to answer Bryce's question: I've tried on two computers (both on Windows XP), three printers and two PDF conversion software (PDF Creator and XPPDF) and the same thing happend with all of them. So I don't think that this is linked to any printer driver. I'd be glad to provide, but I don't have an idea how to do this.

Simon

Revision history for this message
Kees Cook (kees) wrote :

Without digging into it on Windows (I don't have any Windows machines), this sounds like a problem somewhere between Cairo and the GTK Printing subsystem. I slightly suspect this bug report contains 2 separate issues:
- no-crash no-print
- crash-on-print

The first backtrace shows a crash in fontconfig via cairo. The "no crash no print" issue is likely what is reporting the "cairo_win32_surface_create: The handle is invalid." error. In this case, it seems like the win32 Cairo backend is unable to do something that GTK Printing API is asking it to do -- something that DOES work under Linux.

Revision history for this message
Tom Davidson (tjd-mit) wrote :

I was wondering whether the difference between windows and linux behavior could be due to different cairo versions being used (Windows packages 1.5.8), so I upgraded my Fedora 8 system to the 1.5.8 release ( using the F9 packages at http://koji.fedoraproject.org/koji/buildinfo?buildID=33604 ). I can still print and save to PDF. So just confirming that this appears to be a windows-only problem...

Revision history for this message
ishmal (ishmalius) wrote :

Just FYI, I was digging around, and found the "handle is invalid" message source. cairo-win32_surface.c: 1719:

    if (_cairo_win32_save_initial_clip (hdc, surface) != CAIRO_STATUS_SUCCESS) {
 free (surface);

...and in _cairo_win32_save_initial_clip():

    gm = GetGraphicsMode (hdc);
    if (gm == GM_ADVANCED) {
 GetWorldTransform (hdc, &saved_xform);
 ModifyWorldTransform (hdc, NULL, MWT_IDENTITY);
    }

    clipBoxType = GetClipBox (hdc, &rect);
    if (clipBoxType == ERROR) {
 _cairo_win32_print_gdi_error ("cairo_win32_surface_create");
 SetGraphicsMode (hdc, gm);
 /* XXX: Can we make a more reasonable guess at the error cause here? */
 return _cairo_error (CAIRO_STATUS_NO_MEMORY);
    }

It's failing GetClipBox(). 'hdc' is the handle in question. They should also check 'gm' for ERROR. I bet
it's the same error.

Revision history for this message
ishmal (ishmalius) wrote :

Tracing the problem a bit further: cairo_win32_surface_create() is being called with a null HDC for print. The normal calls to that function are receiving valid HDCs.

Revision history for this message
Bryce Harrington (bryce) wrote :

Duositex, your assumption is correct - with non-commercial open source software like Inkscape, which is driven mainly(*) through volunteer efforts, there isn't that firm distinction of roles between users and developers - really there are just contributors and non-contributors. I blogged about this more at http://bryceharrington.org/drupal/foss-win-paradox.

What you're reading from my comment is not defensiveness (not intentionally anyway!) but literally that yes, the burden of supporting Windows needs to lay within the Windows community. Not necessarily the person who reported the issue, but maybe someone who otherwise would assume fixing it was "someone else's problem". Ideally, a Windows person with development experience would look into this and sort it out, but lacking such a person, even a non-developer can assist in making progress with the bug as I mentioned in my previous comment.

Anyway, I asked Kees to outline his thoughts on what needs to be done technically. I think this may just be a packaging issue, that can be sorted out within the Windows build, outside the core. But someone on Windows needs to do the leg work of figuring this all out.

Revision history for this message
Aaron C Spike (acspike) wrote :

FYI, I recently had some difficulties with pycairo on win32. I built pycairo against our libs bundle (cairo 1.4 at the time iirc) as an easy out (all of the deps were collected there in one place for me). Things worked fine until I tried to use text. Every attempt to use text caused a crash. Recently I found an updated binary of cairo and pycairo 1.4 on the gtk site and with these versions I do not experience a crash. I would postulate from my experience that this crash if it is caused by text is not related to the version of cairo, but rather the build. I wonder if perhaps this is caused by some bad linking against or between the font librarys that cairo uses. (Those font libs always confuse me. seems like there are a number of cross deps that would be difficult to get right.)

Revision history for this message
Duositex (duositex) wrote : Re: [Bug 179988] Re: no printing from Windows

I thank everyone for their quick efforts to solve this problem and to
Bryce for doing a good job fielding my questions and giving good
responses. Sincerely appreciated.

On Thu, Feb 21, 2008 at 8:43 PM, Aaron Spike <email address hidden> wrote:
> FYI, I recently had some difficulties with pycairo on win32. I built
> pycairo against our libs bundle (cairo 1.4 at the time iirc) as an easy
> out (all of the deps were collected there in one place for me). Things
> worked fine until I tried to use text. Every attempt to use text caused
> a crash. Recently I found an updated binary of cairo and pycairo 1.4 on
> the gtk site and with these versions I do not experience a crash. I
> would postulate from my experience that this crash if it is caused by
> text is not related to the version of cairo, but rather the build. I
> wonder if perhaps this is caused by some bad linking against or between
> the font librarys that cairo uses. (Those font libs always confuse me.
> seems like there are a number of cross deps that would be difficult to
> get right.)
>
>
>
> --
> no printing from Windows
> https://bugs.launchpad.net/bugs/179988
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Inkscape: A Vector Drawing Tool: Confirmed
>
> Bug description:
> Running Windows XP, and Inkscape0712311750.7z
> When I use File|Print, I get no printout, and no crash.
> In DOS I get a one line message :
> C:\Python25\APP>python inkcl.py
> cairo_win32_surface_create: The handle is invalid.
>
> P.S. this is a major improvement over Dec18 Windows build, which would crash on printout, and would not allow me to save anything as 'Plain SVG' or 'Compressed Plain SVG', both of these now work well, congratulations!
>
> P.P.S. I believe the file \inkscape\share\extensions\svgz_output.inx is redundant.
> It leads to a duplicate entry under File|Save As ...|Compressed Inkscape SVG (*.svgz)
>
> [Changing title to not be build-specific, since the problem persists in later builds... -Tom Davidson]
>

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

> Tracing the problem a bit further: cairo_win32_surface_create() is being called

I don't recommend using cairo_win32_surface_create() for printing. Use the cairo_win32_printing_surface() in cairo 1.5.x instead.

cairo_win32_surface_create() is designed for displays. It requires the DC to support a destination bitmap that can be read. This is used to implement functionality that GDI does not support such as antialiasing and transparency. The problem is most printers don't support a destination bitmap so just about anything except text, images, and rectangles with integer coordinates is not going to print correctly. Even when the printer driver does support a destination bitmap we end spooling 100MB per page of raster data.

cairo_win32_printing_surface_create() works the same way the PostScript surface works. It uses the GDI API as much as possible since we don't need antialising at printer resolutions. For unsupported operations such as transparency, fallback images are used.

Revision history for this message
ishmal (ishmalius) wrote :

@Adrian:

I agree. I saw that file yesterday and asked about it. But cairo_win32_surface_create() is called by gtkprintoperations-win32.c or whatever the name is, not Inkscape. Also, cworth told me that cairo_win32_printing_surface_create() is a Cairo 1.5+ API thing, so I think that the decision would be up to the Gtk/Win32 guys (Tor?) whether to require Cairo 1.5+ on Win32 to use GtkPrint. Maybe a call to search for the symbol name in the binary, and dynamically call it? (I doubt that anyone would ever do that ^^).

Revision history for this message
ishmal (ishmalius) wrote :

Well, after searching through Gtk code last night, with help from Mental, it LOOKS like Win32 API's PrintDlgExW() is returning ok, but that printdlgex->hDC is not being set. Thus the null argument to cairo_win32_surface_create(). I may be wrong, but that's what it looks like. I suspected that maybe MinGW's PRINTDLGEXW struct definition might not match that of the native Win2003 SDK, but it looks OK, too. Adrian, you're right, a call that doesn't require an HDC would be great. :)

Here is the gtk source:
http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtkprintoperation-win32.c?annotate=18860

Look at lines 1544 and 1603.

Anyway, we're strategically no closer to fixing the bug, but have made tactical advances. But it looks like the problem is definitely upstream in Gtk territory or MinGW or something like that. Maybe it's not the source, but just a particular build?

Revision history for this message
Bryce Harrington (bryce) wrote :

ishmal, thanks for investigating this. Since it sounds like an issue in the dependencies, I take it this is something that can be worked out at the packaging level, so there's no reason for us to block the core inkscape release on it. A true fix will require involvement from upstream (does anyone have an upstream bug report url we could link this to?)

Perhaps for the 0.46 release, the windows build could ship with printing disabled - when the user clicks print, display a message explaining the issue and indicating they can print to pdf to print, or whatever is considered the best workaround, and when working upstream libs become available, a new windows package can be released with that.

Revision history for this message
ishmal (ishmalius) wrote :

More info. gtk-demo.exe in the /devlibs dir -does- print, tho messy. This is with the same libs as inkscape.exe. Curious.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :
Changed in gtk:
status: Unknown → New
Revision history for this message
Duositex (duositex) wrote :

I would be happy with this as long as text in PDF's is no longer
upside down on printing. Is this fixed? Thanks guys!

--Chris

On Fri, Feb 22, 2008 at 2:33 PM, Bryce Harrington
<email address hidden> wrote:
> ishmal, thanks for investigating this. Since it sounds like an issue in
> the dependencies, I take it this is something that can be worked out at
> the packaging level, so there's no reason for us to block the core
> inkscape release on it. A true fix will require involvement from
> upstream (does anyone have an upstream bug report url we could link this
> to?)
>
> Perhaps for the 0.46 release, the windows build could ship with printing
> disabled - when the user clicks print, display a message explaining the
> issue and indicating they can print to pdf to print, or whatever is
> considered the best workaround, and when working upstream libs become
> available, a new windows package can be released with that.
>
>
>
> --
> no printing from Windows
> https://bugs.launchpad.net/bugs/179988
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Inkscape: A Vector Drawing Tool: Confirmed
>
> Bug description:
> Running Windows XP, and Inkscape0712311750.7z
> When I use File|Print, I get no printout, and no crash.
> In DOS I get a one line message :
> C:\Python25\APP>python inkcl.py
> cairo_win32_surface_create: The handle is invalid.
>
> P.S. this is a major improvement over Dec18 Windows build, which would crash on printout, and would not allow me to save anything as 'Plain SVG' or 'Compressed Plain SVG', both of these now work well, congratulations!
>
> P.P.S. I believe the file \inkscape\share\extensions\svgz_output.inx is redundant.
> It leads to a duplicate entry under File|Save As ...|Compressed Inkscape SVG (*.svgz)
>
> [Changing title to not be build-specific, since the problem persists in later builds... -Tom Davidson]
>

Revision history for this message
jhoechtl (johann-hoechtl) wrote :

This is Inkscape 0.45+0.46pre2+devel, built Feb 21 2008 on Windows

I can only confirm the aforementioned bug when printing on Windows PLUS:

Export to ps (using cario or builit-in) or to pdf is not working. svg or svgz works though.

Given this behaviour and the unwillingness to postpone the release to fix this severe issue
I would vote to remove Windows from the list of supported plattforms: Without this 'feature'
(print, huhu, cool) you can not call it supported.

Revision history for this message
Duositex (duositex) wrote :

I would second this motion. Export to PDF now crashes on 0.45+0.46pre2 here as well (as downloaded from inkscape.org) and printing does nothing here. It's a shame but I would suggest that Windows be removed from the supported platforms list as well.

Revision history for this message
Okko7 (okko7) wrote :

I can very well understand that it is hard to find a solution for this bug as long as there are too few windows developers. Unluckily I have no idea of programming, so I wont be able to help any on this.

I have however some knowledge on marketing. From this point of view, I'd say that it might be best to just call the windows release delayed in the hope that a solution might be found later.

I think that this would be better than the other solutions mentioned, for example calling Windows not supported, releasing it with printing disabled or releasing it just as is.

In any case, I'd recommend to be honnest on this point and not try to hide it. If the windows user learn about the new version, then download it and start using it, just to discover that printing doesn't work, that will give a much worse image than if it's clear from the beginning on that the new Windows version is delayed.

Simon

PS: There was the idea of a bounty on this bug. I'd be willing to contribute. How much time/money would be needed to pay someone to find a solution for this bug? And would there be anyone willing to work in it?

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

running win32 nightly build Inkscape0802291457.7z
still no printing and no crash, however, the message has changed, the new message is

C:\Python25\APP>python inkcl.py
_cairo_win32_save_initial_clip: GetGraphicsMode: The handle is invalid.

Never tried this before, but the procedure Save As PDF via Cairo works well, produced a readable pdf file.

However, on exit I got the following DOS messages

C:\Python25\APP>python inkcl.py
576.000000 576.000000

** (inkscape.exe:3592): WARNING **: Parameter <blurToBitmap> might not exists

** (inkscape.exe:3592): WARNING **: Parameter <blurToBitmap> might not exists

(inkscape.exe:3592): Gtk-CRITICAL **: gtk_widget_grab_default: assertion `GTK_WI
DGET_CAN_DEFAULT (widget)' failed

Revision history for this message
bbyak (buliabyak) wrote :

Sorry for an uninformed suggestion, but when did this problem appear? Maybe we can find and revert the change that triggered it? I always thought it was something with Kees' print redesign.

Bryce: I agree with those who say we must NOT release with this bug. No matter if someone is named as a blameperson for this or not, it's just not acceptable. If we can't fix it, we must, yes, simply wait until someone comes along. Meanwhile it'd make more sense to make some noise about this bug, e.g. on the devel list. With 400+ subscribers it has a lot of people to appeal to, especially if we honestly admit that this is holding back the release.

Revision history for this message
Rygle (rygle) wrote :

I think that, regardless of your position on Windows as an operating system, or Windows users, that putting out a release that is crippled would be downright humiliating to the *whole* Inkscape project.

Let's ask, what is pushing us so hard to get the next release out? In a lot of these projects there is an impetus based on saving face, which is about bringing new features to fruition. IMHO, the saving face needs to be done by being a little patient, or at the very least not releasing 0.46 for Windows until it is pretty right.

Again, what is the aim? Is it purely to further the name of Inkscape, or is there at least some desire to further SVG as a viable option is a largely proprietary world? I have heard that said a number of times, and used as a reason to include or reject features. This project is meant to be about a good SVG editor, and the rest is a nice by-product. Again, a good reason to hold off just a little.

Let us also ask, if Linux users are so technically superior, aren't they already using the release candidate, which offers pretty much what the release will? Surely even the nightlies are very stable by now if all the bugs are ironed out. If so, in at least one sense who cares if there's a release if the RC is working and those who want the release are already using it! Linux users are well and truly used to beta and release candidates, and in fact the pure only use the bleeding edge stuff and look down on those who don't. Or are we next going to start railing against Ubuntu users for their lack of technical expertise, and because they need a packaged version? Afterall, isn't Ubuntu trying to attract that Windows-like person?

Lets please hold off just a little, at the very least on the Windows release. For many Linux users it makes no difference whether or not there's an official release, because the pre2 package is stable. For the Windows users, and the reputation of Inkscape, SVG, and even FOSS, it makes a huge difference.

Revision history for this message
Bryce Harrington (bryce) wrote :

Kees simply implemented the common gnome print dialog that uses standard cairo interfaces for printing, in a cross-architecture fashion. Adrian and Ishmal point to upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=488833 as the cause of this problem. That bug says the fix will be released in cairo 1.6. Presumably, once that library is available, inkscape simply needs to be rebuilt against it and in theory the issue will be solved. A patch to cairo is posted there, with requests for testing, and I'd encourage those with windows platforms to test on, to build a patched cairo with this patch included and test to see if your print issue is resolved.

Bulia, your alternative suggestion for reverting the new print dialog back to the old one, would also be acceptable to me, if you code it to only take effect on Windows (i.e., either using ifdefs or an option). In browsing the svn log, it looks like kees introduced these changes in r16655, r16860, r16865, r16866. Please send me this patch by Tuesday if you could?

I am also open to the proposal by Rygle, Mental, and others that a Windows version of Inkscape not be advertised if this bug cannot be resolved prior to the release. This should be the last fallback if neither of the prior two options work out in time. This would enable us to release in time to be included in the next round of LInux distros (Ubuntu Hardy entered feature freeze Feb14, and goes to Beta Freeze March 13th; Fedora 9 foes into feature freeze March 4th, and beta release March 13th with Final Development freeze April 8). Otherwise, it'll be another 6 months before we have the opportunity to get Inkscape out to Linux users officially.

Revision history for this message
Bryce Harrington (bryce) wrote :

<bryce> cworth: if you're around, can I ask what your timeframe is for cairo 1.6? It's looking like one of our remaining critical bugs is contingent on a cairo 1.6 change.

<cworth> bryce: weeks not months for 1.6 certainly

 bryce: And it *might* be days not weeks, but I can't promise that yet.

<bryce> cworth: ok thanks

Revision history for this message
Okko7 (okko7) wrote :

Anyone has some more detailed information on how to test the mentioned? I'd be glad to test, but I'm enough computer savvy to know how to test it without additional instructions.

Simon

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi Simon,

Essentially, you need to get the cairo SVN code, take this patch: http://bugzilla.gnome.org/attachment.cgi?id=99752&action=view, apply the patch to cairo, and build it. Then, rebuild Inkscape using this library. Then fire up Inkscape and see if it prints.

There are some more detailed directions about building Inkscape for Windows at http://wiki.inkscape.org/wiki/index.php/Win32Port. I haven't ever built Inkscape on Windows, so don't know how up to date that page is, but perhaps it will give clues. Ishmal is the best person to ask for advice if you run into trouble. You might find it helpful to try catching him on IRC/Jabber.

Simon, thanks greatly for offering to test this. I know it can be a bit of a challenge, but this is something that could greatly help out the project.

Bryce Harrington (bryce)
Changed in inkscape:
milestone: none → 0.46
Rygle (rygle)
Changed in inkscape:
assignee: nobody → pittos
status: Confirmed → In Progress
Rygle (rygle)
Changed in inkscape:
status: In Progress → Fix Released
Rygle (rygle)
Changed in inkscape:
status: Fix Released → In Progress
Rygle (rygle)
Changed in inkscape:
status: In Progress → Fix Released
100 comments hidden view all 180 comments
Revision history for this message
Bryce Harrington (bryce) wrote :

The patch causes this build error on Linux:

 g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/freetype2 -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -DPOTRACE=\"potrace\" -pthread -I/usr/local/include -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I../cxxtest -Wall -Wformat-security -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -D_FORTIFY_SOURCE=2 -Wno-unused-parameter -g -O2 -MT extension/internal/cairo-render-context.o -MD -MP -MF $depbase.Tpo -c -o extension/internal/cairo-render-context.o extension/internal/cairo-render-context.cpp &&\
 mv -f $depbase.Tpo $depbase.Po
extension/internal/cairo-render-context.cpp:53:44: error: FontFactory.h: No such file or directory
make[2]: *** [extension/internal/cairo-render-context.o] Error 1
make[2]: Leaving directory `/home/bryce/src/Inkscape/inkscape-0.46-branch/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bryce/src/Inkscape/inkscape-0.46-branch'
make: *** [all] Error 2

Revision history for this message
Rygle (rygle) wrote :

Bryce: Thanks for your help. When is the deadline on all this 0.46.0 stuff?

The fontfactory.h thing is a windows only dependency related to pango (it's in src\libnrtype), and I think it needs an #ifdef win32. Does this seem correct?

+#ifdef WIN32
+#include "FontFactory.h" // USE_PANGO_WIN32
+#endif

I think it's possible that more #ifdef WIN32 ... #endif statements are needed in the patch. I'm checking, but I'm no programmer.

Revision history for this message
Rygle (rygle) wrote :

That last bit is in src\extensions\internal\cairo-render-context.cpp

There are only a few other bits in the current patch that don't seem to have ifdefs and may affect other platforms

The first four added lines here;
==========
@@ -1421,16 +1426,33 @@
 {
     // create a cairo_font_face from PangoFont
     double size = style->font_size.computed;
+ cairo_font_face_t *font_face = NULL;
+
+ FcPattern *fc_pattern = NULL;
+
+#ifdef USE_PANGO_WIN32
==========

This just seems to be an improvement of code for everyone;
========
- if (FcPatternGetDouble(fc_pattern, FC_PIXEL_SIZE, 0, &size) != FcResultMatch)
+ if (fc_pattern && FcPatternGetDouble(fc_pattern, FC_PIXEL_SIZE, 0, &size) != FcResultMatch)
========

And so does this;
========
     cairo_restore(_cr);

- cairo_font_face_destroy(font_face);
-#else
- (void)size;
- (void)fc_pattern;
+ if (font_face)
+ cairo_font_face_destroy(font_face);

- cairo_restore(_cr);
-#endif
-
========

So I think just one #ifdef WIN32 ... #endif needed for the #include "Fontfactory.h"

Will test now on Windows.

Rygle

Revision history for this message
Rygle (rygle) wrote :

For ui\dialog\print.cpp, I'm wondering about #ifdefs for the following

Should the ifdef be earlier here? Before the //ctx->setPSLevel? Or before the cairo_t?

============
- bool ret = ctx->setSurfaceTarget (cairo_get_target (gtk_print_context_get_cairo_context (context)), true);
- if (ret) {
+
+ // ctx->setPSLevel(CAIRO_PS_LEVEL_3);
+ ctx->setTextToPath(false);
+ ctx->setFilterToBitmap(true);
+ ctx->setBitmapResolution(72);
+
+ cairo_t *cr = gtk_print_context_get_cairo_context (context);
+ cairo_surface_t *surface = cairo_get_target(cr);
+#ifdef WIN32
+ if (cairo_surface_get_type (surface) == CAIRO_SURFACE_TYPE_WIN32) {
+ HDC dc = cairo_win32_surface_get_dc (surface);
+ surface = _cairo_win32_printing_surface_create (dc);
+ }
+#endif
+
+ bool ret = ctx->setSurfaceTarget (surface, true); if (ret) {
==========

And should there be an ifdef on this, since Linux are not having the issue with scaling?
========
+ gtk_print_operation_set_unit (_printop, GTK_UNIT_POINTS);
========

Revision history for this message
Rygle (rygle) wrote :

Can someone try this patch on Linux (Bryce??). It just has the added #ifdef WIN32 ... #endif in src/extension/internal/cairo-render-context.cpp, so hopefully it should now build on Linux.

Cheers, Rygle

Revision history for this message
Rygle (rygle) wrote :

Adrian: What do you think we should do about fallback?

Here's some comparisons for the spool files for the above creation scene file - https://bugs.launchpad.net/inkscape/+bug/179988/comments/113

HP LJ 4550 Colour PS3 (Can't set dpi, but max is 600);
0.45.1 - 114Mb and great
0.46 branch - unpatched fallback - 424Kb and very pixelated
0.46 branch - x_dpi, y_dpi fallback - 1.55Mb and moderate pixelation

Lexmark Optra T616 Greyscale PS3 (dpi set to 1200);
0.45.1 - 24Mb and great
0.46 branch - unpatched fallback - 41Kb and very pixelated
0.46 branch - x_dpi, y_dpi fallback - 244Kb and moderate pixelation

0.45.1 was always slow on printing because of the large spool files. This seems to have vastly improved things as far as spool size, and probably memory usage.
I think there must be something affecting the dpi in the cairo context setup, which thus affects the x_dpi and y_dpi fed to fallback. Hopefully we can fix this for 0.46.1.

Rygle.

Revision history for this message
Rygle (rygle) wrote :

Just did a build with the fallback set at 300dpi and it prints almost exactly the same as leaving the fallback unpatched. 40.4Kb and very pixelated

Printed it out and on the giraffe I can literally count how many pixels are in an inch (well 2.54cm) because it has a constantly changing colour that makes successive pixels different colours. It's printing at about 18 or 19 dpi. It's like playing a game on a commodore 64 emulator.

This leads me to think the default fallback is still 300dpi, as there is no difference between unpatched fallback and patched with hard 300dpi, but there's something else going wrong. Could it be the scale command that scaled this up from the tiny print that we were getting before?

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

Rygle wrote:
> Just did a build with the fallback set at 300dpi and it prints almost
> exactly the same as leaving the fallback unpatched. 40.4Kb and very
> pixelated
>
> Printed it out and on the giraffe I can literally count how many pixels
> are in an inch (well 2.54cm) because it has a constantly changing colour
> that makes successive pixels different colours. It's printing at about
> 18 or 19 dpi. It's like playing a game on a commodore 64 emulator.
>
> This leads me to think the default fallback is still 300dpi, as there is
> no difference between unpatched fallback and patched with hard 300dpi,
> but there's something else going wrong. Could it be the scale command
> that scaled this up from the tiny print that we were getting before?
>
>
I've found the bug in cairo that is causing this. The problem is we are
scaling the Windows DC from
the default 1 unit = 1 printer pixel to 1 unit = 1/72" with this code

+ SetGraphicsMode (hdc, GM_ADVANCED);
+ xform.eM11 = x_dpi/72.0;
+ xform.eM12 = 0;
+ xform.eM21 = 0;
+ xform.eM22 = y_dpi/72.0;
+ xform.eDx = -x_off;
+ xform.eDy = -y_off;
+ SetWorldTransform (hdc, &xform);

However this is causing a cairo to reduce the resolution of the fallback
images by a factor of dpi/72.
I'll have a look at what it will take to fix the problem in cairo. There
are couple of workarounds that
Inkscape can use. One workaround is to remove the above code and instead
scale the cairo content;

eg
cr = cairo_create (surface);
cairo_scale (cr, x_dpi/72.0, y_dpi/72.0);

The other, and likely the simpler, workaround is to scale up the
fallback resolution by dpi/72.

eg
  surface = cairo_win32_printing_surface_create (hdc);
  cairo_surface_set_fallback_resolution (surface, (x_dpi/72.0) * x_dpi,
(y_dpi/72.0) * y_dpi);

or to use a fixed 300 dpi:
  surface = cairo_win32_printing_surface_create (hdc);
  cairo_surface_set_fallback_resolution (surface, (x_dpi/72.0) * 300,
(y_dpi/72.0) * 300);

Revision history for this message
Rygle (rygle) wrote :

This is great Adrian.

I did do a bitmap export of the file at 200dpi and I was very happy with the resolution on that, which is partly why this has been bugging me.

As soon as I can I will do a build with the fixed 300, since that is ultimately what you thought was a reasonable max. Just in the middle of another build to test my master patch for SVN bugs 1-5. Man, I wish my PC could do 2 builds at once.

Revision history for this message
Rygle (rygle) wrote :

I've also found another printing bug with masks.

In the creation scene (see https://bugs.launchpad.net/inkscape/+bug/179988/comments/113), there's a turtle sitting in the water, and his feet fade into the water using a mask with a gradient going from a black bottom to a white top.He prints fine in 0.45.1, but in 0.46 branch he's gone.

Exporting to bitmap works fine on 0.46. Printing to bitmap (Render as bitmap) works fine also on 0.46. Save as PDF keeps the turtle but loses all blurs (not implemented) and the mask, so his legs are fully visible. I think PDF should be capable of a blend to transparent, because the leaves on the bushes blend to transparent and they export to pdf beautifully.

I'm also puzzled why printing to bitmap produces a 117Mb file @ 90dpi, while exporting to bitmap produces an almost identical quality picture that's 495Kb at 90dpi. The export is a png, but that's a heck of a difference. Is it that export is using the imagemagick dll or similar, while print to bitmap is using cairo?

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

The fallback resolution fix for cairo has been committed:

http://gitweb.freedesktop.org/?p=cairo;a=commit;h=e9906ae2021904c8c3d3a4083786475c102196f7

Obviously we want to ensure that Inkscape does not implement the fallback resolution workaround I suggested at the same time as using a libcairo.dll with this fix or else we will get a fallback resolution much higher then it should be.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

As far as I know masks are correctly implemented by cairo in the PDF backend.

Based on comment 61 there are two different cairo renderers for PS and PDF.

$ grep cairo_mask *
cairo-render-context.cpp: cairo_mask_surface(_cr, clip_mask, 0, 0);
cairo-render-context.cpp: cairo_mask_surface(mask_ctx->_cr, clip_mask, 0, 0);
cairo-render-context.cpp: cairo_mask_surface(_cr, mask_image, 0, 0);

Only one of them is using cairo_mask().

I'm not sure why the print file is 117MB. A 11x8" page at 90dpi is
90*11*90*8*3 = about 2MB. The PNG file would be compressed.

117MB is about 8 times larger (or 600/72) which suggests there is a scaling problem somewhere due to difference between the printer resolution and 72dpi.
I can't think of anything in cairo that would cause this other than printing a transparent image on top of something else which would force cairo to use a fallback image.
Someone may need to check that the Inkscape code is working correctly.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

Adrian Johnson wrote:
> I'm not sure why the print file is 117MB. A 11x8" page at 90dpi is
> 90*11*90*8*3 = about 2MB. The PNG file would be compressed.
>
> 117MB is about 8 times larger (or 600/72)

I didn't explain that very well. If the horizontal and vertical
resolution is increased by 8 the image size increases by 8*8.

Revision history for this message
Rygle (rygle) wrote :

Thanks for all your great work. It's great that this is helping Cairo and all its other beneficiaries too.

I will check out the mask thing a bit more and see what happens.

I'm wondering whether the file sizes might be to do with ascii vs binary. Looking at the contents of the spool file, it sure looks like ascii to me. Lots of repetition of phrases (not human readable but still phrases).

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

Rygle wrote:
> I'm wondering whether the file sizes might be to do with ascii vs
> binary. Looking at the contents of the spool file, it sure looks like
> ascii to me. Lots of repetition of phrases (not human readable but still
> phrases).

The binary image is encoded in an ASCII encoding that will increase the
size by either 1.25 or 2 times depending on the encoding used. Certainly
not enough to explain the file size difference.

Does the image look like it is 90dpi or something higher?

Revision history for this message
Rygle (rygle) wrote :

Both exported @ 90dpi and printed @ 90dpi look about the same. It's just the size that's different.

At first I thought the printed was less clear, but then I realised that GSview uses graphics alpha/antialiasing and that was affecting things a bit.

Doing that build now. About 20 minutes left.

Revision history for this message
Rygle (rygle) wrote :

Excellent! Much, much better! This has taken a weight off my mind.

Hard coded as follows;
cairo_surface_set_fallback_resolution (surface, (x_dpi/72.0) * 300, (y_dpi/72.0) * 300);

Spool for HP Colour PS3 is 26Mb and looks good
Spool for Apple Colour PS2 is 25.5Mb and looks good
Spool for Lexmark Grayscale PS3 is 2.24Mb and looks good - on paper this looks equivalent to 0.45. In fact the contrast is better in 0.46 and there is a slight banding in the 0.45 gradients that isn't there in 0.46

So now, I will resubmit the patch with the fallback bit commented out (with some explanatory stuff), and we will have to talk to Ishmal about cairo again, and hope it makes it in, or at least co-ordinate the fix against the cairo build.

Just need to sort two more things and I'll be really happy;
* Blur scaling and alignment
* Masks

Revision history for this message
Rygle (rygle) wrote :

Is there some conditional thing we can use to test whether cairo has this fix? That would be cleaner in some ways and messier in others I guess.

Could do something like;
=====
#ifndef have_cairo_1.6 // (or whatever the correct call is)
cairo_surface_set_fallback_resolution (surface, (x_dpi/72.0) * 300, (y_dpi/72.0) * 300);
#endif
=====

But then I guess that would then have to be changed for every version of cairo, so it's not worth it.

Revision history for this message
Rygle (rygle) wrote :

Another possibility for conditional code would be to read the x_dpi resolution setting, and if it's less than a certain amount, the substitute code could kick in

Here is my guess of what it might look like in C++

#if x_dpi < 150 // (or whatever the correct call is for less than)
cairo_surface_set_fallback_resolution (surface, (x_dpi/72.0) * 300, (y_dpi/72.0) * 300);
#endif

Revision history for this message
Rygle (rygle) wrote :

Here's what I'm working on at the moment for ui\dialog\print.cpp - will do a build soon and see if it works. This should allow us to work with Cairo whether it has a scaling bug or not.

======
    // Alternative Fallback 1. Set resolution of fallback to printer resolution. If everything is working properly this will set the resolution much higher than actually needed as printer halftoning means laser printers don't need much more than 300dpi. Leave commented unless you know what you're doing.
    // cairo_surface_set_fallback_resolution (surface, x_dpi, y_dpi);

    // Alternative fallback 2. Set fallback to 300 dpi, compensating for cairo scaling bug
    // cairo_surface_set_fallback_resolution (surface, (x_dpi/72) *300, (y_dpi/72) *300);

    // Alternative fallback 3. Conditional fallback -> 300dpi, only if the dpi is set to less than 100dpi due to cairo bug.
    if x_dpi < 100 {
       cairo_surface_set_fallback_resolution (surface, (x_dpi/72.0) * 300, (y_dpi/72.0) * 300);
 }
======

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

Rygle wrote:
> Is there some conditional thing we can use to test whether cairo has
> this fix? That would be cleaner in some ways and messier in others I
> guess.
>
> Could do something like;
> =====
> #ifndef have_cairo_1.6 // (or whatever the correct call is)
> cairo_surface_set_fallback_resolution (surface, (x_dpi/72.0) * 300, (y_dpi/72.0) * 300);
> #endif
> =====
>
> But then I guess that would then have to be changed for every version of
> cairo, so it's not worth it.
>

As Inkscape ships the libcairo.dll with the Inkscape binary it is
probably not worth trying to make the code work for different versions
of cairo. The win32_printing_surface has only existed in the 1.5.x
development snapshots. The first stable release (1.6.0) that will
include the win32_printing_surface will have the fix.

Revision history for this message
Rygle (rygle) wrote :

Tried this, but it doesn't set the fallback to 300. Oh well, worth a try. Hopefully Ishmal can build the patched cairo and we won't need this...

==========
    if (x_dpi < 100) {
         cairo_surface_set_fallback_resolution (surface, (x_dpi/72.0) * 300, (y_dpi/72.0) * 300);
         return surface;
 }
    else {
         return surface;
    }
==========

Revision history for this message
Rygle (rygle) wrote :

Thanks Adrian. I'll give up. Good practice for me.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

I've built the latest cairo from git for testing the fallback resolution fix.

The binaries can be downloaded from:

http://annarchy.freedesktop.org/~ajohnson/cairo-2008-03-26/

This is built with cairo 1.5.15-6dc75ab0f and pixman 0.9.7-eec44d371

Revision history for this message
Rygle (rygle) wrote :

Excellent. I was just thinking I should ask about that.

It works really well. I just commented the fallback line in ui\dialog\print.cpp and it built and printed beautifully. The only error I got was because my drive got full from 4 versions of the devlibs and all the test print spool files I hadn't deleted yet.

Here's what I've been doing with the patched cairo libs;
* Drop those into the same c:\devlibs\bin directory that the normal libcairo-2.dll goes in
* Replace the normal build.xml in your working directory with the attached file. It adds a single entry for the pixman dll, so it gets copied automatically with the build.

Well, I think we're very close to a release. I'm tempted to put out my own 0.46 win32 pre4 version somewhere.

Revision history for this message
Rygle (rygle) wrote :

Can this patch be updated in 0.46 branch?

Have improved Linux compatability in response to Bryce's comments;
 - https://bugs.launchpad.net/inkscape/+bug/179988/comments/141

Have removed cairo fallback workaround, which are fixed by Adrian's patched dlls and/or new devlibs from Ishmal;
- https://bugs.launchpad.net/inkscape/+bug/179988/comments/164

Revision history for this message
Rygle (rygle) wrote :

Sorry, typo in src/extension/internal/cairo-render-context.cpp - two #'s on an endif.

Fixed version attached.

Revision history for this message
Rygle (rygle) wrote :

Changing to fix released so Launchpad counts as closed in stats

Changed in gtk:
status: New → Fix Released
Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

A new version of GTK+ has been released with the fix to make GtkPrint use the cairo_win32_printing_surface. This means the workaround in Inkscape can be removed. This should make the print options in the GtkPrint dialog (such as landscape mode) work correctly.

Revision history for this message
Okko7 (okko7) wrote :

That's great news. I kept both versions of Inkscape on my computer, that is 0.47 for general work, and 0.46 for printing.

Will the new GTK+ version be included in the stable release or only in the development version? Or is there a way to update only GTK+?

Thanks

Okko7

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

- running Win32 Inkscape19816-080908.7z
- with regret, I am going to re-open this bug since the printed output is one eighth of the normal size, as predicted in comment 169

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

Before the GTK+ update, Inkscape was scaling the printer DC and creating it's own cairo_win32_printing_surface. Now Inkscape needs to use the scale set by gtk_print on the print context.

Inkscape is correctly setting the gtk_print units to points. The problem is that Inkscape is getting the target surface from the print context then passing the surface to the renderer. As a result the scale that gtk_print sets on the print context is not used. One solution would be to use cairo_get_matrix() to get the scale from the print context and set it on every new context created from the target surface.

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

- just writing to confirm that the scaling issue still exists.
- running Windows build 21165
- on a printer with a resolution of 300 dpi, the image is too small by a factor of 4.2
- on a printer with a resolution of 360 dpi, the image is too small by a factor of 5.0
- this suggests that the image would be correct size on a printer with a resolution of 72 dpi.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

Patch to fix the print scaling problem.

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

thanks Adrian !
would someone be willing to test this on Windows and commit it?
unfortunately I work only from the nightly builds, so cannot test it before committing.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

Now that the devlibs include gtk+ 2.14 the fix for win32 printing on versions of gtk+ prior to 2.14 can be removed.

Revision history for this message
theAdib (theadib) wrote :

I commit the patches :
https://bugs.launchpad.net/inkscape/+bug/179988/comments/174
https://bugs.launchpad.net/inkscape/+bug/179988/comments/176
from <adrianj> and printing scale is ok for me. Now svn revision 21212.
Adib.

Revision history for this message
Rygle (rygle) wrote :

Tested build 21213 and seems to scale printing properly for me. Thanks very much Adrian, Adib and Alvin. Great to finally have this sorted!

Revision history for this message
Rygle (rygle) wrote :

Largley fixed in 0.46 release, however 0.47 has significantly improved printing for the Win32 platform. If you are concerned about this bug please move to 0.47 or later. The final patch will probably not work for 0.46 release code as it used much earlier dev libs.

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

thanks Adrian and Adib !

Changed in gtk:
importance: Unknown → Critical
Displaying first 40 and last 40 comments. View all 180 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

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