After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 572024 - Printing: Note content printing over margin and past bottom of page
Printing: Note content printing over margin and past bottom of page
Status: RESOLVED FIXED
Product: tomboy
Classification: Applications
Component: General
0.13.x
Other Linux
: Normal major
: ---
Assigned To: Benjamin Podszun
Tomboy Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-02-16 15:38 UTC by Sandy Armstrong
Modified: 2009-05-02 14:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
"LugRadio Live Rocked, and UIA progresses" note (5.96 KB, application/octet-stream)
2009-02-16 15:42 UTC, Sandy Armstrong
  Details
PDF output of "LugRadio Live Rocked, and UIA progresses" note (25.08 KB, application/pdf)
2009-02-16 15:44 UTC, Sandy Armstrong
  Details
One off corrected, starting with the correct first line on page 2ff now (659 bytes, patch)
2009-02-16 16:44 UTC, Benjamin Podszun
committed Details | Review
PDF output of the testcase note after this patch is applied (25.81 KB, application/pdf)
2009-02-16 16:45 UTC, Benjamin Podszun
  Details
PDF output of "Scratch" note (39.16 KB, application/pdf)
2009-02-16 17:17 UTC, Sandy Armstrong
  Details
PDF output of "Scratch" note (34.68 KB, application/pdf)
2009-02-16 18:25 UTC, Benjamin Podszun
  Details
Note with very, very long lines (42.86 KB, application/octet-stream)
2009-04-28 13:56 UTC, Benjamin Podszun
  Details
Note that should break in a normal paragraph (2.33 KB, application/octet-stream)
2009-04-28 13:58 UTC, Benjamin Podszun
  Details
Current (broken) result printing the note with very long lines (551.36 KB, application/pdf)
2009-04-28 14:01 UTC, Benjamin Podszun
  Details
Current (broken) support for paragraphs that don't fit on a page completely (11.99 KB, application/pdf)
2009-04-28 14:03 UTC, Benjamin Podszun
  Details
Patched (patch follows) result printing the note with very long lines (22.19 KB, application/pdf)
2009-04-28 14:07 UTC, Benjamin Podszun
  Details
Patched (patch follows) support for paragraphs that don't fit on a page completely (12.04 KB, application/pdf)
2009-04-28 14:08 UTC, Benjamin Podszun
  Details
Rewrote the gtk print support to account for two problems, tracked by bug 572024: (19.32 KB, patch)
2009-04-28 14:59 UTC, Benjamin Podszun
none Details | Review
Rewrote the gtk print support to account for two problems, tracked by bug 572024: (19.31 KB, patch)
2009-04-28 15:14 UTC, Benjamin Podszun
committed Details | Review

Description Sandy Armstrong 2009-02-16 15:38:26 UTC
With many of my long notes that should print multi-page, the breaks between pages seem to be calculated incorrectly.

I'm not sure of the best way to check this, but according to the GNOME Appearance Preferences (Font Tab, Details... button), my font resolution is 93 DPI.  I use Subpixel smoothing and Full hinting.  All of my fonts are set to some variation of 10pt Bitstream Vera Sans.  My screen resolution is 1920x1200.

I will attach two Tomboy notes and the PDF output I see when I attempt to print them.
Comment 1 Sandy Armstrong 2009-02-16 15:42:11 UTC
Created attachment 128839 [details]
"LugRadio Live Rocked, and UIA progresses" note

A long blog post draft that results in printing off the page.
Comment 2 Sandy Armstrong 2009-02-16 15:44:01 UTC
Created attachment 128840 [details]
PDF output of "LugRadio Live Rocked, and UIA progresses" note
Comment 3 Benjamin Podszun 2009-02-16 16:33:33 UTC
I can reproduce this on my machine as well. The reason seems to be that the code is rather dumb right now and tries to render whole paragraphs ("Lines" actually, which might end up as multiple lines on the result). The last line in your note is very long and shows two bugs:
1) This is an one-off problem (the paragraph should've been on the next page)
2) The basic approach is ugly, since we could fit quite some lines of this paragraph on the first page.

Since this is classified as major bug I'll first correct 1) which results at least in no corruption/loss of information in the resulting file.
Afterwards I plan to continue my cleanup/rewrite of the addin which will lay out these kind of notes in the expected way: Break at the end of the page, continue the fragment on the next one.


Thanks for the test case
Comment 4 Benjamin Podszun 2009-02-16 16:44:51 UTC
Created attachment 128843 [details] [review]
One off corrected, starting with the correct first line on page 2ff now

See my description above for the problem. This patch fixes the issue for me.
Comment 5 Benjamin Podszun 2009-02-16 16:45:35 UTC
Created attachment 128844 [details]
PDF output of the testcase note after this patch is applied
Comment 6 Sandy Armstrong 2009-02-16 17:17:41 UTC
Created attachment 128846 [details]
PDF output of "Scratch" note

Benjamin, that worked great on the note I attached on this bug.  I still have an issue when trying to print my "Scratch" note:

http://bugzilla.gnome.org/attachment.cgi?id=127654

I have attached the PDF output when trying to print this note.  See the bottom of the last page.

