GNOME Bugzilla – Bug 377795
Absolute size of layouts depends on target resolution
Last modified: 2007-04-02 20:42:06 UTC
See attached test case. It simply prints as many lines as it can to one page; or it can produce pdf with the same stuff. On win32, I get different number of lines with a printer and in pdf. This is caused somehow by different resolution - printer has 600 or 1200 dpi, pdf uses 72 dpi, I tried to scale to compensate resolution, and it seemed working. This thing makes it pretty impossible to implement WYSIWYG (meaning number of pages and lines of text on those are the same) print preview. Filing under pango to get Behdad attention on this; I have no idea whose bug this really is.
Created attachment 76973 [details] test case A demo program. By default it invokes Print dialog; "test --pdf file.pdf" makes pdf; and "test --preview" shows preview.
Created attachment 76974 [details] Win32 binary Win32 binary of the test case, built with gtk-2.10.
Does this only happen with win32, or is it a dupe of bug 392475?
(In reply to comment #3) > Does this only happen with win32, or is it a dupe of bug 392475? > I have no idea if it happens on unix, because I have no idea how I can get that high resolution on unix. PDF uses 72 dpi which is almost the same as screen resolution. I guess one could test this with some real printer which has at least 300 dpi resolution, but all I have is some win-only Canon. It does look like #392475 is a duplicate of this one, dunno.
(In reply to comment #3) > Does this only happen with win32, or is it a dupe of bug 392475? Doesn't sound like it was a duplicate. From an IRC discussion, it sounds like muntyan is using tml's builds of cairo for win32 which do not include cairo's freetype backend. -Carl
Created attachment 84456 [details] test case I used for bug 392475 Please run this and attach the output.
Created attachment 84462 [details] behdad's test case output
The results are impressively consistent: minw 8.328835 maxw 8.330078 error 0.0149228% I don't see a Pango bug here.
and more importantly, no cairo bug.
I'd think it only means that this one isn't a duplicate of #392475, and the problem is elsewhere. Is it possible to create two cairo surfaces with different resolution to test? Perhaps it's gtk printing bug, but how to determine if it's so?
(In reply to comment #10) > I'd think it only means that this one isn't a duplicate of #392475, and the > problem is elsewhere. Is it possible to create two cairo surfaces with > different resolution to test? Perhaps it's gtk printing bug, but how to > determine if it's so? Did you see that Behdad's test runs the output resolution from 10 to 200 DPI? -Carl
(In reply to comment #11) > (In reply to comment #10) > > I'd think it only means that this one isn't a duplicate of #392475, and the > > problem is elsewhere. Is it possible to create two cairo surfaces with > > different resolution to test? Perhaps it's gtk printing bug, but how to > > determine if it's so? > > Did you see that Behdad's test runs the output resolution from 10 to 200 DPI? I did, I also tried 6000 with the same result. But does it mean that some cairo_get_something_for_something() which is called by gtk printing code isn't buggy? Or pango_cairo_create_layout() or similar? I have no idea where the bug is, but I am sure you can't conclude it's not cairo/pango bug just from that test case. You know, that bug shouldn't have existed if everything were fine and nice as it is in theory ;) There is of course a possibility that I am talking bullshit; if you say that my test case shows a bug which is neither cairo nor pango for some other reason, then I'll surely accept that.
FWIW, pango_context_get_resolution() returns -1 for context returned from gtk_print_context_create_pango_context(), i.e. the context which is used to draw onto printer surface. If we do want to set resolution on it, what value should be given to set_resolution() if we have N dpi? Is it N/96 or N/96*72 or something? And what if dpi_x is not equal to dpi_y? (I don't think I've seen it different in printing, but the printing api gets two resolutions - x and y)
Created attachment 84468 [details] test case Attached is the test case which reproduces printing problem: if we set resolution on fontmap, we get different sizes. The output (with sinpped middle stuff): 72 ; 914.7 ; 213.3 84 ; 914.7 ; 195.0 96 ; 914.7 ; 202.7 108 ; 914.7 ; 189.6 120 ; 914.7 ; 187.7 132 ; 914.7 ; 193.9 144 ; 914.7 ; 192.0 156 ; 914.7 ; 190.4 168 ; 914.7 ; 201.1 180 ; 914.7 ; 193.4 192 ; 914.7 ; 192.0 204 ; 914.7 ; 195.8 216 ; 914.7 ; 194.4 228 ; 914.7 ; 193.1 240 ; 914.7 ; 196.3 252 ; 914.7 ; 195.0 264 ; 914.7 ; 197.8 276 ; 914.7 ; 196.6 288 ; 914.7 ; 195.6 300 ; 914.7 ; 194.6 312 ; 914.7 ; 196.9 324 ; 914.7 ; 192.8 336 ; 914.7 ; 195.0 348 ; 914.7 ; 197.1 360 ; 914.7 ; 193.4 372 ; 914.7 ; 192.7 384 ; 914.7 ; 194.7 396 ; 914.7 ; 193.9 408 ; 914.7 ; 193.3 420 ; 914.7 ; 195.0 432 ; 914.7 ; 192.0 444 ; 914.7 ; 193.7 456 ; 914.7 ; 193.1 468 ; 914.7 ; 194.7 480 ; 914.7 ; 192.0 492 ; 914.7 ; 195.6 504 ; 914.7 ; 193.0 516 ; 914.7 ; 194.5 528 ; 914.7 ; 193.9 540 ; 914.7 ; 195.3 552 ; 914.7 ; 192.9 564 ; 914.7 ; 194.3 576 ; 914.7 ; 193.8 588 ; 914.7 ; 193.3 600 ; 914.7 ; 194.6 612 ; 914.7 ; 194.1 624 ; 914.7 ; 193.6 636 ; 914.7 ; 194.8 648 ; 914.7 ; 194.4 660 ; 914.7 ; 193.9 672 ; 914.7 ; 193.5 684 ; 914.7 ; 194.6 696 ; 914.7 ; 192.7 708 ; 914.7 ; 192.4 720 ; 914.7 ; 193.4 732 ; 914.7 ; 193.0 744 ; 914.7 ; 192.7 756 ; 914.7 ; 193.7 768 ; 914.7 ; 193.3 780 ; 914.7 ; 193.0 792 ; 914.7 ; 193.9 804 ; 914.7 ; 193.6 816 ; 914.7 ; 193.3 828 ; 914.7 ; 192.9 840 ; 914.7 ; 193.8 852 ; 914.7 ; 192.3 864 ; 914.7 ; 194.4 876 ; 914.7 ; 192.9 888 ; 914.7 ; 193.7 900 ; 914.7 ; 193.4 912 ; 914.7 ; 192.0 924 ; 914.7 ; 190.6 936 ; 914.7 ; 192.5 948 ; 914.7 ; 191.2 960 ; 914.7 ; 190.9 972 ; 914.7 ; 191.7 984 ; 914.7 ; 191.5 996 ; 914.7 ; 191.2 1008 ; 914.7 ; 192.0 1020 ; 914.7 ; 191.7 1032 ; 914.7 ; 189.5 1044 ; 914.7 ; 191.3 1056 ; 914.7 ; 190.1 1068 ; 914.7 ; 190.8 1080 ; 914.7 ; 190.6 1092 ; 914.7 ; 191.3 1104 ; 914.7 ; 190.1 1116 ; 914.7 ; 190.9 1128 ; 914.7 ; 190.6 1140 ; 914.7 ; 190.4 1152 ; 914.7 ; 191.1 1164 ; 914.7 ; 190.9 1176 ; 914.7 ; 191.6 1188 ; 914.7 ; 191.4 1200 ; 914.7 ; 192.0
(In reply to comment #13) > FWIW, pango_context_get_resolution() returns -1 for context returned from > gtk_print_context_create_pango_context(), i.e. the context which is used to > draw onto printer surface. Ok, this means that it sets resolution on the fontmap. I don't know why it does that though. I checked the code and this is in fact true. Filed bug 417707. So, that's one thing to fix. The other is to see why you are getting the results you get. This is a pangowin32 issue. It's kinda weird though, because apparently the resolution is effective. Just that font options seem to be messed now. CCing Tor for investigation.
(In reply to comment #8) > The results are impressively consistent: > > minw 8.328835 maxw 8.330078 error 0.0149228% > > I don't see a Pango bug here. My fault. The width is fine. The heights are varying. This seems to be a bug in cairo's win32 font backend, returning hinted font metrics all the time. Following up in cairoland.
Isn't this fixed with cairo 1.4.2?
There was a patch, which did fix the bug; and there is appropriate ChangeLog entry in cairo, but I haven't had chance to test the cairo release yet. Will reopen if bug isn't fixed.