no printing from Windows

[Alvin Penner]

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]

[Peter Lewerin (vermeil-deactivatedaccount)]

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 ?? ()

[Simon (simon2)]

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

[Alvin Penner (apenner)]

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.

[Tom Davidson (tjd-mit)]

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...

[Alvin Penner (apenner)]

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)]

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

[do1eh (rnh)]

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.

[do1eh (rnh)]

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)

[Bryce Harrington (bryce)]

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.

[Duositex (duositex)]

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!

[micool (flightsim)]

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 )

[Duositex (duositex)]

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!

[David Bower (dave-koales)]

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...!

[Bryce Harrington (bryce)]

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.

[Duositex (duositex)]

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."

[Okko7 (okko7)]

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

[Kees Cook (kees)]

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.

[Tom Davidson (tjd-mit)]

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...

[ishmal (ishmalius)]

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.

[ishmal (ishmalius)]

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.

[Bryce Harrington (bryce)]

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.

[Aaron C Spike (acspike)]

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.)

[Duositex (duositex)]

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]
>

[Adrian Johnson (ajohnson-redneon)]

> 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.

[ishmal (ishmalius)]

@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 ^^).

[ishmal (ishmalius)]

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?

[Bryce Harrington (bryce)]

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.

[ishmal (ishmalius)]

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

[Adrian Johnson (ajohnson-redneon)]

The gtk+ bug is
http://bugzilla.gnome.org/show_bug.cgi?id=488833

[Duositex (duositex)]

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]
>

[jhoechtl (johann-hoechtl)]

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.

[Duositex (duositex)]

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.

[Okko7 (okko7)]

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?

[Alvin Penner (apenner)]

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

[bbyak (buliabyak)]

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.

[Rygle (rygle)]

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.

[Bryce Harrington (bryce)]

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.

[Bryce Harrington (bryce)]

<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

[Okko7 (okko7)]

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

[Bryce Harrington (bryce)]

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.

[Adrian Johnson (ajohnson-redneon)]

That patch is for gtk+. Cairo doesn't need any patching to use the win32_printing_surface. Although as the win32_printing_surface was added during the 1.5.x development cycle you do need one of the cairo 1.5.x development snapshots (preferably the latest). Using a recent cairo development snapshot also provides the many PDF enhancements required to get good quality vector PDF export from Inkscape.

[bbyak (buliabyak)]

We now have cairo 1.5.8 in Windows builds, so this should be OK.

Unfortunately building the libs for windows is being done by a single
person at this time - ishmal - so I really think we need his help in
building the patched gtk...

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

[ishmal (ishmalius)]

@bulia:

Actually, we have moved on to 1.5.10, which Carl released soon after. He just released 1.5.12 over the weekend, too. (Feb29) But I haven't tried that one yet. I really need to read the release notes to see what changes are in each Cairo release before grabbing the latest copy like an addict. :)

For those who are not on the dev list, I uploaded another "devlibs" library bundle on 1 Mar, with the latest Gtkmm/Glibmm/Cairomm/Sigc++ stuff in order for them to be in sync with the current Gtk libs. It is here:

http://inkscape.modevia.com/win32libs/devlibs-2.12-080301.7z

We really need 2 things:
    1. Some linux box that can host a copy of the cross-compiler and devlibs, so that people without win32 boxes can test their submissions. Being linux, it will be easier to build dependent libs like Cairo or Gtk, for when we need updates or we need our own patches.
    2. Svnserve, serving a versioned tree of the devlibs. This uploading and downloading monolithically is nuts. We need something that can handle incremental diffs and versions. Any dev should be able to cd into his devlibs dir and just do "svn up" to get the latest stuff. Svn does binary diffs, so it should be able to handle this efficiently. Something like Portage would be better later, but we need something like this now.

[ishmal (ishmalius)]

Looking at the Gtk patch, it doesn't look like it would solve our problem:

http://bugzilla.gnome.org/attachment.cgi?id=99752

I was incorrect in thinking that cairo_win32_printing_surface_create() did not need an HDC, but it does. Our bug comes from that value being null.
I'm sure that the new stuff would also fail with a null HDC. I still suspect a stack or malloc problem causing an alignment problem, though I am probably wrong about that, too. ^^

[ishmal (ishmalius)]

Hi, again. I just did a debug trace with the "fulldbg" build from
today, and I got some interesting information.

Here is the debug info, if anyone wants to follow. I set a breakpoint
at Print::run(), invoked the Print dialog, and started single-stepping
from there. After each step, I did a backtrace.

Look at the value of Print's "this", 0x22efac . And
skip to the bottom, and look at the last stacktrace.
Note that the stack appears to be screwed after
NetEnumerateComputerNames (),
between stack depths #7 and #5.

This is my own code, so it doesn't map to what you would see in print.cpp.
But what is important is the change in the stack during the call to
run().

====================================================================
Breakpoint 1, Inkscape::UI::Dialog::Print::run (this=0x22efac)
    at src/ui/dialog/print.cpp:179
179 _printop->run();
1: this->_doc = (SPDocument *) 0x459bea0
(gdb) display _base
2: this->_base = (SPItem *) 0x3e860c0
(gdb) s
0x008f9a90 in Gtk::PrintOperation::run () at CairoOutputDev.h:72
72 // (Upside-down means (0,0) is the top left corner of the page.)
(gdb) bt
#0 0x008f9a90 in Gtk::PrintOperation::run () at CairoOutputDev.h:72
#1 0x004f977b in Inkscape::UI::Dialog::Print::run (this=0x22efac)
    at src/ui/dialog/print.cpp:179
#2 0x0041aa6f in sp_print_document (parentWindow=@0x5499300, doc=0x459bea0)
    at src/print.cpp:138
#3 0x00410c1e in sp_file_print (parentWindow=@0x5499300) at src/file.cpp:1378
#4 0x004e9cc2 in sp_action_perform (action=0x45a1d20, data=0x0)
    at src/helper/action.cpp:181
#5 0x62743995 in _libmsvcrt_a_iname () from C:\inkscape\libgobject-2.0-0.dll
#6 0x045a1d20 in ?? ()
#7 0x00000000 in ?? ()
(gdb) s
Gtk::PrintOperation::run (this=0x7005df8,
    action=Gtk::PRINT_OPERATION_ACTION_PRINT_DIALOG) at printoperation.cc:56
56 printoperation.cc: No such file or directory.
        in printoperation.cc
(gdb) bt
#0 Gtk::PrintOperation::run (this=0x7005df8,
    action=Gtk::PRINT_OPERATION_ACTION_PRINT_DIALOG) at printoperation.cc:56
#1 0x004f977b in Inkscape::UI::Dialog::Print::run (this=0x22efac)
    at src/ui/dialog/print.cpp:179
#2 0x0041aa6f in sp_print_document (parentWindow=@0x5499300, doc=0x459bea0)
    at src/print.cpp:138
#3 0x00410c1e in sp_file_print (parentWindow=@0x5499300) at src/file.cpp:1378
#4 0x004e9cc2 in sp_action_perform (action=0x45a1d20, data=0x0)
    at src/helper/action.cpp:181
#5 0x62743995 in _libmsvcrt_a_iname () from C:\inkscape\libgobject-2.0-0.dll
#6 0x045a1d20 in ?? ()
#7 0x00000000 in ?? ()
(gdb) s
63 in printoperation.cc
(gdb) bt
#0 Gtk::PrintOperation::run (this=0x7005df8,
    action=Gtk::PRINT_OPERATION_ACTION_PRINT_DIALOG) at printoperation.cc:63
#1 0x004f977b in Inkscape::UI::Dialog::Print::run (this=0x22efac)
    at src/ui/dialog/print.cpp:179
#2 0x0041aa6f in sp_print_document (parentWindow=@0x5499300, doc=0x459bea0)
    at src/print.cpp:138
#3 0x00410c1e in sp_file_print (parentWindow=@0x5499300) at src/file.cpp:1378
#4 0x004e9cc2 in sp_action_perform (action=0x45a1d20, data=0x0)
    at src/helper/action.cpp:181
#5 0x62743995 in _libmsvcrt_a_iname () from C:\inkscape\libgobject-2.0-0.dll
#6 0x045a1d20 in ?...

[Rygle (rygle)]

Hi,

I just ran Inkscape0803031858-fulldbg, both with and without gdb, and had no crashes with printing, although the print was very small - an A4 page came out at 2.5x3.5cm using two different printer drivers. The same file prints normally on 0.45.1, however in 0.45.1 the spool file was 7.52Mb, while in this dev version it was 433Kb.

The only error I got in gdb was;
BFD: C:\WINDOWS\system32\wmvcore.dll Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
BFD: C:\WINDOWS\system32\wmvcore.dll Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
BFD: C:\WINDOWS\system32\wmvcore.dll Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc

This really seems to be unrelated, because that dll's description is "Windows Media Playback/Authoring DLL".

Exporting this file to PDF works without crashing and has shrunk the file from 336Kb to 277Kb compared to the last pre Cairo 1.5.12 dev version I had from Feb 29.

[Adrian Johnson (ajohnson-redneon)]

> although the print was very small - an A4 page came out at 2.5x3.5cm

