Hi all,
I tried Cairo-1.5.14 out today and it works fine. One small problem, though. It breaks Cairomm. If you try compiling with it, you will encounter the error:
'CAIRO_FONT_TYPE_ATSUI_replaced_by_CAIRO_FONT_TYPE_QUARTZ' was not declared in this scope
This is because 1.5.14 has a small API change, using the QUARTZ names now instead of ATSUI.
Cairomm does not have that change yet, even the version on their server. If you still want to try Cairo-1.5.14, just change line 195 in cairomm/enums.h from: FONT_TYPE_ATSUI = CAIRO_FONT_TYPE_ATSUI to FONT_TYPE_ATSUI = CAIRO_FONT_TYPE_QUARTZ
Happy hacking.
bob
Hi Bob,
Nice to hear fro y
Hopefully you know about Adrian's patch for GTK 1.5.14 and radial gradients, plus his comments about building and another PS patch.
See https://bugs.launchpad.net/inkscape/+bug/179988/comments/138
Hi
You will know about Adrian's bug fix for radial gradients. This requires a new cairo dll for the release.
I am currently using Adrian's build of libcairo-2.dll and libpixman-1.dll over the top of the March 13 libs and I have had no problems with them with printing. See http://annarchy.freedesktop.org/~ajohnson/cairo/ And also https://bugs.launchpad.net/inkscape/+bug/179988/comments/138
Adrian has also committed another bug fix in cairo's git repository for scaling of images. See Bug 179988 When printing, anything not able to be expressed in postscript falls back to bitmap, and cairo was using the actual dpi/72 for some reason, making the fallback bitmaps really pixelated.
Adrian has committed a patch to Cairo here - http://gitweb.freedesktop.org/?p=cairo;a=commit;h=e9906ae2021904c8c3d3a40837...
But we can also patch it in src\ui\dialog\print.cpp by changing the following line, which currently reads the dpi from the print surface;
cairo_surface_set_fallback_resolution (surface, x_dpi, y_dpi);
to a fallback of 300dpi by saying the following
cairo_surface_set_fallback_resolution (surface, (x_dpi/72.0) * 300,(y_dpi/72.0) * 300);
Adrian also says;
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 than it should be.
Ultimately it would be best to have no patches in our code, and to get rid of the fallback line altogether, because the default fallback dpi is 300, which prints well.
Can you tell me which way you would like to go - build new libs or incorporate patch and patched libs? And a rough time frame if building new libs?
participants (2)
-
Bob Jamison
-
rygle