I have been investigating Geany's problems with printing.
I looked at * Geany 1.22 * Geany - the current git (as of a few days ago when I started this) * Geany 1.23 (git >= 8855c14), en_US.UTF-8 * SciTE 3.1.0
Geany 1.22 - problems * When counting pages, tabs are not expanded, giving inaccurate results - #3475444 * Printing code mishandles non-monospaced fonts - #2804000 * When printing, tabs are expanded to fixed width, not to the next tab stop - #2629121. * When user requests to print a specified page, page 1 is printed and labeled the requested page. For example, if the user selects to print page 7 only, Geany will print page 1, but in the heading, the text will read "Page 7 of xx". I didn't submit this as a developer bug, since it is fixed in the current version.
Geany -- the current git - problems * Print Preview displays a different number of lines than hard-copy - #3580269. * The line separating line numbers from text when printing is positioned incorrectly - #3580268. * Printed lines are right-shifted compared to previous Geany versions, causing wrapping which did not occur in previous Geany versions.
SciTE problems * Print Preview displays a different number of lines than hard-copy.
The git version of Geany contains a new version of the printing code. This new version uses the printing code contained within Scintilla.
The Scintilla printing code does not draw a vertical line between the line number and the text. So the git version of Geany attempts to draw that line. However, Scintilla provides no method of determining the width of the line number column (SSM(SCI_GETMARGINWIDTHN) returns the display margin width, not the printer margin width). So the Geany code attempts to mimic the calculations Scintilla performs to come up with the column width. The attempt fails, thus bug #3580268.
The Scintilla printing code adds three spaces between line number and text. This shifts the text right, and lines which were nearly page width when printed using the previous versions of Geany now wrap.
As a quick check whether the lines per page mismatch between Print Preview and hard copy is in Geany's code or Scintilla's, I tested SciTE. SciTE has the same problem.
Using the git version of Geany, I printed page 1 of a particular test document, Print Preview listed the document as 18 pages long with 51 lines on the first page (4 lines wrapped) and the hardcopy listed it as 19 pages long with 45 lines on the first page (8 lines wrapped).
Printing the same test with SciTE, Print Preview listed 55 lines on page 1 with 3 lines wrapped, and hardcopy listed 44 lines with 7 lines wrapped. (SciTE's output does not show the number of pages in the document).
I have investigated the problems with the old (1.22 and before) printer code, and I believe all can be addressed by modifying the original code, with the exception of Printing code mishandles non-monospaced fonts - #2804000
I fixed the bug "When printing, tabs are expanded to fixed width, not to the next tab stop - #2629121" locally a few weeks ago. That was why I joined the developers group. I wanted to submit that patch.
I have not noticed any discrepancy between Print Preview and hardcopy with the (tab expansion patched) old code. And the old code naturally knows the correct location for the vertical line.
When determining the number of pages in the code, the old code currently determines the length of each line by multiplying the width of one character by the number of characters in the line. That is correct as far as UTF8 is concerned -- it uses a UTF-aware function to determine number of characters. But it fails to take into consideration the expansion of tabs.
To fix this problem in the old code, one could replace the page counting code. Take the lines of code that actually do the printing, put those lines into a separate function, and call that function twice. First time, the function would calculate the layout (and thus the number of pages) but not actually print. Second time, it prints. If only certain pages are requested, second time it skips lines til a requested page's first line, then prints the page, then skips lines til the next requested page, etc.
Once tabs are expanded correctly, this change seems to fix all the issues except non-monospaced fonts.
An option to deal with that could be to use the new code only for non-monospaced fonts. For monospaced fonts, use the old code. For non-monospaced fonts, the issue of Print Preview not matching hardcopy would remain, but IMO that is a Scintilla bug, and depends on that group for a fix.
Hi Roger,
A couple of comments.
1. It is unlikely that the old non-Scintilla printing code will be returned to Geany. Sorry that you made changes to it before you were aware of the change to Scintilla printing. It would be definitely best to keep up to date with the current Git if you are making changes, since they will need to be merged into it.
2. Those problems that you found can be reproduced on Scite should be reported to the Scintilla project. (www.scintilla.org)
Cheers Lex
On 31 October 2012 16:36, Roger Booth rbooth@kabooth.com wrote:
I have been investigating Geany's problems with printing.
I looked at
- Geany 1.22
- Geany - the current git (as of a few days ago when I started this)
- Geany 1.23 (git >= 8855c14), en_US.UTF-8
- SciTE 3.1.0
Geany 1.22 - problems
- When counting pages, tabs are not expanded, giving inaccurate results -
#3475444
- Printing code mishandles non-monospaced fonts - #2804000
- When printing, tabs are expanded to fixed width, not to the next tab stop
- #2629121.
- When user requests to print a specified page, page 1 is printed and
labeled the requested page. For example, if the user selects to print page 7 only, Geany will print page 1, but in the heading, the text will read “Page 7 of xx”. I didn't submit this as a developer bug, since it is fixed in the current version.
Geany – the current git - problems
- Print Preview displays a different number of lines than hard-copy -
#3580269.
- The line separating line numbers from text when printing is positioned
incorrectly - #3580268.
- Printed lines are right-shifted compared to previous Geany versions,
causing wrapping which did not occur in previous Geany versions.
SciTE problems
- Print Preview displays a different number of lines than hard-copy.
The git version of Geany contains a new version of the printing code. This new version uses the printing code contained within Scintilla.
The Scintilla printing code does not draw a vertical line between the line number and the text. So the git version of Geany attempts to draw that line. However, Scintilla provides no method of determining the width of the line number column (SSM(SCI_GETMARGINWIDTHN) returns the display margin width, not the printer margin width). So the Geany code attempts to mimic the calculations Scintilla performs to come up with the column width. The attempt fails, thus bug #3580268.
The Scintilla printing code adds three spaces between line number and text. This shifts the text right, and lines which were nearly page width when printed using the previous versions of Geany now wrap.
As a quick check whether the lines per page mismatch between Print Preview and hard copy is in Geany's code or Scintilla's, I tested SciTE. SciTE has the same problem.
Using the git version of Geany, I printed page 1 of a particular test document, Print Preview listed the document as 18 pages long with 51 lines on the first page (4 lines wrapped) and the hardcopy listed it as 19 pages long with 45 lines on the first page (8 lines wrapped).
Printing the same test with SciTE, Print Preview listed 55 lines on page 1 with 3 lines wrapped, and hardcopy listed 44 lines with 7 lines wrapped. (SciTE's output does not show the number of pages in the document).
I have investigated the problems with the old (1.22 and before) printer code, and I believe all can be addressed by modifying the original code, with the exception of Printing code mishandles non-monospaced fonts - #2804000
I fixed the bug “When printing, tabs are expanded to fixed width, not to the next tab stop - #2629121” locally a few weeks ago. That was why I joined the developers group. I wanted to submit that patch.
I have not noticed any discrepancy between Print Preview and hardcopy with the (tab expansion patched) old code. And the old code naturally knows the correct location for the vertical line.
When determining the number of pages in the code, the old code currently determines the length of each line by multiplying the width of one character by the number of characters in the line. That is correct as far as UTF8 is concerned – it uses a UTF-aware function to determine number of characters. But it fails to take into consideration the expansion of tabs.
To fix this problem in the old code, one could replace the page counting code. Take the lines of code that actually do the printing, put those lines into a separate function, and call that function twice. First time, the function would calculate the layout (and thus the number of pages) but not actually print. Second time, it prints. If only certain pages are requested, second time it skips lines til a requested page's first line, then prints the page, then skips lines til the next requested page, etc.
Once tabs are expanded correctly, this change seems to fix all the issues except non-monospaced fonts.
An option to deal with that could be to use the new code only for non-monospaced fonts. For monospaced fonts, use the old code. For non-monospaced fonts, the issue of Print Preview not matching hardcopy would remain, but IMO that is a Scintilla bug, and depends on that group for a fix.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Hi,
Le 31/10/2012 06:58, Lex Trotman a écrit :
Hi Roger,
A couple of comments.
- It is unlikely that the old non-Scintilla printing code will be
returned to Geany. Sorry that you made changes to it before you were aware of the change to Scintilla printing. It would be definitely best to keep up to date with the current Git if you are making changes, since they will need to be merged into it.
I agree with Lex here. The old code was extremely complex and tried to mimic Scintilla display, while failing to deal with many things (counting wrapped lines, paginating the output, and probably others I don't remember).
I think that if you want to give the printing some love, you should rather work together with Scintilla to get it do what you (we) want. For example, Scintilla could have an API to chose between whitespace between line numbers and code, or the line we want.
- Those problems that you found can be reproduced on Scite should be
reported to the Scintilla project. (www.scintilla.org)
Cheers Lex
On 31 October 2012 16:36, Roger Booth rbooth@kabooth.com wrote:
I have been investigating Geany's problems with printing.
I looked at
- Geany 1.22
- Geany - the current git (as of a few days ago when I started this)
- Geany 1.23 (git >= 8855c14), en_US.UTF-8
- SciTE 3.1.0
Geany 1.22 - problems
- When counting pages, tabs are not expanded, giving inaccurate results -
#3475444
- Printing code mishandles non-monospaced fonts - #2804000
- When printing, tabs are expanded to fixed width, not to the next tab stop
- #2629121.
- When user requests to print a specified page, page 1 is printed and
labeled the requested page. For example, if the user selects to print page 7 only, Geany will print page 1, but in the heading, the text will read “Page 7 of xx”. I didn't submit this as a developer bug, since it is fixed in the current version.
Those issues are the reason I spend some effort switching to the Scintilla printing support. Especially the pagination issue was quite hard to fix because the layout and display code were merged together, so it was nearly impossible to just layout without actually render (and we need that to layout the pages that won't be printed in order to get the line offset at which start to print).
Moreover, the old code had sever issues when wrapping the last line on the page.
Geany – the current git - problems
- Print Preview displays a different number of lines than hard-copy -
#3580269.
- The line separating line numbers from text when printing is positioned
incorrectly - #3580268.
I'm not sure, but I suspect this might be because of the "magnification" setting from scintilla. You noted I added a quite clear comment next to that call, showing I have roughly no idea why -2 gives good results. To get this right, either the fixes has to go in Scintilla, or we need to understand exactly what that magnification is, so what to reproduce.
- Printed lines are right-shifted compared to previous Geany versions,
causing wrapping which did not occur in previous Geany versions.
As you noted, it's Scintilla that adds whitespace to separate line numbers from code, but we prefer a vertical line.
SciTE problems
- Print Preview displays a different number of lines than hard-copy.
So this one is not specific to our printing code, and both Geany and SciTE would benefit from a fix. Or maybe it's just I took some SciTE code as an example, e.g. for the setup_range() function.
Unfortunately I don't currently have a real printer to test with, so I only tested with PDF and preview output; I didn't suspect that real copy could look different.
The git version of Geany contains a new version of the printing code. This new version uses the printing code contained within Scintilla.
The Scintilla printing code does not draw a vertical line between the line number and the text. So the git version of Geany attempts to draw that line. However, Scintilla provides no method of determining the width of the line number column (SSM(SCI_GETMARGINWIDTHN) returns the display margin width, not the printer margin width). So the Geany code attempts to mimic the calculations Scintilla performs to come up with the column width. The attempt fails, thus bug #3580268.
I know. I first tried, as you suggest, to use GETMARGINWITH, but as you saw, without any success unfortunately.
The Scintilla printing code adds three spaces between line number and text. This shifts the text right, and lines which were nearly page width when printed using the previous versions of Geany now wrap.
Yes, and I agree this is unwanted since we have our less space-wasting vertical line separator.
As a quick check whether the lines per page mismatch between Print Preview and hard copy is in Geany's code or Scintilla's, I tested SciTE. SciTE has the same problem.
Using the git version of Geany, I printed page 1 of a particular test document, Print Preview listed the document as 18 pages long with 51 lines on the first page (4 lines wrapped) and the hardcopy listed it as 19 pages long with 45 lines on the first page (8 lines wrapped).
Printing the same test with SciTE, Print Preview listed 55 lines on page 1 with 3 lines wrapped, and hardcopy listed 44 lines with 7 lines wrapped. (SciTE's output does not show the number of pages in the document).
That difference of lines between Geany and SciTE is probably due to our header and footer I guess.
I have investigated the problems with the old (1.22 and before) printer code, and I believe all can be addressed by modifying the original code, with the exception of Printing code mishandles non-monospaced fonts - #2804000
I fixed the bug “When printing, tabs are expanded to fixed width, not to the next tab stop - #2629121” locally a few weeks ago. That was why I joined the developers group. I wanted to submit that patch.
I have not noticed any discrepancy between Print Preview and hardcopy with the (tab expansion patched) old code. And the old code naturally knows the correct location for the vertical line.
When determining the number of pages in the code, the old code currently determines the length of each line by multiplying the width of one character by the number of characters in the line. That is correct as far as UTF8 is concerned – it uses a UTF-aware function to determine number of characters. But it fails to take into consideration the expansion of tabs.
To fix this problem in the old code, one could replace the page counting code. Take the lines of code that actually do the printing, put those lines into a separate function, and call that function twice. First time, the function would calculate the layout (and thus the number of pages) but not actually print. Second time, it prints. If only certain pages are requested, second time it skips lines til a requested page's first line, then prints the page, then skips lines til the next requested page, etc.
That'd be a bunch of work, and beware: the code must deal with wrapped lines spanning between pages. E.g. if last line of page 1 wraps, its end must appears on page 2, no matter whether page 1 was actually printed or not.
Once tabs are expanded correctly, this change seems to fix all the issues except non-monospaced fonts.
An option to deal with that could be to use the new code only for non-monospaced fonts. For monospaced fonts, use the old code. For non-monospaced fonts, the issue of Print Preview not matching hardcopy would remain, but IMO that is a Scintilla bug, and depends on that group for a fix.
I don't like the old code since it isn't really clever and tries to replicates something that is already there and better done: Scintilla. And I like even less the idea of having two code paths for one thing.
So, I'm sorry you spent some effort on the old, now removed, code but I don't think bringing it back is the solution. I think the new code should rather be fixed, and Scintilla too if that's needed.
Best regards, Colomban
Le 31/10/2012 15:03, Colomban Wendling a écrit :
On 31 October 2012 16:36, Roger Booth rbooth@kabooth.com wrote:
Geany – the current git - problems
- Print Preview displays a different number of lines than hard-copy -
#3580269.
- The line separating line numbers from text when printing is positioned
incorrectly - #3580268.
I'm not sure, but I suspect this might be because of the "magnification" setting from scintilla. You noted I added a quite clear comment next to that call, showing I have roughly no idea why -2 gives good results. To get this right, either the fixes has to go in Scintilla, or we need to understand exactly what that magnification is, so what to reproduce.
OK, I think I found it. The Pango layout from GtkPrintOperation may have the resolution set to a non-default value, and that resolution probably depends on the output device. However, this resolution is set in the PangoContext one can get from the GtkPrintOperation, context that Scintilla never get -- and can't (at least easily), it creates its Pango contexts directly from the Cairo ones.
This results in an inappropriate resolution on the Scintilla draws, hence the bigger text and the sizing issues (since we get out own context from the GtkPrintOperation, context that has the proper resolution).
So, three solution are possible:
1) Set the magnification so it compensates the resolution difference. However, this is not really a solution because the magnification value is a integer, which isn't precise enough (e.g. it can't represent the compensation needed if the device output resolution is 72, which would give a magnification of -2.5).
2) Scale down Scintilla's drawings. This requires a little more attention since then the surface size given to Scintilla needs to be adjusted to compensate the scaling, but it works.
3) make the same mistake in our own code an ignore the resolution. This doesn't seem sensible since that resolution isn't here for nothing, and it doesn't fix the overall sizing problem.
So, I implemented solution 2 in the attached patch, please test and tell me if it's ok, better, or what problem remains, etc.
- Printed lines are right-shifted compared to previous Geany versions,
causing wrapping which did not occur in previous Geany versions.
As you noted, it's Scintilla that adds whitespace to separate line numbers from code, but we prefer a vertical line.
BTW, with the appropriate sizing, the 3 spaces aren't that big, and even though we may prefer to only have say, 0.5 on both side of the vertical line, it's not that much of an issue I think.
Regards, Colomban
I applied the patch. Page 1 of the printout has 54 lines, Print Preview has 56.
The vertical line on Print Preview looks fine, on the hard copy it appears on top of the least significant digit of the line number. For example, on line 1, the vertical line is superimposed on the vertical line that comprises most of the 1's glyph.
The vertical line extends down "a ways" past the last line number. On Print Preview, it extends what seems to be one line height, or so. On hardcopy, it extends what might be three lines, its difficult to measure. Perhaps it is drawn to the top of the page number row, but the last printed line is one line less?
Anyway, the good news is that my test doc, page one anyway, does not wrap.
Le 01/11/2012 04:10, Roger Booth a écrit :
I applied the patch. Page 1 of the printout has 54 lines, Print Preview has 56.
The vertical line on Print Preview looks fine, on the hard copy it appears on top of the least significant digit of the line number. For example, on line 1, the vertical line is superimposed on the vertical line that comprises most of the 1's glyph.
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.
The vertical line extends down "a ways" past the last line number. On Print Preview, it extends what seems to be one line height, or so. On hardcopy, it extends what might be three lines, its difficult to measure. Perhaps it is drawn to the top of the page number row, but the last printed line is one line less?
The vertical line is drawn from the header to the "bottom of the area minus one line height". This should be roughly correct, but in theory could go "line height -1px" too far if the print area isn't a multiple of lines. Getting this right would be (area_height - (area_height % line_height)), but it'd require to know the exact line_height Scintilla uses, including the blanks between lines.
And the bigger offset in the hard copy might come from the maybe improper margin I was speaking about before.
Anyway, the good news is that my test doc, page one anyway, does not wrap.
Yeah, at least the font sizing is better.
Regards, Colomban
Anyway, the good news is that my test doc, page one anyway, does not wrap.
Yeah, at least the font sizing is better.
Hey, that was the major gripe I had with the new implementation. I can easily just comment out the lines in printer.c that draw the vertical line, and I'll be happy. So I appreciate the changes.
Thats not to say I won't continue to work on this to get it perfect. (But not 'tonight').
You've probably already studied the Scintilla source file Editor.cxx, but you only mentioned looking at SciTE's source, so I thought I'd ask. I have taken notes of the calculations Scintilla makes to calculate the width of the line number column. Unfortunately, Scintilla's print function Editor::FormatRange() declares a local variable ViewStyle vsPrint(vs), and all the calculated values are stored there. That's why SSM(SCI_GETMARGINWIDTHN) returns worthless values.
So, I'm guessing you've looked through that code, but in the off chance, that code uses totally different calcs than the old Geany printing code. So I thought I'd mention it. I have notes, again in the off chance.
Thanks! Roger
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.
I'll do more testing tomorrow, but its looking good.
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.
Regards, Roger
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
I found a new problem just now. I changed the font size from 10 to 12. Text that is tab-aligned on the screen, and tab-aligned in Print Preview when the font size is 10 is no longer tab-aligned in Print Preview when the font size is 12.
Regards, Roger
Le 02/11/2012 01:12, Roger Booth a écrit :
I found a new problem just now. I changed the font size from 10 to 12. Text that is tab-aligned on the screen, and tab-aligned in Print Preview when the font size is 10 is no longer tab-aligned in Print Preview when the font size is 12.
I'm unable to reproduce this, could you provide a small sample showing the issue? Though this sounds like a Scintilla issue, I doubt anything we can do could change that.
On 11/02/2012 06:59 AM, Colomban Wendling wrote:
Le 02/11/2012 01:12, Roger Booth a écrit :
I found a new problem just now. I changed the font size from 10 to 12. Text that is tab-aligned on the screen, and tab-aligned in Print Preview when the font size is 10 is no longer tab-aligned in Print Preview when the font size is 12.
I'm unable to reproduce this, could you provide a small sample showing the issue? Though this sounds like a Scintilla issue, I doubt anything we can do could change that.
Attached is an example. I see a problem in Print Preview when I change to either font size 12 or font size 8.
Regards, Roger
Le 02/11/2012 15:49, Roger Booth a écrit :
On 11/02/2012 06:59 AM, Colomban Wendling wrote:
Le 02/11/2012 01:12, Roger Booth a écrit :
I found a new problem just now. I changed the font size from 10 to 12. Text that is tab-aligned on the screen, and tab-aligned in Print Preview when the font size is 10 is no longer tab-aligned in Print Preview when the font size is 12.
I'm unable to reproduce this, could you provide a small sample showing the issue? Though this sounds like a Scintilla issue, I doubt anything we can do could change that.
Attached is an example. I see a problem in Print Preview when I change to either font size 12 or font size 8.
OK, gotcha (after a looong and boring dig into Scintilla code, beuah). Actually Scintilla doesn't setup its Pango layouts for the actual target Cairo surface but always for the widget's one, so some of the measurements were done using a layout setup for the screen, thus the sizing problem with the cairo_scale()s. Attached patch should (and does here) fix the issue (0004-Scintilla-properly-update-the-Pango-contexts-for-the.patch).
Additionally it made me see that the scaling was inaccurate because Scintilla don't use the default Pango scale but the scale for the screen (which is correct), which changes depending on the screen's DPI.
I attach all patches. They are based upon the printing-with-scintilla branch but should apply cleanly on master.
Regards, Colomban
On 11/02/2012 02:03 PM, Colomban Wendling wrote:
Le 02/11/2012 15:49, Roger Booth a écrit :
On 11/02/2012 06:59 AM, Colomban Wendling wrote:
Le 02/11/2012 01:12, Roger Booth a écrit :
I found a new problem just now. I changed the font size from 10 to 12. Text that is tab-aligned on the screen, and tab-aligned in Print Preview when the font size is 10 is no longer tab-aligned in Print Preview when the font size is 12.
I'm unable to reproduce this, could you provide a small sample showing the issue? Though this sounds like a Scintilla issue, I doubt anything we can do could change that.
Attached is an example. I see a problem in Print Preview when I change to either font size 12 or font size 8.
OK, gotcha (after a looong and boring dig into Scintilla code, beuah). Actually Scintilla doesn't setup its Pango layouts for the actual target Cairo surface but always for the widget's one, so some of the measurements were done using a layout setup for the screen, thus the sizing problem with the cairo_scale()s. Attached patch should (and does here) fix the issue (0004-Scintilla-properly-update-the-Pango-contexts-for-the.patch).
Additionally it made me see that the scaling was inaccurate because Scintilla don't use the default Pango scale but the scale for the screen (which is correct), which changes depending on the screen's DPI.
I attach all patches. They are based upon the printing-with-scintilla branch but should apply cleanly on master.
Regards, Colomban
Well, I've totally blown my printer ink budget for the month :-) . But these patches look great. And I like that the new code prints longer lines without wrapping. I'd definitely give up a few lines per page in trade for longer lines w/o wrapping.
As for the vertical line thing, sorry I kept harping on that. Until last turn-around, I was only testing page one, and failed to realize it wasn't that the line height calc was wrong, instead you just always draw to just above the page number. So I have an easy (personal) fix. I'll just comment the line-drawing code in my version. I tried it, and I'm happy without the line. So thats the last problem I know of in Geany's code.
I'm willing to work on the Scintilla code base to develop a permanent vertical-line-drawing solution. But I've been a Windows programmer all my career until a year ago, and since then its like drinking from a firehose. I've destroyed my Linux installation twice, having to reinstall from scratch (fortunately I put home on a separate partition). And I've since somehow sort of broken the latest install; it won't automount. That's actually forced me to learn about dmesg and pmount. Anyway, beyond that, there's learning GTK+ and the deprecation caused by 3.0, which I note Geany is dealing with. My wife and I just bought Android tablets, so now I have to learn Java. There's more, but maybe you get the idea. Anyway, I'll try to help Scintilla with printing, and I'll try not to be an annoying nooby.
I just registered an account on Gnome Bugzilla. I found an existing bug complaining that the print dialog showed no notice about the correct syntax for printing ranges of pages. I added a request for an error message when the user screws up.
I'll go back through my posts and see if I should submit other bugs to Scintilla or Gnome.
What about patch 4
Scintilla: properly update the Pango contexts for the target surface
I assume you will submit it?
Regards Roger
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.
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).
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.
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.
Another 'does anyone care' - if you choose to Print Preview page 3 of a one-page document, nothing happens. No diagnostic, nothing.
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. 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).
Regards, Roger
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