I'm going to commit your patch now, as it definitely helps.
Comment 7 Sandy Armstrong 2009-02-16 17:22:42 UTC
Committed patch in r2341.

An obvious problem with this patch, Benjamin, is that if you have one huge paragraph, it will still overflow.  I doubt that's very common but I think it's a component of this bug.  As a test, I took the "LugRadio Live [...]" note, removed all line breaks, and had it repeat once (so one really disgustingly huge paragraph).  It should have printed as two (or three?) pages, but instead printed as one with runoff.
Comment 8 Benjamin Podszun 2009-02-16 18:13:41 UTC
That's (talking about the loooong line) expected: I cannot currently separate lines (in the note) into lines on the page. That's what I meant with bug 2) further up. I have to solve that by partially rendering lines/paragraphs per page, something I'm going to implement next. I'm not sure if that'll be ready tonight but it's on top of my list. So that's unrelated of the one-off bug and more a current design limitation (which sucks).

Worse than that, actually, is that I cannot reproduce your problem with the Scratch note. I tested it _before_ I submitted this patch (since my personal notes are quite small so far I heavily use your testcases so far) and it works fine for me, resulting in 4(!) pages with correct contents.

What's your take here: Should I go for the rewrite regarding paragraphs first or hunt this over the edge bug of yours? The former might change parts of the code in quite some ways, so I'm currently leaning in favour of rewriting and then testing/fixing regressions in the new code. Comments?

Comment 9 Benjamin Podszun 2009-02-16 18:25:31 UTC
Created attachment 128854 [details]
PDF output of "Scratch" note

I first noticed that our notes were rendered differently, but the only issue was that you added some content to the Scratch note inbetween ("test a thing\nweird.\n\n"). When I do the same I end up with this PDF, looking exactly like yours but wrapped correctly. Can you reproduce this with other notes as well?
Comment 10 Sandy Armstrong 2009-02-16 19:15:48 UTC
(In reply to comment #8)
> What's your take here: Should I go for the rewrite regarding paragraphs first
> or hunt this over the edge bug of yours? The former might change parts of the
> code in quite some ways, so I'm currently leaning in favour of rewriting and
> then testing/fixing regressions in the new code. Comments?

If you can do the rewrite by March 2nd, then I think you're right.  It's best to do the rewrite first and then see if the same regressions even exist.
Comment 11 Benjamin Podszun 2009-04-28 13:56:08 UTC
Created attachment 133493 [details]
Note with very, very long lines

Random long lines in a note that currently break the print support (aren't wrapped accordingly). Careful, this note slows down the app on my netbook!
Comment 12 Benjamin Podszun 2009-04-28 13:58:25 UTC
Created attachment 133494 [details]
Note that should break in a normal paragraph

Testcase for a note with reasonable/normal lines that just happen to fit on the output best if wrapped/split into parts
Comment 13 Benjamin Podszun 2009-04-28 14:01:04 UTC
Created attachment 133495 [details]
Current (broken) result printing the note with very long lines

Current state of the problem, to document the issue: These cases are completely broken.
Comment 14 Benjamin Podszun 2009-04-28 14:03:59 UTC
Created attachment 133496 [details]
Current (broken) support for paragraphs that don't fit on a page completely

Documenting the technically lesser but far more common problem: Paragraphs that don't fit on the rest of the page are currently completely moved to the next one, leaving empty space inbetween.
Comment 15 Benjamin Podszun 2009-04-28 14:07:33 UTC
Created attachment 133497 [details]
Patched (patch follows) result printing the note with very long lines

This is the way the output _should_ look like
Comment 16 Benjamin Podszun 2009-04-28 14:08:29 UTC
Created attachment 133498 [details]
Patched (patch follows) support for paragraphs that don't fit on a page completely

This is the way it should look like.
Comment 17 Benjamin Podszun 2009-04-28 14:59:06 UTC
Created attachment 133506 [details] [review]
Rewrote the gtk print support to account for two problems, tracked by bug 572024:

1) Very long lines were not wrapped around
2) Paragraphs at the end of any page wouldn't render partially, therefor leaving excess whitespace on the result

Both issues should be resolved.
Comment 18 Benjamin Podszun 2009-04-28 15:14:37 UTC
Created attachment 133510 [details] [review]
Rewrote the gtk print support to account for two problems, tracked by bug 572024:

1) Very long lines were not wrapped around
2) Paragraphs at the end of any page wouldn't render partially, therefor leaving excess whitespace on the result

Both issues should be resolved.
Comment 19 Benjamin Podszun 2009-04-28 15:18:31 UTC
First git patch and I was dumb enough to forget about git config --global settings on this machine of mine.. The second patch should be fine.
Comment 20 Sandy Armstrong 2009-05-02 14:06:03 UTC
This appears to fix all of my problems, Ben!  I'll open a new bug to make things like margin width configurable.  I just pushed it, but I realized too late that you set your name to "Benajamin.Podszun".  You should change that in your ~/.gitconfig to "Benjamin Podszun".

Resolving this bug as fixed, as your patch addressed everything I think.