Le 02/11/2012 04:02, Roger Booth a écrit :
The horizontal positioning of the vertical line between line number and text looks fine, now. I ran several test and the location always looked reasonable.
Great, so those extra margins most probably were the issue, and look wrong anyway :)
A printout of the same page of the same document from V1.22 and the git version shows that the characters in the new version are printed more closely together than in the old version, so even though the line number margin is wider in the new version, each line is shorter, which allows an even greater line length before wrapping than in the old version.
On the other hand, each line is a bit taller in the new version than in the old version. The new version lists 56 lines on page one, the old lists 61 lines. (with a font of monospace, regular, 10).
Well, as said the code is totally different (and less hackish, for what Geany's code is concerned), so I don't expect 1:1 results. With the fixes mentioned in this thread (which I'm gonna commit soon), the output looks sensible enough to be acceptable IMO.
Geany versions 1.22 and before (at least since I started using Geany a year ago or so) drew the vertical line down to the last printed line of the page. So on the last page of the document, if the last line of the document wound up in the middle of the page, the vertical line extended down to the middle of the page.
In the current git version, on the last page, the vertical line always extends to near the bottom of the page. Print out a document with only 22 lines total, and the vertical line goes to near the bottom of the page.
Yeah, that's suboptimal. To do that right, one gotta know the height Scintilla *actually* drew on, which unfortunately isn't that easy I think. The easier solution would probably be Scintilla to support drawing this line. Anyway, if you have an idea how to accurately determine the end position of the line, I'm all hears and would be happy to review a patch.
One unrelated nit I found is if you set the font size above 22 or so (probably depends on digits in current page number, total pages, L10n date format), the page number and date in the heading collide. Not sure if anyone cares about that one.
I don't care because IMO if you encounter the issue, you'll anyway have so few character per lines it doesn't make sense for code output.
Another 'does anyone care' - if you choose to Print Preview page 3 of a one-page document, nothing happens. No diagnostic, nothing.
That might be more useful to fix, although I don't thing it's the bigger issue ever. And without having investigated this at all, I don't even know whether we'll know it, because as explained below, we tell GTK how many pages our document has and it tells us which page we should print; so maybe we'll never know the user wanted to print page 3.
While I'm at it, if you select to print a few pages of, say, a 12 page document using exactly
3 5 7
Print Preview shows only page 3, without explaining why no 5 or 7. That happened to me a few months ago, then I stumbled on the tooltip.
This is a GTK problem of it not telling the user it doesn't understand space-separated page ranges, we can't do much about it in our side, we don't get the user input. Just report that to the GTK guys.
But it didn't matter, since Geany (before this version) printed page 1 and labeled it page 3. By the way, I have tested printing, in a 13-page document, the following
3,13,7
The pages matched exactly (far as I could tell) the same pages from a previous complete printout (both printed using the git version with patches).
That's good, but not really a surprise since now we paginate properly, whatever being the range we gotta print. Actually, we get notified that we should paginate, and later on, repeatedly that that we should print page N. We don't really know whether we're printing everything or only a single page, so this shouldn't change anything :)
Regards, Colomban