Comment 74 for bug 179988

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: 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itransform translate
*****

***** logo300dpi.ps
  447: %%EndFont
  448: 0.973 0.414[31.996 0 0 -31.996 0 0]/Bitstream_Vera_Sans32320 MF
  449: 25 92 M
***** LOGO1200DPI.PS
  447: %%EndFont
  448: 3.895 0.414[32.031 0 0 -32.031 0 0]/Bitstream_Vera_Sans32320 MF
  449: 25 92 M
*****

***** logo300dpi.ps
  557: %%EndFont
  558: 0.973 0.414[31.996 0 0 -31.996 0 0]/Boulevard32320 MF
  559: 39 163 M
***** LOGO1200DPI.PS
  557: %%EndFont
  558: 3.895 0.414[32.031 0 0 -32.031 0 0]/Boulevard32320 MF
  559: 39 163 M
*****

The main data/image portion of the ps file stays the same, but just a few minor dpi setting differences mainly. In other words, there's an embedded bitmap that is just getting blown up bigger at the printer end based on the dpi setting, without actually changing the bitmap. Note this is on a vector print.

Ulferikson, your patch for page size seems to do something like what Adrian was talking about https://bugs.launchpad.net/inkscape/+bug/179988/comments/47, but it seems to me that this could be taken one step further to make the print job the right size. 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?

* Some Niggling Issues/Questions:
 - Why do vector prints largely contain raster images, when saving as PS is perfect vector content?
 - Why does printing to PS (print to file) keep the white boxes, but saving as PS is absolutely perfect vector content?