The device units of a Windows printer DC are 1 unit == 1 printer pixel. If the device units are incorrectly assumed to be in points (1/72"), on a 600dpi printer the output will be 72/600 =0.12 of the size. An A4 size job (21 cm x 29.7 cm) will print out at the size 2.52 x 3.564 cm.

It looks like Inkscape needs to call gtk_print_operation_set_unit (_printop, GTK_UNIT_POINTS)

As Windows places the origin at the start of the printable area rather than the top left of the page you probably also want to call gtk_print_operation_set_use_full_page () if you want the output to be positioned identically on both Windows and Linux.

[Rygle (rygle)]

Good suggestion Adrian.

Printing with the driver set at 300dpi doubles the size, while 1200 dpi halves the size (from 2.5x3.5cm).

Another complication is that the data is not coming through 100%. It seems to be putting a white box around any object that overlaps another object. For instance, the draw-freely.svg file in the share\clipart folder prints with white boxes on the Inkscape logo where the boundaries of the white peak and lower white highlight are over the black. But if I ungroup and then do a difference (ctrl+-) on each of the white sections with the background one at a time to make it one single path, then the whole thing prints fine. I've attached a file showing how it looks when it prints that file, and more complex files look lots worse.

FYI I am using a Lexmark Optra T616 with PS3 drivers, but this happens with 2 different Non-PS drivers as well. Windows XP SP2. Prints fine on Inkscape 0.45.1.

[Rygle (rygle)]

I have also printed to the PDF Creator (pdfforge.org) printer driver and it does pretty much the opposite, putting black boxes around the objects underneath the overlapping objects.

I've attached a sample of the draw-freely.svg file printed at 600dpi.

[Adrian Johnson (ajohnson-redneon)]

> It seems to be putting a white box around any object that overlaps another object.

See the comment I made earlier about needing to use cairo_win32_printing_surface instead of cairo_win32_surface. cairo_win32_surface can not read the destination bitmap from the printer driver. Depending on the driver it will see the destination as all white or all black.

[Alvin Penner (apenner)]

running the win32 binary build : Inkscape-0.45+0.46pre3-1.win32.exe
I do not have a printer on this machine so I am using PDF Creator.
Default resolution on PDF Creator is 600 dpi. If I print a page I get a black rectangle about 1 inch square in the upper left.
If I change the PDF Creator resolution to be 96 dpi, then the size of the black rectangle increases by a factor of 6 or so, as previously discussed.
This is by far the most promising result I have seen in the last two months, wish I could get my other machine to do this.

In DOS I get an exit message :
C:\Python25>python inkcl.py

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

but I am not sure this is relevant, I think I've seen this elsewhere on other occasions. (Note that the cairo_win32_surface_create message is not present.)

[Alvin Penner (apenner)]

still running win32 binary : Inkscape-0.45+0.46pre3-1.win32.exe
    by trial and error I think I have accidentally stumbled onto something that would be worth investigating some more. I can make the cairo_win32_surface error go away or come back again as I please by adjusting the relative values of the default printer compared to the selected printer. In the print dialog there is both a "default" and a "selected" printer. These are normally the same, but need not be, and in this case they *should not* be.

I have two printer drivers, a BJC-250 (which is physically attached) and an i550 driver (with no printer attached).
Steps to reproduce:
Run 1:
- close Inkscape, use control panel to select BJC-250 as the default
- run Inkscape, draw green border, choose Print and use the default BJC printer
- get no printing, no printer icon in taskbar, and no formfeed
- close Inkscape and get DOS message : cairo_win32_surface_create: The handle is invalid.
Run 2:
- close Inkscape, use control panel to select i550 as the default, even though there is no such printer attached
- run Inkscape, draw green border, choose Print and use the default i550 printer
- get a line of one single pixel's worth of output at the top, plus a formfeed
- close Inkscape and get *no* DOS message
Run 3:
- close Inkscape, leave the i550 as the default
- run Inkscape, draw green border, choose Print and select the BJC-250 without changing the default printer
- get a rectangle about 1/6 of the size of the full page, plus a formfeed
- close Inkscape and get *no* DOS message
- in the rectangle is the appropriate green border, plus a black filled center

the image needs some tweaking before it will look nice, but at least there is printing, whereas previously there was none.
It appears to be mandatory that the selected printer cannot be the same as the default printer, sort of like an address off-by-one?

[pete twang (fillpete)]

Thank you Alvin for your extensive explination. I did download the USB inkscape and it prints ok.
  thank you once again.

Alvin Penner <email address hidden> wrote:
  still running win32 binary : Inkscape-0.45+0.46pre3-1.win32.exe
by trial and error I think I have accidentally stumbled onto something that would be worth investigating some more. I can make the cairo_win32_surface error go away or come back again as I please by adjusting the relative values of the default printer compared to the selected printer. In the print dialog there is both a "default" and a "selected" printer. These are normally the same, but need not be, and in this case they *should not* be.

I have two printer drivers, a BJC-250 (which is physically attached) and an i550 driver (with no printer attached).
Steps to reproduce:
Run 1:
- close Inkscape, use control panel to select BJC-250 as the default
- run Inkscape, draw green border, choose Print and use the default BJC printer
- get no printing, no printer icon in taskbar, and no formfeed
- close Inkscape and get DOS message : cairo_win32_surface_create: The handle is invalid.
Run 2:
- close Inkscape, use control panel to select i550 as the default, even though there is no such printer attached
- run Inkscape, draw green border, choose Print and use the default i550 printer
- get a line of one single pixel's worth of output at the top, plus a formfeed
- close Inkscape and get *no* DOS message
Run 3:
- close Inkscape, leave the i550 as the default
- run Inkscape, draw green border, choose Print and select the BJC-250 without changing the default printer
- get a rectangle about 1/6 of the size of the full page, plus a formfeed
- close Inkscape and get *no* DOS message
- in the rectangle is the appropriate green border, plus a black filled center

the image needs some tweaking before it will look nice, but at least there is printing, whereas previously there was none.
It appears to be mandatory that the selected printer cannot be the same as the default printer, sort of like an address off-by-one?

--
no printing from Windows
https://bugs.launchpad.net/bugs/179988
You received this bug notification because you are a direct subscriber
of a duplicate bug.

Status in gtk: New
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]

Pete

---------------------------------
Sent from Yahoo! Mail.
The World &#39;s Favourite Email.

[Ulferikson (ulferikson)]

After some testing (with "print to file" only; i'm unable to view the files afterwards so i don't know whether the output is okay) it seems the default page size causes the invalid hdc.

Here is a patch that doesn't set any default page size and instead sets the units and full page as suggested by Adrian.

[Alvin Penner (apenner)]

okay, I think you are right, the issue is not the default printer, the issue is the default output settings.
I have had one successful output by using the default printer, but refusing to use the default page settings.

[Alvin Penner (apenner)]

I should clarify, the output was very small, but small is better than nothing.

[jarks (jarks)]

Inkscape 0.45+0.46pre3+devel, built Mar 8 2008, windows XP

When I want to print page, program every time crashes.
Last functional version was 0.46dev+devel, built Nov 29 2007, which
I launch when I need to print.

gdb output:

Program received signal SIGSEGV, Segmentation fault.
0x63c90f28 in FcPatternObjectPosition ()
   from c:\Program Files\inkscape\libfontconfig-1.dll

second try:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c901231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7c901231 in ntdll!DbgUiConnectToDbg ()
   from C:\WINDOWS\system32\ntdll.dll
#1 0x7c96c943 in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\WINDOWS\system32\ntdll.dll
#2 0x0023b6d8 in ?? ()
#3 0x7c949eb9 in ntdll!RtlInsertElementGenericTableAvl ()
   from C:\WINDOWS\system32\ntdll.dll
#4 0x0035a658 in ?? ()
#5 0x000002a2 in ?? ()
#6 0x00260000 in ?? ()
#7 0x00000001 in ?? ()
#8 0x0035b420 in ?? ()
#9 0x00000000 in ?? ()

[Ulferikson (ulferikson)]

Alvin, Did you try the patch? Removing the default page size was enough to enable printing for you too? I've installed a PS printer so I can see what I print to file. Setting the gtk unit to points give the right size for me when printing as bitmap. Only printing as vector remains too small. But is that really a Windows only problem?

jarks, Do you see a crash when printing any file or only files with text? Did you try to print as bitmap? Does "Save as.. pdf" crash for you too? What if you select "Convert text to paths"?

[Alvin Penner (apenner)]

Sorry for the delay in responding. Unfortunately, I can't try the patch because I don't compile the code myself, I run from the win32 nightly builds.
    However, I have been able to successfully avoid the crash as follows: When the print dialog comes up, click on Preferences, then click on Advanced, then click on Paper Size, then select a page size different from your default size, then go back to your original page size if you like, then click OK, and OK again, and Print.
    If I do this then I get no error messages and no crash and I get a printout which is 1/6 of the proper size, and also a black background.

[Rygle (rygle)]

I have been trying to test this patch, but have been learning a lot in the meantime.

If anyone wants to patch and build their own binaries to test, I have updated the following page on the Wiki to help the process.
http://wiki.inkscape.org/wiki/index.php/Win32Port

No doubt there are some problems with the changes I've made, but together with what was already there it should get most people on the way. Some of my build error questions need answers if anyone can help.

Note: there are three different files called print.cpp in the source tree if you're trying to patch. This one is the /src/ui/dialog/print.cpp one. Something should be done about duplicate file names.

[Ulferikson (ulferikson)]

Alvin Penner:
> Sorry for the delay in responding. Unfortunately, I can't try the
> patch because I don't compile the code myself, I run from the
> win32 nightly builds.

Ok. But.. I think the nightly builds are from the trunk not the 0.46 branch. Maybe not all that important for this bug though. Trunk has the same issue.

Rygle:
> If anyone wants to patch and build their own binaries to test, I
> have updated the following page on the Wiki to help the process.
> http://wiki.inkscape.org/wiki/index.php/Win32Port

Again, I think the snapshots are from the trunk. You might want to add a blob about TortoiseSVN and how to pull the latest source from the repository. The URL to use would be:
https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/branches/RELEASE_0_46_BRANCH
Tortoise is also a nice tool to use when applying patches.

Ulferikson:
> jarks, Do you see a crash when printing any file or only files
> with text? Did you try to print as bitmap? Does "Save as.. pdf"
> crash for you too? What if you select "Convert text to paths"?

What a mess.. You can ignore my suggestion to compare with saving the file as pdf. The "Save as.. pdf" uses the printer interface and the "Print (with vectors)" uses the output interface and an "experimental" renderer. They both use cairo but don't share code. While the old postscript backend used the same code for both saving and printing

[jarks (jarks)]

> Do you see a crash when printing any file or only files with text? Did you try to print as bitmap? Does "Save as.. pdf" crash for you too? What if you select "Convert text to paths"?

I did some tests and:

