GNOME Bugzilla – Bug 152939
Printing should use pango interface to libgnomeprint
Last modified: 2004-12-22 21:47:04 UTC
Users writing in hebrew and arabic can print in gnumeric (Maybe other locales ?). Other information: gnome-print implements pango using gnome_print_pango_layout (..). but gnumeric in the file print-cell.c use gnome_print_show (..). the cell is rendered correctly on screen (gtk use pango by default) but not printed correctly (gnome_print_show() do not use pango)
Should that be "can't print in gnumeric"?
Yes it is "can't print in gnumeric" :)
gnome_print_pango_layout in 2.6 was a kludge. We can not use it in 1.2.x For gnome-print-2.8 it has been revamped and we could consider using it for 1.4
Created attachment 31656 [details] screenshot of the problem
i will be very happy to print in gnumeric, and if you will use it on 1.4, i will move to gnumeric 1.4, thank you in advance, kobi.
Created attachment 31661 [details] [review] a test patch i've made a patch to test pango printing and i works for me, i do not think it is up to gnumeric coding tandards, but now i can print :)
Created attachment 31662 [details] screenshot of how the test patch work
Created attachment 31695 [details] [review] this patch is an error ! This patch is better :> ( i think )
I forgot, to use this patch (id=31695) you need to make cell_calc_layout not static.
This was envisioned long ago, but gnome-print couldn't print layouts back then. I like the ratio of "-" to "+" lines in that patch, btw!
Yes, I liked it too BUT it was a mistake !!! This patch (id=31695) does NOT work. 1. the cell_calc_layout use int and the print function use double. 2. the cell_calc_layout use the layout from the cell and the print need a new layout derived from the printing context solution ? 1. make a new layout cell_calc_layout that get a ready made layout and calculate the x,y, etc... for screen and printer ( and whatever ) 2. create a new layout cell_calc_layout just for the printer ( current solution ) 3. something better ?
It doesn't look too bad. We could... 1. Make cell_calc_layout take an extra parameter, RenderedValue *rv, from which to get the layout. (Using the rendered value will get indentation right.) 2. Have draw_cell supply cell->rendered_value for that argument. 3. Make cell_calc_layout non-static. What is it we need in floating point? The rectangle?
Created attachment 31731 [details] [review] a working test patch to use cell_calc_layout in print cell in this patch i copied the cell_calc_layout from draw-cell.c just to see what is needed. i have a problem with width and hight ( i will attach a screenshot next ) help ?
Created attachment 31732 [details] patch_20092004 screenshot
Created attachment 31757 [details] [review] use cell_calc_layout from cell-draw with printing *rv It finaly work, i'm very happy :) (next is a screenshot)
Created attachment 31758 [details] a screen shot of patch 21092004
Created attachment 31759 [details] a screen shot of patch 21092004 with hebrew i just had to put a screenshot with hebrew :) p.s. the printing argument i added to cell_calc_layout is ugly is there a better way to let the function know y axis is upside down and to use points and not pixels ?
Created attachment 31774 [details] [review] the same as print_cell_c_21092004, some code cleanups.
Created attachment 31787 [details] [review] header/footer printer patch (if you use hebrew local h/f is printed packword)
Created attachment 31789 [details] [review] header/footer (update) - i forgot to unref the print layout on the last patch
that looks pretty good. I don't know what the dpi should be, but I do know that gnome_font_get_pango_description ignores it except that it checks for >0. It looks like we might want to apply the header/footer patch independently of the cell draw patch. Jody?
attachments 31757, 31731 and 31695 should be striked out
Created attachment 31797 [details] [review] Updated header/footer patch This avoid having to require libgnomeprint 2.8 and avoid some minor rounding issues. Please test.
It works for me (But i have gnome_print_pango_create_layout) I loved to see the way you code ! p.s. I did not find the code for printing labels in graphs, can you point me to it ?
header/footer patch committed. I suspect you are looking for the code in src/cut-n-paste-code/goffice/graph/gog-renderer-gnome-print.c
Comment on attachment 31774 [details] [review] the same as print_cell_c_21092004, some code cleanups. I like the concept but the interface is too pixel specific to adopt in the current form. We'd need to either move to using pango fixed point measurements for both or produce multiple copies of the pixel code
Created attachment 31816 [details] [review] i've tried to get the pixels out of cell calc layout is this in the right direction ?
Oo.. Thank you Morten Welinder, I found the code in the place you showed my :)
Created attachment 31817 [details] [review] the same as (id=31816), i just forgon one refence to pixels in calc layout
Created attachment 31824 [details] [review] gnome print pango layout in graph The graph part of gnumeric is not working properly ? I did not test it !! i can't make graphs in my gnumeric cvs (but it compiles).
You might want to "make clean" and re-run the configuration process. (That has solved those problems for others.) Anyway, graph printing has been committed. I decided not to create a new layout for every text fragment as that was a problem recently for screen rendering. Also, the code has some type issues.
This cell printing patch still needs work. To get the ball rolling, I am... installing these baby-step changes: 2004-09-22 Morten Welinder <terra@gnome.org> * src/rendered-value.c (rendered_value_new): Get rid of quantify artefacts. * src/cell-draw.c (cell_draw): Get rid of quantify artefacts. (cell_calc_layout): Add rv and printing arguments, drop res_layout argument. Make extern. Caller changed. and calculating the y_direction (always +1 for now). Note, that your patch changed the meaning of rect->height = height + 1; to rect->height = height - y_direction * 1; I did not do that. Rendered values' ->layout_natural_height and ->layout_natural_width currently have pixel sizes in them, so we cannot simply use _get_size instead of _get_pixel_size. (We might want to change their definition.)
The skeleton work for cell printing is now in. To see it in action, do USE_NEW_PRINT=1 ./gnumeric It still has a terrible confusion of points an pixels, but I'm sure we can address that.
I believe the rounding issues have been addressed to the extent that we should be accurate to 1/1024 pt. That's far less than a pixel on even high-end printers. It still needs USE_NEW_PRINT=1 to be turned on.
*** Bug 62210 has been marked as a duplicate of this bug. ***
I finaly got graph to work (I did the make clean...) but the labels and the numbers jump around both on screen and on print, is it a problem with my build ? (it did not work at all until now) Can it be a problem with the patch ? ( the problem is on screen too )
There was a bug in graph printing (things got placed the wrong spot) until about an hour ago.
Stick a fork in it. It's done. Thanks for all the help.