Downscaled print output on recent 0.46-devel Windows builds (since 11/08)

[atarian]

From beginning of November, all print output is downscaled by 8,33333... factor. Verified of several printers, including network and virtual.
Platform: Windows XP, Vista (32bit)
Inkscape version: recent 0.46-devel builds, currently 20225 from Nov. 19, 2008
Steps to repro: Install recent dev build on Windows platform. Create any drawing and print it usin any available printer. Note disproportion between original size and print out.
Please reffer to attachements (original file plus PDF output created by Bullzip PDF virtual printer) to see the issue.

[Docsonic (sysadmin-macfarlands)]

I also see this problem, current build 20552, but I wasn't aware of the precise scale factor.

[Alvin Penner (apenner)]

is this a continuation of Bug 179988 ?
see comment at :
https://bugs.launchpad.net/inkscape/+bug/179988/comments/172

[Jewel (ejewel)]

I am currently trying to solve this bug. I have the following additional information:

It still happens in the latest nightly, from 2009-03-23.

It happens if I check out the RELEASE_0_46_0 tag and compile using the latest devlibs from svn.

It doesn't happen if I use the 0.46 release tag and an old version of the devlibs: http://inkscape.modevia.com/win32libs/devlibs-2.12-080408.7z.

It doesn't happen when exporting to PDF in any version.

It doesn't happen in the svn version when compiled on Ubuntu 8.10.

[Alvin Penner (apenner)]

I think the relevant comment was made at :
https://bugs.launchpad.net/inkscape/+bug/179988/comments/169

this change in GTK+ was made around Sept 5, 2008

[Jewel (ejewel)]

I tried doing what is suggested in bug 179988 comment 172 but ran into some difficulties. I am new to cairo, inkscape hacking, etc, but my current understanding of the problem goes something like this:

1. GTK makes a cairo context for the printer.
2. Inkscape takes the surface from that context and passes it to its cairo renderer (ui/dialog/print.cpp).
3. The cairo renderer creates its own context.
4. The surface is assigned to the new context.

During this process, GTK's context information is lost.

Would it work to pass the GTK's context straight into the renderer instead of just passing the surface?

In the meanwhile, attached is a ghetto workaround that just multiplies the cairo scale by 8.3333.

[Jewel (ejewel)]

Although I am fairly certain I tried RELEASE_0_46_0 with the win32-printing patch (packaging/win32/patches) I must have been mistaken. After applying that patch to a fresh RELEASE_0_46_0 checkout printing worked as expected with the newer devlibs. Sorry for the confusion.

[Alvin Penner (apenner)]

I believe this was resolved in svn rev 21212, as discussed in Bug 179988.
could you try this with a recent build and see if the problem is fixed?

[su_v (suv-lp)]

Can this be confirmed as 'Fix released' with recent prerelease builds?

a patch was committed in rev. 21212 - see bug #179988 comment #177
<https://bugs.edge.launchpad.net/inkscape/+bug/179988/comments/177>

[su_v (suv-lp)]

@Alvin - sorry, didn't realize you already asked the same question!

[jazzynico (jazzynico)]

Closing fix released. Don't hesitate to reopen the report if you run into the same issue again with a recent Inkscape version.