- if file doesn't contains text, program don't crash, but nothing is printed
- the same if file contains text converted to paths
- if file contains plain text, program crashes every time
- if file contains plain text and it is printed as bitmap, program don't crash, but nothing is printed
- saving to PDF doesn't crash, but in created PDF file is NON-curved text flipped upside down and text converted to paths is OK (this is really strange)

[Rygle (rygle)]

I tried the above patch (https://bugs.launchpad.net/inkscape/+bug/179988/comments/54) and built a new version from the trunk from March 13 and it didn't seem to make any difference. On printing as vector there was no crash, but still printed small and with blocks. On printing as bitmap it was perfect, but the spool file was 32Mb at 72dpi, so it's not really practical.

I think I patched /src/ui/dialog/print.cpp properly, and the build seems to run normally in other ways, but my build experience is limited. I haven't yet managed to get the 0.46 branch patched and compiled, but will try using Tortoise.

[Albin Sunnanbo (albin-sunnanbo)]

As this seems to be the major collection of windows printing bugs I duplicate the findings from bug #176944
This related to the crash-part of this bug, where Inkscape crashes when a drawing containing text is printed on Windows.
The line

PangoFcFont *fc_font = PANGO_FC_FONT(font);
(cairo-render-context.cpp:1424)
prints the "invalid cast from `PangoWin32Font' to `PangoFcFont'"-message

The actual crash comes later down, but this seems to be the root cause.

The behavior is the same on trunk as well as the .46 branch.

[Rygle (rygle)]

Tried the above patch and with the 0.46 Release SVN and it still seems to print small.

After more experimentation, I have been getting crashes on all 0.46+ builds trunk or release branches. They seem to be related to text as far as I can tell, but not all documents with text seem to crash. For instance, I have been able to print the "draw freely" file that comes with Inkscape without crashes, but still with blocks and small as above. However I have also had another document where it will crash with plain text, but if I convert the text to paths it does not crash. So, whatever is causing the crash is not generic, but dependent on the content of the document.

[Ulferikson (ulferikson)]

> Tried the above patch and with the 0.46 Release SVN and
> it still seems to print small.

Let me explain once more what the patch does and does not, and then you can tell whether you see the same..

Without the patch: Using the default printer with the default pagesize gives no output. First selecting another printer or pagesize does. But both vector or bitmap prints too small.

The patch removes to pagesize selection done by Inkscape. This might help with the "cairo_win32_surface_create: The handle is invalid" error. The patch also set the GTK unit to points. If Inkscape uses points while GTK assumes pixels this should help with the size issue.

With the patch: It is possible to use the default printer with the default pagesize. Bitmap prints at full size. But vectors still prints too small.

[Ulferikson (ulferikson)]

> PangoFcFont *fc_font = PANGO_FC_FONT(font);
> (cairo-render-context.cpp:1424)
> prints the "invalid cast from `PangoWin32Font' to
> `PangoFcFont'"-message

It looks like part of cairo renderer expects freetype fonts, while win32 fonts are used on windows.. Maybe something like this patch has to be done?

[Albin Sunnanbo (albin-sunnanbo)]

I have tested the patch in https://bugs.launchpad.net/inkscape/+bug/179988/comments/67 on Vista SP1
I applied the patch on trunk, revision 17915.
It solves the font issue in https://bugs.launchpad.net/inkscape/+bug/179988/comments/64 on my machine.

I have tested with the example file in https://bugs.launchpad.net/inkscape/+bug/176944 as well as with a document with only text that did crash on me without the patch.

[Rygle (rygle)]

Albin, I think you've solved the crash. Great work!

I patched the latest 0.46 release SVN (17916 I think it was) using both the above patches, built it and had no crashes printing docs with text. It would be good if a few others could do the same thing and test with a range of documents and fonts.

I realised that I put in some bad information last time - the draw-freely.svg file fonts have been converted to paths. So I think it is clear that fonts are the cause of the crash.

So if the crash is really fixed, here's where I think we are at with this bug.
* Things still printing small and with blocks of white or black when printing vector.
* Everything prints fine when printing as bitmap, but huge spool files and takes a loooong time.

[Rygle (rygle)]

Sorry, I should have thanked Ulferikson, not Albin, but you're both doing great work!

[Rygle (rygle)]

Just to clarify the font thing in case any more info is needed, here is what happens with the 0.46pre3 binary using gdb when I go to print inkscape.logo.svg (can't open because of gdb, so have to import) with some text added ("Inkscape logo" above logo with default formatting).

------------------
Program received signal SIGSEGV, Segmentation fault.
0x63c90f28 in FcPatternObjectPosition ()
   from D:\Download\Multimedia\Image\Inkscape\Latest\inkscape\libfontconfig-1.dll
(gdb) bt
#0 0x63c90f28 in FcPatternObjectPosition ()
   from D:\Download\Multimedia\Image\Inkscape\Latest\inkscape\libfontconfig-1.dll
#1 0x63c90f81 in FcPatternObjectFindElt ()
   from D:\Download\Multimedia\Image\Inkscape\Latest\inkscape\libfontconfig-1.dll
#2 0x63c9142c in FcPatternObjectGet ()
   from D:\Download\Multimedia\Image\Inkscape\Latest\inkscape\libfontconfig-1.dll
#3 0x63c91626 in FcPatternObjectGetString ()
   from D:\Download\Multimedia\Image\Inkscape\Latest\inkscape\libfontconfig-1.dll
#4 0x68e1ad00 in _cairo_ft_unscaled_font_create_for_pattern ()
   from D:\Download\Multimedia\Image\Inkscape\Latest\inkscape\libcairo-2.dll
#5 0x68e1e65c in cairo_ft_font_face_create_for_pattern ()
   from D:\Download\Multimedia\Image\Inkscape\Latest\inkscape\libcairo-2.dll
#6 0x006c2baf in Inkscape::Extension::Internal::CairoRenderContext::renderGlyph
text ()
#7 0x005f10f2 in Inkscape::Text::Layout::showGlyphs ()
#8 0x006bed0c in Inkscape::Extension::Internal::CairoRenderer::renderItem ()
#9 0x006bf3c0 in Inkscape::Extension::Internal::sp_group_render ()
#10 0x006bea1a in Inkscape::Extension::Internal::CairoRenderer::renderItem ()
#11 0x006bf3c0 in Inkscape::Extension::Internal::sp_group_render ()
#12 0x006be49f in Inkscape::Extension::Internal::CairoRenderer::renderItem ()
#13 0x004f60dd in draw_page ()
#14 0x62743995 in _libmsvcrt_a_iname ()
   from D:\Download\Multimedia\Image\Inkscape\Latest\inkscape\libgobject-2.0-0.dll
#15 0x056856c0 in ?? ()
#16 0x06c85128 in ?? ()
#17 0x00000000 in ?? ()
--------------------

- If I don't add text to the logo, no crash on printing.
- With the latest patch from Ulferikson for src/extension/internal/cairo-render-context.cpp, I can add text and no crash on printing.

[Ulferikson (ulferikson)]

Attaching a new version of the font issue patch

> So if the crash is really fixed, here's where I think
> we are at with this bug.
> * Things still printing small and with blocks of white
> or black when printing vector.
> * Everything prints fine when printing as bitmap, but
> huge spool files and takes a loooong time.

* Convert texts to paths doesn't work. (not actually printing related but part of the cairo renderer and maybe the freetype/win32 font issue)

The suggested fix for the blocks of white and black is to use cairo_win32_printing_surface_create() instead of cairo_win32_surface_create(). You need to patch gtk for that, not Inkscape.

https://bugs.launchpad.net/inkscape/+bug/179988/comments/50
https://bugs.launchpad.net/inkscape/+bug/179988/comments/24
https://bugs.launchpad.net/inkscape/+bug/179988/comments/25

[Ulferikson (ulferikson)]

Another issue:

* If you use "opacity" instead of "alpha" to make half transparent objects the text is suddenly badly aligned.

Still.. I wonder how much of the remaining printing issues are really windows specific

[Rygle (rygle)]

Here's the results of my latest testing.

* Page Size Patch - https://bugs.launchpad.net/inkscape/+bug/179988/comments/54
Seems to be working well to stop non-print. Thanks!

* Font Crash Patch - https://bugs.launchpad.net/inkscape/+bug/179988/comments/72
Ulferikson: your latest patch still works perfectly as far as I can tell (0.46 release SVN 17926 built with both above patches and latest dev libs). I tried putting several pieces of text over the top of the inkscape.logo.svg file and there are no crashes on printing, and the fonts are good. Still blocks of black and white on the picture, but interestingly not on the fonts - I know that's not what this patch fixes, but am puzzled that the image and font content are treated differently.

Ulferikson: Thanks for your follow ups about where we're up to. I'm not sure what you mean by "Convert texts to paths doesn't work". Before your patch converting texts to paths stopped crashes for me (object to path), and after patching I don't need to convert to stop crashes.

* Black & White Boxes on printing - https://bugs.launchpad.net/inkscape/+bug/179988/comments/37, https://bugs.launchpad.net/inkscape/+bug/179988/comments/50
Has anyone tried using the gtk patch (http://bugzilla.gnome.org/show_bug.cgi?id=488833) to rid us of black and white boxes? I looked at that a few days ago in the gnome bug site, but no-one has actually reported having used the patch, so I have asked there if anyone knows of a build with it. I know Ishmal tried looking through the code and said he didn't think the patch would help (https://bugs.launchpad.net/inkscape/+bug/179988/comments/44) because cairo_win32_printing_surface_create() needs an HDC that is non-null (whatever that means!). But it's still worth a try isn't it? Has anyone tested this?

* Print size
Printing as a vector and changing the dpi still changes the size of the print. If you print to a ps file, you can actually see that much of a "vector" print is actually still a raster, although at 300dpi and 1200dpi the size of the ps file doesn't seem to change. I've attached both ps files and if you zoom in on these you can see the pixels starting pretty soon.

Doing "fc logo300dpi.ps logo1200dpi.ps /C /L /N > psdiff.txt" to compare the two files shows negligible differences.
Comparing files logo300dpi.ps and LOGO1200DPI.PS
***** logo300dpi.ps
    7: %%Creator: LEXPSNT3 Version 7.4.1
    8: %%CreationDate: 16:43 3/19/2008
    9: %%Pages: (atend)
***** LOGO1200DPI.PS
    7: %%Creator: LEXPSNT3 Version 7.4.1
    8: %%CreationDate: 16:44 3/19/2008
    9: %%Pages: (atend)
*****

***** logo300dpi.ps
   90: [{
   91: %%BeginFeature: *Resolution 300dpi
   92: << /HWResolution [300 300] >> setpagedevice
   93: %%EndFeature
***** LOGO1200DPI.PS
   90: [{
   91: %%BeginFeature: *Resolution 1200dpi
   92: << /HWResolution [1200 1200] >> setpagedevice
   93: %%EndFeature
*****

***** logo300dpi.ps
  115: %%EndPageSetup
  116: 10 829 translate 72 300 div dup neg scale
  117: 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itransform translate
***** LOGO1200DPI.PS
  115: %%EndPageSetup
  116: 10 829 translate 72 1200 div dup neg scale
  117: ...

[loucypher (loucypher)]

I patched latest RELEASE_0_46_BRANCH (17939?) with the first two files mentioned in
  https://bugs.launchpad.net/inkscape/+bug/179988/comments/74
for "Page Size Patch" and "Font Crash Patch", but it doesn't work here for page size: printing with PDF Creator still generates a too small printout.
I tried a document starting from blank page (A4 size), adding a text ("ABCDEFG") with default settings, stretching it to be (almost) full page in width and half page in height, then adding a rectangle for the lower half of page (black border/white filling).
The result is roughly 1/8 of a full page (with the box still all black, of course).

~ Lou

[Rygle (rygle)]

Loucypher: Good on you for testing! The page size patch actually is more to do with stopping non-printing by correcting the default page size setting. Before this patch, sometimes it would say it was printing and then give no output at all. See here - https://bugs.launchpad.net/inkscape/+bug/179988/comments/66 - maybe I should have referred to it as the "Default Pagesize Patch". Keep chipping away.

On another note, I've realised that doing an ASCII compare might not give the right results for the above ps files, but they are exactly the same size. I have also been wondering how printer driver dependent the ps output is. It is a PS3 printer driver, and PS3 must also be able to contain raster images, however the files don't seem to change much if I set it to full ascii output, and set compression settings to none.

[Ulferikson (ulferikson)]

Attaching a new patch. This one includes the changes from the earlier patches plus avoids the context to surface and back to context conversions done. This might have been the reason the units got reset?

> * Page Size Patch - Seems to be working well to stop
> non-print. Thanks!

Well.. it only shows where the problem is. It's no solution. You want Inkscape to preselect a papersize that corresponds to the size of your drawing.

> I'm not sure what you mean by "Convert texts to paths
> doesn't work".

Sorry, I was a bit unclear. I have sometimes used "Save as Postscript via Cairo" for testing. It uses the same code as printing.

> I know Ishmal tried looking through the code and said
> he didn't think the patch would help because
> cairo_win32_printing_surface_create() needs an HDC
> that is non-null (whatever that means!).

The HDC was NULL because Windows couldn't accept the papersize suggested by Inkscape. At least that is my guess :)

> Printing as a vector and changing the dpi still
> changes the size of the print.

Yes. Somehow things are still pixel based instead of point based. I have an idea though.. Maybe you can try the new patch? I have fullsize images now. But.. the size of the drawing and the size of the paper still doesn't match.

> Is it possible when you call
> gtk_print_operation_set_use_full_page (_printop, TRUE)
> to actually tell it separately what that full page
> size is? Or should it already do that?

I don't know. I just added that line because Adrian said so :)

> * Some Niggling Issues/Questions:

Vector or bitmap is about how Inkscape communicates with cairo. Whether cairo uses vector or bitmaps when converting the content to pdf, ps or windows metafiles is beyond our control. Have you read this section of the release notes (the same is true for all other cairo backends): http://wiki.inkscape.org/wiki/index.php/ReleaseNotes046#PDF_export

[Adrian Johnson (ajohnson-redneon)]

I am attaching the test code that I used when I wrote the cairo_win32_printing_surface. Someone may be able to use this to try out Inkscape with the cairo win32 printing surface and work out whether the problem is in Inkscape or gtkprint.

The test code creates a DC for a printer. There is a #define PRINT_DLG that if defined will cause a print dialog to pop up. Otherwise it will print to the file cairo.ps using the default printer. Obviously you will want to have a PostScript printer driver installed and set as the default for this to work. I used the HP LaserJet 4550 driver for testing even though I don't have this printer as it is a PostScript Level 3 color printer. I viewed the output using GSView and ghostscript.

I would suggest finding where Inkscape gets the cairo_t * pointer from gtkprint and instead supply the cairo_t * created in the test code.

[Ulferikson (ulferikson)]

> I would suggest finding where Inkscape gets the
> cairo_t * pointer from gtkprint and instead supply the
> cairo_t * created in the test code.

A bit clumsily done (I receive two print dialogs now) but using the cairo_t * from your test code produces a nice postscript with vector operators, but the size is still not perfect.

[Adrian Johnson (ajohnson-redneon)]

Some more things to try:

Try adding some code after the cairo_t* is created and before the Inkscape drawing code is called to draw a rectangle of a known size and check what size it prints out as.
 eg

cairo_set_source_rgb (cr, 0, 0, 0);
cairo_rectangle (cr, 2*72, 2*72, 4*72, 4*72);
cairo_stroke (cr);

This should stroke a black square 4" x 4" in size and offset 2" from the top and left sides.

You could also redirect the drawing to a PS or PDF file. eg

cairo_surface_t *surface;
cairo_t *cr;

surface = cairo_pdf_surface_create ("filename.pdf", 595, 842);
cr = cairo_create (surface);

and check if that works.

[Ulferikson (ulferikson)]

> Try adding some code after the cairo_t* is created and
> before the Inkscape drawing code is called to draw a
> rectangle of a known size and check what size it
> prints out as.

Thanks. My new code path missed a cairo_scale() call. The new patch gives output of correct size. If WIN_PRINT_TEST is defined, and the test code from win-print.c is used, the image contains vectors otherwise bitmaps.

[Rygle (rygle)]

Ulf and Adrian, this is a good step forward. Patched and built 0.46 release SVN 17943 and printing is now the right size. Great work! At first I thought there were no more bitmaps but when I zoomed right in I could see them there, but still greatly improved. Colour printing seems to work pretty well too (used a Apple Colour Laserwriter PS driver). Didn't print blurs at all as far as I can tell.

So now it seems the remaining issues are;
* Transparency - fix - GTK patch?
* bitmaps vs. vector in prints - much better - only affects spool file size now really, as the quality is higher than before - fix - ?
* blurs not appearing - fix - ?

Patch/Diff Note:
The first two patches apply cleanly with TortoiseSVN, but I keep getting errors trying to patch with the last part - ui/dialog/print.cpp - using Tortoise. It complained about line mismatches with both the current version and the last version of your patch. Anyway, patched manually and built on SVN 17943. I'm puzzled, because even after I patched manually and generated my own diff patch and try to reapply that to the SVN version, it still complains! Anyway, that's not the biggest deal.

[Rygle (rygle)]

Ulf remarked earlier about different lots of code for printing and PDF (https://bugs.launchpad.net/inkscape/+bug/179988/comments/61);
> The "Save as.. pdf" uses the printer interface and the "Print (with vectors)" uses the output interface and an "experimental" renderer. They both use cairo but don't share code. While the old postscript backend used the same code for both saving and printing

Is this the same with printing vs. Save to PS via Cairo? I am puzzled why saving to ps via Cairo produces clean vectors with no white blocks. That suggests to me that different code is being used. Perhaps the printing code is using cairo/GTK badly at some point, while the Save to ps via Cairo is using it slightly better. This does not eliminate whether the problem is with GTK/Cairo or Inkscape though, because the GTK element in question is the common print dialog, which has nothing to do with save as PS via Cairo (If my logic is correct!).

I also tested blur on the PS via Cairo output, although when I tested this it doesn't just turn the blurred elements to bitmaps, but everything in the image, and the blurred elements are also shifted somewhat from their proper location.

[Adrian Johnson (ajohnson-redneon)]

Rygle wrote:
> Ulf and Adrian, this is a good step forward. Patched and built 0.46
> release SVN 17943 and printing is now the right size. Great work! At
> first I thought there were no more bitmaps but when I zoomed right in I
> could see them there, but still greatly improved.

Assuming you are now using the cairo_win32_printing_surface you should
be getting all vectors for simple stuff like text/stroke/fill with solid
opaque colors. Transparent colors are likely to result in fallback
images as they are not supported by GDI.

Redirecting the cairo drawing to a PDF file as described in

https://bugs.launchpad.net/inkscape/+bug/179988/comments/82

is a good way to determine whether a problem is in Inkscape or cairo.

[Ulferikson (ulferikson)]

> At first I thought there were no more bitmaps but when
> I zoomed right in I could see them there,

Did you define WIN_PRINT_TEST to use Adrian's test code? (look in print.cpp) You will get two printer dialogs. The second one matters. For me this produces clean vectors.

> So now it seems the remaining issues are;
> * Transparency - fix - GTK patch?
> * bitmaps vs. vector in prints -
> * blurs not appearing - fix - ?

If there is no support for blur or transparency in the output format you need to mimic it someway. I don't know what Inkscape turns into raster and cairo does.. Search for "ctx->setContextTarget" and try add some lines like these right before:
    //ctx->setPSLevel(CAIRO_PS_LEVEL_3);
    ctx->setTextToPath(false);
    ctx->setFilterToBitmap(true);
    ctx->setBitmapResolution(72);

> I am puzzled why saving to ps via Cairo produces clean
> vectors with no white blocks.

With save as ps you ask cairo to produce the postscript. With print to a postscript printer I think cairo produces a windows meta file and the printer driver will translate that to a postscript. The white blocks have been said to come because gtk asks cairo for the wrong sort of meta file. at least that is my understanding

[theAdib (theadib)]

Reagrding blur I need to say "Not implemented in the cairo-pdf exporter" it is implemented in the cairo-PS exporter. Thats propably my bad, because I was to busy with my office stuff so I couldn't make it for the current release. I will try to do that ASAP after we publish the 0.46 for windows.
But it definately won't make it to the 0.46.0 release.
for printing you must then use the bitmap exporter.
Hope that clarifies the situation regarding blur. Adib.

[Rygle (rygle)]

OK, I wasn't thinking about Adrian's comment above... does this fully explain the differences between Printing via Cairo vs. Save as ps via Cairo? Vectors vs. Bitmap?

> See the comment I made earlier about needing to use cairo_win32_printing_surface instead of cairo_win32_surface. cairo_win32_surface can not read the destination bitmap from the printer driver. Depending on the driver it will see the destination as all white or all black.

Adrian or Ishmal: have you built GTK+ with the patch? The readme in the GTK source directory seems designed to warn off the inexperienced (like me!). I am not even sure the guy who wrote the patch has compiled a patched version.

[Ulferikson (ulferikson)]

> Reagrding blur I need to say "Not implemented in the
> cairo-pdf exporter" it is implemented in the cairo-PS
> exporter.

Is there a reason why the two are not the same?

The "pdf via cairo"-exporter uses sp_item_invoke_print() while the "postscript via cairo"-exporter uses the new CairoRenderer class (the same class as is used for printing).

In extension/init.cpp one can active a "Cairo PDF experimental"-exporter that also uses CairoRenderer.

[Adrian Johnson (ajohnson-redneon)]

Ulferikson wrote:
>> I am puzzled why saving to ps via Cairo produces clean
>> vectors with no white blocks.
>
> With save as ps you ask cairo to produce the postscript. With print to a
> postscript printer I think cairo produces a windows meta file and the
> printer driver will translate that to a postscript. The white blocks
> have been said to come because gtk asks cairo for the wrong sort of meta
> file. at least that is my understanding

The reason for the white blocks is because gtk is using
cairo_win32_surface instead of cairo_win32_printing_surface for printing.

The difference is:

cairo_win32_surface_create() accepts a DC supplied by the application.
It will call the GDI functions for a small number of operations where
the GDI rendering matches cairo rendering. Mostly just text and
filling/stroking of rectangles that are on integer coordinates with
solid colors. For anything else cairo reads and writes a bitmap
associated with the DC. This does not work well with DCs for printers
where there is no bitmap that can be accessed.

cairo_win32_printing_surface_create() also accepts a DC however it
restricts itself to only calling the GDI functions for
fill/stroke/text/drawing images. At printer resolutions antialiasing is
not required. The cairo_win32_printing_surface shares the same code as
the PostScript backend for supporting transparency. ie it generates
fallback images and paints them onto the DC after all the vector drawing
has completed.

When printing, Windows writes all the GDI functions called on the
printer DC out to an EMF file (the spool file) then replays this to the
printer driver. The printer driver will generate PostScript, PCL, or
whatever the printer supports and send it to the printer.

So you can see that when printing Windows records all the GDI function
calls to a spool file however cairo_win32_surface is writing to a bitmap
in memory associated with the DC. All the drawing to the in memory
bitmap cairo does will not end up in the spool file.

That is why I wrote the cairo_win32_printing_surface. It was simply not
possible to fix cairo_win32_surface to better support printing. The
win32_surface was designed to be fast when drawing on the screen while
the win32_printing_surface was designed to be careful to only use GDI
function calls for drawing and never try to read image data back from
the DC.

[Adrian Johnson (ajohnson-redneon)]

Rygle wrote:
> Adrian or Ishmal: have you built GTK+ with the patch? The readme in the
> GTK source directory seems designed to warn off the inexperienced (like
> me!). I am not even sure the guy who wrote the patch has compiled a
> patched version.

I really don't have any interest in trying to compile GTK+ or Inkscape
under Windows. The only time I use Windows is to improve the win32
support in cairo. The recent exception being the Pango fixes for
OpenType and Type 1 fonts. However getting Pango to compile in Mingw was
enough pain to ensure I won't be repeating that experience for sometime.

Behdad, who wrote the patch, does not use Windows. So the patch has not
been tested. However it is a trivial patch and looks correct to me.

[Rygle (rygle)]

Adrian wrote:
>Assuming you are now using the cairo_win32_printing_surface you should be getting all vectors for simple stuff like text/stroke/fill with solid opaque colors. Transparent colors are likely to result in fallback images as they are not supported by GDI.

I am only using the inkscape.logo.svg file, and just putting some simple text, and then printing to a ps file. Very similar to my previous attachments. When I zoom in using GSView I see nice crisp text, but a not so crisp logo. At fit page to screen, you can see tiny irregularities, but if you zoom right in there are clear pixels (see attached). Perhaps Ulf's comment about the test stuff will help clarify.

Ulf Wrote:
>Did you define WIN_PRINT_TEST to use Adrian's test code? (look in print.cpp) You will get two printer dialogs. The second one matters. For me this produces clean vectors.

Ah, hadn't noticed that was commented out in print.cpp. I thought you getting two print dialogs was a mistake with the second last version of the patch and was glad I hadn't finished building it before I saw the latest patch and your comment about two dialogs - I'm currently building with WIN_PRINT_TEST =1 uncommented. Cheers.

Adib: Thanks for the clarification on blur. I'm sure we all understand fully about the office, and the kids, and ..., and... ATM it seems blur is there in ps, but from my one test the alignment is a little off. I'm looking forward to this.

[Rygle (rygle)]

Built now with latest patch from Ulf and WIN_PRINT_TEST=1 in ui/dialog/print.cpp uncommented. (See my last post).

The second dialog gives nice clean vector printing with no boxes, except transparent boxes with black lines appearing across the page - one seems to be about 2cm in all around, and the other is smaller and offset towards top left. The boxes are there whatever I do, text or no text, image or no image - can't even get rid of them even by deleting all content or starting new document, or changing printer driver.

Any thoughts?

[Rygle (rygle)]

Does this from the command line make any sense of this error? No crashes, just this feedback using inkcl.bat

==================
..>inkcl
 x = 4758 y = 6800
dpi x = 600 y = 600
offset x = 100 y = 108
depth = 1
 x = 4758 y = 6800
dpi x = 600 y = 600
offset x = 100 y = 108
depth = 1
 x = 4725 y = 6700
dpi x = 600 y = 600
offset x = 125 y = 192
depth = 1
 x = 9633 y = 13600
dpi x = 1200 y = 1200
offset x = 167 y = 215
depth = 1

** (inkscape.exe:2884): CRITICAL **: SPObject* sp_object_unref(SPObject*, SPObje
ct*): assertion `object != NULL' failed
================

[Ulferikson (ulferikson)]

> The second dialog gives nice clean vector printing with no
> boxes, except transparent boxes with black lines appearing
> across the page - one seems to be about 2cm in all around,
> and the other is smaller and offset towards top left.

That's the test rectangle I used to find the scaling bug:
https://bugs.launchpad.net/inkscape/+bug/179988/comments/82

Just remove the two "draw (cr)" calls.

[Ulferikson (ulferikson)]

Attached is a patch for the 046 release branch. It does not contain the win-print test code. just enough to enable printing

[Rygle (rygle)]

Thanks Ulf for the latest patch, and Adrian for many suggestions and clarifications.

> That's the test rectangle I used to find the scaling bug
Well at least we're on our way to drawing crop marks for 0.47 now! ;^)

But seriously, this latest patch compiles OK for me, but seems to take us back a step .

Can I ask more about the previous patch?
- It seems to call cairo_win32_printing_surface_create() from ui/dialog/print.cpp to print clean vectors with no white blocks. Is that true?
- Was the win-print test code just a workaround that partly bypasses GTK to narrow down whether using the cairo_win32_printing_surface_create() call fixes the issues? That's how it seemed to me.
- Is the latest patch just waiting for the GTK stuff to be sorted, and then you reckon we'll get clean vectors with no white/black blocks?
- If so, what is stopping us just using that code temporarily, even if it's a kludge until the GTK stuff gets properly sorted? I'm guessing this bypasses other stuff, but how important is that? If it's only the look of the dialog, but it's still using Cairo to print nice vectors behind the scenes, does that matter for 0.46.0, and could we fix it properly for 0.46.1?

[Ulferikson (ulferikson)]

Rygle, I think the best choice now is the simplest patch that gives acceptable output. Inkscape 0.46 is already delayed due to windows specific bugs.. ( If you have a chance to also test the patches for bug #187290 that would be great :)

Yes, you could bypass the gtk printer dialog and have better output, but the dialog interacts badly with Inkscape. Try this patch and drag the printer dialog around and see. Fixing this too means adding yet more code that will not be tested enough before release.. (and up til now none of this code has been checked to not break non-windows versions!)

[Adrian Johnson (ajohnson-redneon)]

It would be interesting to see what happens if using the gtkprint dialog you

- get the cairo_surface_t from the cairo_t
  surface = cairo_get_target(cr);

- get the DC from the surface
 dc = cairo_win32_surface_get_dc (surface);

- create a win32_printing surface
  surface2 = cairo_win32_printing_surface_create (dc);
  cr2 = cairo_create (surface2);

call the Inkscape drawing function with cr2

The best solution is to get gtk patched and built to use the printing surface.

[Rygle (rygle)]

Ulf, I understand what you're saying. I am also conscious of the release date. I've had someone express interest in testing the GTK patch on the GTK bug tracker, but I don't know whether that will result in getting our hands on a windows build, and I agree that this will be untested. About these patches breaking non windows versions, isn't it just a matter of carefully making sure that there's always an #ifdef WIN32 before any subroutines added? I can help there. (Yes I am picking up just enough of a sliver of C++ to become at least vaguely useful in this limited fashion).

I think we (well not so much me) have made great strides, and I don't want my hesitance at adopting an 'acceptable output' patch to be confused with being ungrateful. I appreciate that, if nothing else, the many comments on this bug show the huge effort by many people. I am astounded by the great teamwork, in spite of some people like me making inflammatory and somewhat unjustified comments in the heat of the moment (sorry everyone!).

I don't care anywhere near as much about the bitmaps or the blurs to get acceptable output, but the white boxes still bother me as they fundamentally interfere with almost every image. It's a question of what is 'acceptable output'.

I agree with Adrian that the best solution is if we can get a patched GTK that works, which the test seemed to show. But a patched GTK it might break other things. I have also found that the test code crashes on more complex images - I haven't worked hard at narrowing that down, but the test code could be exposing a GTK or Cairo problem (???). Is it better for now for us to revert back to the 0.45.1 printing system for 0.46.0, and work on the GTK common print dialog for 0.46.1?

Currently building with the newest patch now, plus the other patches mentioned too.

[Ulferikson (ulferikson)]

Adrian Johnson:
> It would be interesting to see what happens if using
> the gtkprint dialog you [...]

Works great. Thank you!

Rygle:
> I agree with Adrian that the best solution is if we
> can get a patched GTK that works

The latest suggestion from Adrian means that we get the same results as what a patched GTK would give.

[Rygle (rygle)]

Built with new patches in second last post from Ulf (https://bugs.launchpad.net/inkscape/+bug/179988/comments/99). Will try new patch now, but I can't test until morning. The following is using the patch from https://bugs.launchpad.net/inkscape/+bug/179988/comments/99 .

Here's the error info for printing more complex pic (colour with gradients and many blurs) with the win-print test code.

- The non-GTK print dialogue (like 0.45.1) comes up and I select a PS printer -> to file and enter a filename
- Click OK and an info dialogue pops up

=======
*Microsoft Visual C++ Runtime Library* -> Title of dialogue

Assertion failed!

Program: ...inkscape.exe
File: cairo-win32-printing-surface.c
Line:1253

Expression: _cair_win32_printing_surface_operation_supported (surface, op, source)

For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts

(Press Retry to debug the application - JIT must be enabled)

(Abort) (Retry) (Ignore)
=========

- Click Retry. Get a message from gdb (see contents and bt below. Clicking ignore does exactly the same but without any gdb output and no need to type continue.)
- type continue
- Goes back to similar (but different) Visual C++ error dialog
============
*Microsoft Visual C++ Runtime Library* -> Title of dialogue

Assertion failed!

Program: ...inkscape.exe
File: cairo-paginated-surface.c
Line:359

Expression: status!= CAIRO_INT_STATUS_UNSUPPORTED

For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts

(Press Retry to debug the application - JIT must be enabled)

(Abort) (Retry) (Ignore)
============

- Now get another message from gdb (second below)
- this process continues cycling between the two Visual C++ errors a number of times until after about 12 clicks of retry and typing continue in gdb, it finally prints. Print is a little mangled but is all vector and demonstrating some transparency in bounding boxes of objects so they display without white boxes.
- gdb output for this repeated cycle from the start is as follows;
============
Program received signal SIGTRAP, Trace/breakpoint trap.
0x77c35b62 in msvcrt!_assert () from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0 0x77c35b62 in msvcrt!_assert () from C:\WINDOWS\system32\msvcrt.dll
#1 0x00000002 in ?? ()
#2 0x7c91056d in ntdll!RtlFreeThreadActivationContextStack ()
   from C:\WINDOWS\system32\ntdll.dll
#3 0x0adb0468 in ?? ()
#4 0x68e631e0 in NOT_REACHED.21838 ()
   from D:\Download\Multimedia\Image\Inkscape\compiling\SVN\branches\RELEASE_0_4
6_BRANCH\inkscape\libcairo-2.dll
#5 0x00000016 in ?? ()
#6 0x00000001 in ?? ()
#7 0x00000000 in ?? ()
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x77c35b62 in msvcrt!_assert () from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0 0x77c35b62 in msvcrt!_assert () from C:\WINDOWS\system32\msvcrt.dll
#1 0x00000002 in ?? ()
#2 0x00000000 in ?? ()
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x77c35b62 in msvcrt!_assert () from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0 0x77c35b62 in msvcrt!_assert () from C:\WINDOWS\system32\msvcr...

[Ulferikson (ulferikson)]

Rygle:
> Here's the error info for printing more complex pic (colour with gradients and many blurs)
> with the win-print test code.

Can you please attach one such complex drawing that causes a crash? Or even better, remove half of the objects and check whether you still have a crash. If not, remove the other half and see if you now have a crash. Try get a fairly simple image that still crashes.

> Assertion failed!
> Program: ...inkscape.exe
> File: cairo-win32-printing-surface.c
> Line:1253
> Expression: _cairo_win32_printing_surface_operation_supported (surface, op, source)

This is an assertion. I don't think it has anything with the win-print test code to do. Somehow Inkscape asks cairo to use an operation that is not supported on the win32 printing surface. Hopefully Inkscape does not need to know what operations are supported on each back-end, cairo will simply do the best possible behind the scene (such as using rasterization if needed).

Can you also try save as "Postscript via Cairo" to see what happens? To try the pdf-backend you need to activate it in extensions/init.c (look for a if (0) statement).

[Adrian Johnson (ajohnson-redneon)]

Rygle wrote:
> Built with new patches in second last post from Ulf
> (https://bugs.launchpad.net/inkscape/+bug/179988/comments/99). Will try
> new patch now, but I can't test until morning. The following is using
> the patch from
> https://bugs.launchpad.net/inkscape/+bug/179988/comments/99 .
>
> Here's the error info for printing more complex pic (colour with
> gradients and many blurs) with the win-print test code.
>
> - The non-GTK print dialogue (like 0.45.1) comes up and I select a PS printer -> to file and enter a filename
> - Click OK and an info dialogue pops up
>
> =======
> *Microsoft Visual C++ Runtime Library* -> Title of dialogue
>
> Assertion failed!
>
> Program: ...inkscape.exe
> File: cairo-win32-printing-surface.c
> Line:1253

This means cairo has detected an internal error. ie it is a bug in cairo.

What version of cairo are you using? Printing to PDF and checking the
document properties in Acrobat is one way to find the cairo version.

I would suggest finding the simplest drawing that reproduces the
problem. Hopefully this will give me a clue as to what the problem is.
Ideally if I can reproduce the bug with a C test case that calls a few
cairo drawing functions I can debug it.

[Adrian Johnson (ajohnson-redneon)]

Ulferikson wrote:
> This is an assertion. I don't think it has anything with the win-print
> test code to do. Somehow Inkscape asks cairo to use an operation that is
> not supported on the win32 printing surface. Hopefully Inkscape does not
> need to know what operations are supported on each back-end, cairo will
> simply do the best possible behind the scene (such as using
> rasterization if needed).

All operations are supported by all backends in cairo. If a backend can
not natively handle an operation it will output a rasterized image. The
only time an application needs to care about what operations are
natively supported is when it wants to get all vector output.

[Rygle (rygle)]

Just tested the latest build with the last patch. I'm using the latest dev libs from Ishmal (March 19), which includes Cairo 1.5.12.

Can print a simple inkscape.logo.svg with some text over the top with no problems at all. Perfect vectors and no white blocks. This also saves as PDF via Cairo no problem (with or without text to path).

If I add 1.0 blur to the logo, it prints with the logo blurred, but the scale is too large and consequently it pushes the logo mostly off the page, but the text stays there. No errors.
Saving the same to ps via cairo looks exactly the same - blurred logo too big and offset down to right, mostly off page. The only diff is that the printed version has margins around the edge.
Saving the same to pdf via cairo prints everything normally, except no blur. I think this is not implemented, so this is to be expected.

[Rygle (rygle)]

Don't worry if you don't have the fonts in that last example, since they are not causing any problem, but in case you want them they are just the default sans, cafecoco and mandingo (all free).

Here's the resulting ps file from printing with the blurred logo too large and offset.

[Rygle (rygle)]

If I duplicate the logo and turn one yellow, the PDF is perfect but has no blurs. The ps print or save has one logo not too bad, but the other way too big. It also has some clear problems with fonts as it tries to drop back to bitmap for the blurs. 200dpi for bitmaps seems to do a lot better blurs, but gets more messed up fonts. Sample attached is a screenshot of the ps file as viewed in gsview.

It seems that these problems only occur when blur is used as present.

The next thing I will do is to try to get a minimum test case for the error messages above, but these were for a much more complex image.

[Rygle (rygle)]

Here's what the PDF looks like, which is accurate apart from blurs.

[Rygle (rygle)]

Here's the test case for the error I mentioned a few posts ago (https://bugs.launchpad.net/inkscape/+bug/179988/comments/103)

It seems to be caused by radial gradients. There are two errors (see above), and I can isolate it so that only one occurs if the radial gradient is off page when printing.

Here's the steps;
1. The test document is landscape. Print as portrait (with the radial gradient off page) and you'll get one error - File: cairo-win32-printing-surface.c, Line:1253, Expression: _cair_win32_printing_surface_operation_supported (surface, op, source)

2. print as landscape, with the radial gradient on page, and you'll get both the above and also the second - File: cairo-paginated-surface.c, Line:359, Expression: status!= CAIRO_INT_STATUS_UNSUPPORTED

3. Delete either object and no errors occur.

4. The backtraces are the same as in my previous post.

[Rygle (rygle)]

5. straight gradients don't seem to be a problem at all.

[Rygle (rygle)]

In case you want to see how I came to this, here's the drawing that I wittled down to the test case.

[Adrian Johnson (ajohnson-redneon)]

Rygle wrote:
> Here's the test case for the error I mentioned a few posts ago
> (https://bugs.launchpad.net/inkscape/+bug/179988/comments/103)
>
> It seems to be caused by radial gradients. There are two errors (see
> above), and I can isolate it so that only one occurs if the radial
> gradient is off page when printing.
>
>

I tried some simple C code for drawing a two circles, one with a radial
gradient, and was
unable to reproduce this problem. It looks like I would need to run
Inkscape with your test
file to debug it.

How much work is involved in setting up mingw to compile Inkscape? I
started following the
instructions here:
http://inkscape.modevia.com/win32_inkscape_org/win32buildnotes.html
however the link to the preassembled mingw is not working.

If it is going to take some time to set up, are you interested in making
a zipped up copy of
your Inkscape build environment available for download so I can just
unzip it and start debugging?

Have you tested the patch in comment 102 that includes the workaround to
make the
gtk print dialog use the cairo_win32_printing_surface ?

[Albin Sunnanbo (albin-sunnanbo)]

To compile on Windows the description on http://wiki.inkscape.org/wiki/index.php/Win32Port works good.
Pick latest Mingw and devlib from http://inkscape.modevia.com/win32libs/

[Rygle (rygle)]

Adrian:

This is a simplified version of http://wiki.inkscape.org/wiki/index.php/Win32Port - I've now started using Tortoise, which is much easier.

*Get Mingw and Devlibs*
I'm using the stuff from Ishmal's site;

- Download http://inkscape.modevia.com/win32libs/mingw-4.2.1-071022-dw2.7z and put the contents in c:\mingw - Just to save confusion the folders directly inside are bin, include, lib, libexec, mingw32, share.
- Download http://inkscape.modevia.com/win32libs/devlibs-2.12-080313.7z and put the contents in c:\devlibs - same story, bin, etc directly inside

*Get source*
I'm using TortoiseSVN - http://tortoisesvn.net/downloads - you can use that or download a source snapshot from Ishmal here;
http://inkscape.modevia.com/svn-snap/?C=M;O=D

*Using Tortoise*
Once Tortoise is installed, just make a working folder wherever you want, and do the following;
In explorer, right click and select TortoiseSVN -> Make repository here
Now make another folder in the working folder called 0.46branch or whatever, and go inside that
Right click and select SVN Checkout, then the URL for the version you want, probably https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/branches/RELEASE_0_46_BRANCH/

*Patching*
To patch with Tortoise, simply put the patch inside the src directory, then right click it and select TortoiseSVN -> Apply Patch
When the patch dialogue comes up, it should list the modules to be patched on the left, and you can select to patch all, patch one, or view diffs on any module

To patch using GNU patch command, follow the instructions here;
http://wiki.inkscape.org/wiki/index.php?title=Win32Port&action=edit&section=5

*Building*
Once you've got source, follow the instructions here - you should find them very easy
http://wiki.inkscape.org/wiki/index.php/Win32Port#Building_The_Binary

Steps are;
- set env variables - from shell type mingwenv (enter)
- build btool - ...> g++ buildtool.cpp -o btool
- run btool and sit back for about 60-70 minutes on my PC

[Rygle (rygle)]

Have you tested the patch in comment 102 that includes the workaround to make the gtk print dialog use the cairo_win32_printing_surface?

Yes, all this happens with that patch, and the one before it (comment 99). It seems to happen much less on the later patch, but I'm wondering whether it happens for each object in a page that offends, which would change the number of interations of the error. It always prints anyway, so this is happening as it converts the objects to raster.

By the way, once you've compiled, here's how to use gdb;

enter the compiled inkscape directory
type the following;

..> gdb (enter)
(gdb) file inkscape.exe inkscape.dbg (enter)
(gdb) run {filename optional} (enter)

I always get a segfault to do with xsldebugstatus, but I then type continue (enter) and it always runs OK.

For some reason you can't open files normally from within Inkscape under gdb, so I always have to import them. For the test file you would then have to make sure the radial gradient was off canvas for portrait and then set it up as landscape again. When printing portrait the radial gradient should be off canvas (only one error) and landscape should have both on canvas (both errors).

You can also run Inkscape with the attached script to get stdout errors. Unzip it to the same directory as the executable and type inkcl (enter). This does not work at the same time as gdb, but can open files perfectly normally.

BTW, thanks for crossing platforms to help!!

[Rygle (rygle)]

Actually, page orientation doesn't matter, just as long as both a non-radial-gradient object is also there with the radial gradient, which can be either on or off canvas in the document when printing. On canvas will produce one more error.

[Adrian Johnson (ajohnson-redneon)]

Rygle wrote:
> Actually, page orientation doesn't matter, just as long as both a non-
> radial-gradient object is also there with the radial gradient, which can
> be either on or off canvas in the document when printing. On canvas will
> produce one more error.
>

I'll look at building Inkscape on Windows tomorrow.

Does it make any difference if you remove the stroke from one or both
circles?

Do you have any versions of cairo.dll other than 1.5.12 you can test
with? If it works on an earlier version it will narrow down the source
of the problem. The win32 printing surface was first added in 1.5.2.

[Rygle (rygle)]

If the radial gradient is on canvas, removing the stroke gets rid of the error.

If it is off canvas, you still get one error - the cairo-win32-printing-surface.c line 1253 one.

[Rygle (rygle)]

Just tested with the latest SVN, the patch from comment 102 and the latest patches on #187290 and everything works pretty well for me, but sadly it doesn't fix the radial gradient with stroke thing, so it's not just a simple dll issue. I will try with an earlier lib bundle to see what happens.

Here's where we're at with this (I think)
* Most printing bugs sorted, including white blocks if we use the GTK bypass hack.
* Mostly doing great clean vector prints, with some features falling back to bitmap
* Blurs aren't perfect
* Radial gradients with stroke can cause an error message, which if abort is clicked will crash, but clicking ignore returns OK.
* Printing as bitmap is always perfect, and the dpi can be upped to get the desired output level, just not ideal for sending files to others.

Is this an 'acceptable output', as Ulf put it before?
Is it OK to put this out with the radial gradient crash possibililty? I'm happy to put it out with everything else as is.

The other options really are;
* Patch most things but don't bypass GTK and get white blocks (and I think no radial gradient problem), and hopefully a patched GTK will fix this in the near future.
* Revert to the old print dialog (and fix for 0.46.1).

Any thoughts?

[Rygle (rygle)]

> Do you have any versions of cairo.dll other than 1.5.12 you can test with? If it works on an earlier version it will narrow down the source of the problem. The win32 printing surface was first added in 1.5.2.

Just built with the Feb 26 libraries that have Cairo 1.5.10, but still does exactly the same thing. Will try with the Nov 1 version and see if there's any difference.

[Rygle (rygle)]

Just built with the Nov 1 version of the libs, and that stops with this error;

==========
Make error line 195: problem compiling: src/ui/dialog/print.cpp: In function 'ca
iro_surface_t* _cairo_win32_printing_surface_create(HDC__*)':
src/ui/dialog/print.cpp:65: error: 'cairo_win32_printing_surface_create' was not
 declared in this scope
src/ui/dialog/print.cpp: At global scope:
src/ui/dialog/print.cpp:78: warning: unused parameter 'operation'
src/ui/dialog/print.cpp:78: warning: unused parameter 'page_nr'
src/ui/dialog/print.cpp:173: warning: unused parameter 'operation'
src/ui/dialog/print.cpp:182: warning: unused parameter 'context'
src/ui/dialog/print.cpp:182: warning: unused parameter 'user_data'
==========

That just tells me that cairo_win32_printing_surface_create is not in the version of cairo in that build of the libs. So too early for our purposes. No other dev libs available, so unable to narrow things down further from my end. Sorry.

[Adrian Johnson (ajohnson-redneon)]

Rygle wrote:
> Adrian:
>
> This is a simplified version of
> http://wiki.inkscape.org/wiki/index.php/Win32Port - I've now started
> using Tortoise, which is much easier.
>
>
>
I patched and built Inkscape and reproduced the problem. I think have
fixed the bug in cairo. I've uploaded the dlls for patched version of
cairo here for testing:

http://annarchy.freedesktop.org/~ajohnson/cairo/

You need the pixman dll as well as I compiled it as a separate library
from cairo.

[Rygle (rygle)]

Adrian: Great! The patched cairo seems to have fixed the errors on radial gradients. No errors at all. I don't know how you guys keep doing this, but I hope my testing is helping. Just have to get this patched cairo into the dev libs - I guess the patch would go to Ishmal in the short term, and upstream in the longer term.

I still think there's a bit too much dropping back to bitmap going on, and not all printer drivers allow to adjust the resolution. For instance take the above creation file (https://bugs.launchpad.net/inkscape/+bug/179988/comments/113), ungroup, select all and turn off all blurs, then print - it drops most of the image back to pretty low res bitmap because of the gradients (I believe). But if I save as PDF it prints out perfectly.

Apart from dropping back to bitmap on gradients, the only other thing I can think of to work on is blurs, but unless Adib or others have lots of time I think that will have to wait for 0.46.1. There is always the option to print bitmap, but it just produces huge files, which will probably be slow to print using a parallel cable, but maybe not so bad with usb. I find blurs are sometimes misaligned and sometimes cause black shapes on the PS2 Apple Laserwriter 12/660 that I've got set up as a PS2 print tester (sample of the above creation picture attached). Turning off blurs fixes the black shapes problem. The PS3 HP 4550 doesn't suffer from the black shapes problem.

[Rygle (rygle)]

Any thoughts - is this ready to nominate for release, or are there any issues that need to be sorted?

To summarise where I think it's at;
- blur isn't perfect (mainly alignment). Adib has indicated limited time, so unless he (or someone else) feels very keen, I think this will have to wait for 0.46.1
- gradients cause drop back to bitmap in print, but not in save to PDF via cairo - do we want to fix this? If no then we should nominate for release now.

If I don't hear anything soon I will just nominate for release in the next 8 hours.

Adrian - can you take care of the patched cairo libs? Or does anyone else have wisdom on getting the libs updated? Thanks.

[Rygle (rygle)]

Actually, I think I should nominate this now given the short deadline. The rest will have to wait for 0.46.1.

The latest patch is attached.

There are also some patched cairo libs that stop a crash. See here - http://annarchy.freedesktop.org/~ajohnson/cairo/

[Alvin Penner (apenner)]

    many thanks for a major effort, the win32 world is in your debt...

Thanks,
Alvin Penner

[Rygle (rygle)]

Thanks to a great team who helped with this bug. Rygle.

[Adrian Johnson (ajohnson-redneon)]

Rygle wrote:
> Actually, I think I should nominate this now given the short deadline.
> The rest will have to wait for 0.46.1.
>
> The latest patch is attached.
>
> There are also some patched cairo libs that stop a crash. See here -
> http://annarchy.freedesktop.org/~ajohnson/cairo/
>
> ** Attachment added: "ink_win32.046.print.patch"
> http://launchpadlibrarian.net/12826073/ink_win32.046.print.patch
>

There few things that should be tidied up before this can be committed
to the 0.46 branch.

- I'll push out my cairo patch to the cairo repository in the next few
hours. Then Ishmal can do a cairo build from that. As the current cairo
snapshot (1.4.14) is the release candidate for 1.6.0 I need to do
further testing to make sure I have not broken anything before I push
out this patch.

- The workaround for using win32_printing_surface with gtkprint should
be made more robust. It should be changed to check of the surface
returned by gtkprint is of type CAIRO_SURFACE_TYPE_WIN32 before
substituting it with win32_printing_surface. That way the code will work
correctly if gtkprint returns some other surface like pdf. It will also
ensure that when gtkprint is fixed to use the surface of type
CAIRO_SURFACE_TYPE_WIN32_PRINTING, the workaround will be bypassed.

eg

    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);

The problem with the low resolution fallback should be easily fixed by
changing the fallback resolution. Radial gradients are not supported by
GDI so they will always use fallback images. Linear gradients are only
supported on PostScript level 3 printers. Otherwise they will fallback
as well.

The cairo function for controlling the fallback resolution is:

  cairo_surface_set_fallback_resolution (surface, x_dpi, y_dpi);

It is in the patch but commented out. The default fallback resolution is
300dpi so that should not be causing the problem unless Inkscape is
changing it. The commented out line in the patch sets the fallback dpi
to the printer resolution. However the problem with doing this is with
higher resolutions (600dpi or more) you can easily run out of memory
when doing full page fallbacks. I would generally setting this to
between 150 to 300 dpi. Laser printers generally get a lot less
resolution when printing color than their native resolution due to the
half toning. For example my 600dpi laser prints grayscale at 120dpi.

The other source of low resolution bitmaps is the resolution that
Inkscape prints images at. I am not familiar with the Inkscape code so I
don't know what it is doing with images.

[Adrian Johnson (ajohnson-redneon)]

> As the current cairo snapshot (1.4.14) is the release candidate for 1.6.0

That should have said 1.5.14 is the release candidate for 1.6.0.

[Rygle (rygle)]

Sorry to jump the gun. I just want this to get in for 0.46.0 and I'm not sure when the hard deadline is.

Adrian: Thanks for pushing out the cairo bug fix.

Adrian/Ulf: Can one of you tidy up the gtkprint workaround as per Adrian's comments? Thanks. I am happy to patch and test.

The blur scaling thing now has its own bug - https://bugs.launchpad.net/inkscape/+bug/205732

I have also opened a bug about the discrepancy between the PS and PDF back ends on fall back to bitmap - https://bugs.launchpad.net/inkscape/+bug/205748

[Rygle (rygle)]

Sorry, I jumped the gun - Rygle. Some cleanups still needed as per https://bugs.launchpad.net/inkscape/+bug/179988/comments/130

[Rygle (rygle)]

Just doing a build with the changes suggested for ui/dialog/print.cpp for robustness

Can I also ask. In the print.cpp patch, right at the end, we have this;
=========
+#ifndef WIN32
     gtk_print_operation_set_default_page_setup (_printop, page_setup);
+#endif
=========

Is the #ifndef correct? Or should it be #ifdef? Keep in mind I know very little about C++

If this is wrong, then I suspect it would just work on win32, but it may cause a problem on Linux.

Rygle

[Rygle (rygle)]

Seems to be working well with the robustness #ifdef in ui/dialog/print.cpp

Here's the new patch with that change. This is separate to my last #ifndef question.

[Rygle (rygle)]

The bitmap thing seems to be falling back to a very low dpi. I have attached a ps file from the HP 4550 PS3 that seems to be falling back to about 75dpi. I can't set the resolution in this driver.

With my Lexmark Optra T616 PS3 driver, even if I set it to 1200dpi, it still prints very similar to this.

I have tried going into the Rendering tab, changing that from 75dpi to 300dpi and then back to vector, which seems to keep the value (though grayed out) in the bitmap section. This doesn't seem to help.

I'm wondering where it's getting this 75dpi from for the fallback.

[Adrian Johnson (ajohnson-redneon)]

Rygle wrote:
> The bitmap thing seems to be falling back to a very low dpi. I have
> attached a ps file from the HP 4550 PS3 that seems to be falling back to
> about 75dpi. I can't set the resolution in this driver.

Looking at the patch there are a couple of things you can try:

+ surface = cairo_win32_printing_surface_create (hdc);
+ //cairo_surface_set_fallback_resolution (surface, x_dpi, y_dpi);
+
+ return surface;

Try uncommenting the call to cairo_surface_set_fallback_resolution() and
see what that does. Or try different fallback dpi values. However the
default fallback resolution in cairo is 300dpi so that may not be the
problem.

+
+ // ctx->setPSLevel(CAIRO_PS_LEVEL_3);
+ ctx->setTextToPath(false);
+ ctx->setFilterToBitmap(true);
+ ctx->setBitmapResolution(72);
+

I don't know what the ctx->setBitmapResolution(72) is for but you could
try changing that value or just comment it out in case there was already
a better default set.

[Adrian Johnson (ajohnson-redneon)]

The fix for the cairo assertion failure has been commited to the cairo git repository:

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

If the cairo dlls for inkscape are built by patching 1.5.14 instead of building from git head I recommend also getting the PostScript bug fix as well:

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

[Rygle (rygle)]

Adrian: Thanks for the cairo libs. I've uncommented cairo_surface_set_fallback_resolution (surface, x_dpi, y_dpi) and this improves things a fair bit. The dpi can be set there manually (eg: 1200) to improve things even more, but I think really this needs to be dynamic to allow the printer to set the resolution.

** Can someone please commit this patch to the 0.46 release branch? **

It also hasn't made it into the trunk yet, so that might be a good idea too. I have tested a trunk build and it now prints just the same as the release branch.

[Adrian Johnson (ajohnson-redneon)]

Rygle wrote:
> Adrian: Thanks for the cairo libs. I've uncommented
> cairo_surface_set_fallback_resolution (surface, x_dpi, y_dpi) and this
> improves things a fair bit. The dpi can be set there manually (eg: 1200)
> to improve things even more, but I think really this needs to be dynamic
> to allow the printer to set the resolution.

 From the patch:
> + x_dpi = GetDeviceCaps (hdc, LOGPIXELSX);
> + y_dpi = GetDeviceCaps (hdc, LOGPIXELSY);
> +
> + x_off = GetDeviceCaps (hdc, PHYSICALOFFSETX);
> + y_off = GetDeviceCaps (hdc, PHYSICALOFFSETY);
[...]
> + surface = cairo_win32_printing_surface_create (hdc);
> + //cairo_surface_set_fallback_resolution (surface, x_dpi, y_dpi);

The x_dpi and y_dpi are the printer resolution.

But the problem with doing this is for example you are using a 1200dpi
laser with 8"x11" paper and cairo does a full page fallback due a radial
gradient over the whole page the memory required is:

1200*8*1200*11*4 = 483MB

It is actually double that as cairo needs to create another image to
blend the transparent parts into white. Even if your PC has enough
memory for this you printer will probably choke on it.

And most of this is wasted on laser printers where due to the half
toning a 1200dpi laser could probably only do 240dpi for color images.

So we need find a better way to set the fallback resolution like make it
a user selectable option. For now I would not hard code it any higher
than 300dpi. But if you are seeing obvious differences between 300dpi
and 1200dpi there may be a bug somewhere that is causing a lower value
to be used.

[Bryce Harrington (bryce)]

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

[Rygle (rygle)]

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.

[Rygle (rygle)]

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

[Rygle (rygle)]

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);
========

[Rygle (rygle)]

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

[Rygle (rygle)]

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.

[Rygle (rygle)]

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?

[Adrian Johnson (ajohnson-redneon)]

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);

[Rygle (rygle)]

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.

[Rygle (rygle)]

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?

[Adrian Johnson (ajohnson-redneon)]

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.

[Adrian Johnson (ajohnson-redneon)]

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.

[Adrian Johnson (ajohnson-redneon)]

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.

[Rygle (rygle)]

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).

