GNOME Bugzilla – Bug 143874
Use Pango for printing
Last modified: 2014-02-15 12:53:14 UTC
Right now gtksourceview has custom printing code that does layout itself in terms of gnome-print's normal text APIs. This means that gtksourceview is unable to print lanugages like Hindi or Arabic that require more sophisticated text layout. The attached patch uses the new gnome-print API from bug 125762 (which will be in the GNOME-2.8 platform) for printing instead of custom layout code. There are some API additions related to the fact that gtk_source_print_job_set_font() and related take a gnome-print Font name not a Pango font name. Just changing the interpretation would break existing code so I took a different approach and added a parallel API gtk_source_print_job_set_font_desc() taking a PangoFontDescription. The old functions are kept around and convert from gnome-print font name to Pango font description. In general, with this patch pagination is somewhat slower, but that only becomes an issue for *very* large files. (A 12,000 line C file took about 2 seconds to paginate on my machine). If this was a concern, it might be nice to have asynchronous pagination as well as printing since it does block the application while paginating. The patch actually includes a big performance speedup to get_text_with_style() in the case of a buffer without any tags; the old algorithm repeatedly scanned the entire document for tag toggles. It might be worth backporting the new approach of keeping track of the next tag toggle across lines to the current code base. I've tried to keep the coding style constistent with that of the code, but it's not my normal style, so there might be a slip-up or two.
Created attachment 28431 [details] [review] Use Pango when printing
Created attachment 28432 [details] [review] Docs diff Forgot the docs/ directory in the last patch
Gustavo: could you please give a look at this patch? I think it can go in.
Looks good to me. Only needs a ChangeLog entry ;-)
*** Bug 100726 has been marked as a duplicate of this bug. ***
Committed with a ChangeLog entry 2004-07-15 Owen Taylor <otaylor@redhat.com> #143874: Use Pango for printing * configure.in: Require gnome-print >= 2.7 for new Pango integration. * gtksourceview/gtksourceprintjob.[ch] docs/reference/gtksourceview-sections.txt: Add functions to set the various fonts as Pango font descriptions rather than gnome-print font names. gtk_source_print_job_{set,get}_{,numbers_,header_footer_}font_desc(). Also add "{,numbers_,header_footer_}font_desc" properties. * gtksourceview/gtksourceprintjob.c: Rewrite printing code to use Pango and gnome-print functions to print Pango objects rather than being a separate implementation of layout. * gtksourceview/gtksourceprintjob.c (gtk_source_print_job_get_property): Fix memory leak for FONT properties. * gtksourceview/gtksourceprintjob.c (get_text_with_style): Improve performance of tag toggle searches for large unstyled buffers. (Don't search for the next tag toggle for each line.) The package version should probably be bumped so that gedit can rely on the new version for the patch in bug 143877, but I'll let you guys do that. Thanks for the review.
Owen: Testing the patch I have noticed that the "TAB" characters are shown in the "Print Preview" window. Is this a known libgnomeprint/ui bug or the problem is due to the patch itself? I'm attaching a screenshow showing the problem.
Created attachment 29682 [details] Screenshot
Created attachment 29683 [details] Generated PDF file The generated PDF file has the same problem too.
What font? What version of Pango?
Font: Bitstream Vera Sans Mono Pango version: [paolo@sara pango]$ pkg-config --modversion pango 1.5.0 [paolo@sara pango]$ cvs status ChangeLog =================================================================== File: ChangeLog Status: Needs Patch Working revision: 1.935 Repository revision: 1.939 /cvs/gnome/pango/ChangeLog,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)
2004-07-26 Owen Taylor <otaylor@redhat.com> * libgnomeprint/gnome-print-pango.c (gnome_print_pango_glyph_string): Don't draw glyph id 0. (Mentioned in #143874, Paolo Molaro)
I'm Paolo Maggi, not Molaro. But it is not a problem. Thanks for fixing this problem.
I have found another problem. If in gedit I use "Fixed", "console8x16" or "console8x8" font as body font no text is printed and the total number of pages is set to 0. I have discovered this problem testing the patch for bug #143877.
Fully fixing the last is a bit hard to fix ... for one thing, for one thing, eliminating the bitmap fonts in the Page Setup dialog would require GtkFontSel API changes. Falling back to a default font if the user selects a bitmap font is also difficult ... I've sent some mail to the fontconfig mailing list asking for ideas about how to do that efficiently. Can we open a separate bug for this issue and close this bug?
Yes, please, open a separate bug for the fixed fonts issue and mark this one depending on it.
Owen: can I close this bug? Have you already opened a separate bug for the issue about the bitmap fonts?
Owen: Testing the patch again I have discovered other problems too. I'm attaching a screenshot showing the problems. As you can see from the screenshot the line numbers are completely wrong (see for example the line number of ADD_CHILD, or line numbers 81 and 82) The text goes outside the margins if "text wrapping" is not enabled. You can see the font I'm using from the screenshot. Other info: [paolo@elilix gedit]$ pkg-config --modversion pango 1.6.0 [paolo@elilix gedit]$ pkg-config --modversion libgnomeprint-2.2 2.8.1 [paolo@elilix gedit]$ pkg-config --modversion libgnomeprintui-2.2 2.8.1 [paolo@elilix gedit]$ pkg-config --modversion gtksourceview-1.0 1.1.1
Created attachment 33464 [details] Screenshot showing the reported problems.
Comment on attachment 28432 [details] [review] Docs diff Sorry for the spam
*** Bug 158030 has been marked as a duplicate of this bug. ***
Created attachment 35105 [details] [review] Patch fixing the line number problems and the para box when wrap is disabled Paolo: Sorry for the delay. Here's a patch which fixes both the line numbers problem and the paragraph bounding box when text wrap is disabled. The patch is hacky, and I don't like it so I'm putting it up here for review and suggestions. The line number printing fix involves two parts: 1) correctly getting the paragraphs to print; for empty lines gtk_text_iter_forward_to_line_end() would skip the empty line, thus causing the incorrect numbering. That part of the patch is ok. 2) for empty paragraphs, pango_layout_iter_get_baseline() returns 0, so at the end of create_layout_for_para() I check this condition and add a space character to force the calculation of the baseline. I don't like that, but I didn't find a better way to do it (Owen?). Note that a paragraph is considered empty either when it has no characters, or when it only has tabs. For the bounding box problem I chose to ellipsize the paragraph when text wrapping is disabled. Another possibility would be to set the width so the text breaks into multiple lines, and paginate/render just the first one. But that involves more code changes, and so that's why I chose the ellipsizing approach. Comments? I'd be very interested in an alternative to the 2nd issue with the line numbering.
You could just set a clip in gnome-print, I think, if you want truncation on screen. Or, another possibility is to simply just ignore WRAP_NONE and treat it as WRAP_WORDS ... I don't think ellipsization is that useful, and whether someone wants a scrollbar onscreen doesn't seem to correspond to whether they want lines wrapped on paper. pango_layout_iter_get_baseline returning zero on a layout (as I understand your description) is just a Pango bug... can you file one about that? (Actually, the code in Pango looks fine on quick inspection, but I could be missing something.) I don't think your hack is bad as a quick workaround, as long as there is a good comment in the code explaining why it is there. My experience that leaving a comment that just says: /* FIXME: <horrible-hack> */ In the code means that two years later you'll agree that it is a horrible hack, but will have absolutely no idea what it is a hcak for.
Gustavo: news? I agree with Owen. The hack is not so bad since it seems there is not a better solution at the moment. Please, if you have time, try to apply the Owen's suggestions about clipping and about adding a more detailed comment to the hack and commit. As I said you, I'd really like to branch gtksourceview as soon as possible.
I have committed the Gustavo's patch with some comments. I'm not closing this bug since Gustavo will try to apply the Owen's suggestions about clipping when he will be back home from vacation.
It's been nice piece of history.