Le 01/11/2012 15:41, Roger Booth a écrit :
On 11/01/2012 06:13 AM, Colomban Wendling wrote:
Well well… I have less and less ideas, but what if you comment out lines 312-323 (after patching)? I copied this logic from SciTE, but I'm not sure it's correct, maybe this should not be included and is only useful when dealing directly with the page setup and paper size.
That worked! At least, one page of my test document printed 56 lines both Print Preview and hardcopy.
Great! Maybe we finally found the problem :)
I'll do more testing tomorrow, but its looking good.
Thanks, looking forward to it so I can commit the fixes if that shows correct results :)
The vertical line is still too long by about one line, but that's a nit. I'd be happy with printouts like this.
Since you copied the logic from SciTE, perhaps this has uncovered a bug in SciTE? That would explain why I thought the problem was in Scintilla code. My read is that the now-commented code is adjusting for printer limitations - printer can't print too close to the edges. Maybe the commented logic you copied from SciTE removes it once, and the Scintilla logic removes it again? Just speculating.
I doubt Scintilla does any resizing of the area itself, it has the same logic on all platforms and it expects the caller to give it the area to draw on, with proper margin set. But when I look at the GTK API, I don't see why I would need to manually remove the printer hard margins from the area the print context gives me: not only the context should be setup correctly, but also the hard margins of the printer are relative to the *page*, not the area where to print (e.g. including user margins).
I think it's only that the person who wrote the SciTE code wrongly assumed those margins were needed, and I copied that. There is nothing in SciTE VCS history that tells why this margins are added, they are there since the very first time SciTE got GTK printing code.
So if those margins should actually not be added, SciTE would need to get fixed too.
Regards, Colomban