[Adrian Johnson (ajohnson-redneon)]

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?

[Rygle (rygle)]

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.

[Rygle (rygle)]

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

[Rygle (rygle)]

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.

[Rygle (rygle)]

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

[Rygle (rygle)]

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);
 }
======

[Adrian Johnson (ajohnson-redneon)]

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.

[Rygle (rygle)]

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;
    }
==========

[Rygle (rygle)]

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

[Adrian Johnson (ajohnson-redneon)]

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

[Rygle (rygle)]

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.

[Rygle (rygle)]

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

[Rygle (rygle)]

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

Fixed version attached.

[Rygle (rygle)]

Changing to fix released so Launchpad counts as closed in stats

[Adrian Johnson (ajohnson-redneon)]

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.

[Okko7 (okko7)]

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

[Alvin Penner (apenner)]

- 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

[Adrian Johnson (ajohnson-redneon)]

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.

[Alvin Penner (apenner)]

- 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.

[Adrian Johnson (ajohnson-redneon)]

Patch to fix the print scaling problem.

[Alvin Penner (apenner)]

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.

[Adrian Johnson (ajohnson-redneon)]

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

[theAdib (theadib)]

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.

[Rygle (rygle)]

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

[Rygle (rygle)]

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.

[Alvin Penner (apenner)]

thanks Adrian and Adib !