GNOME Bugzilla – Bug 125762
Add better Pango support
Last modified: 2004-12-22 21:47:04 UTC
Adding the ability to write to a GnomePrintContext as easily as Pango can currently write to an FT2_Bitmap extends Pango for use with GNOME Print. Having Pango and GNOME Print work together has been discussed on and off since at least when I started tracking Pango and GNOME Print back in 2001. Pango and GNOME Print are certainly a lot more aligned than they were back in early 2001, but the idea of just passing a PangoLayout to GNOME Print still isn't happening. While I believe that passing a PangoLayout to GNOME Print is the wrong way around, and that Pango should be passed a GnomePrintContext instead, the exact details don't matter provided it is possible to render a PangoLayout to a GNOME Print document. A GNOME Print backend would be useful for other GNOME projects such as Conglomerate, and would allow the incongruous PangoPDF project on SourceForge to shut down.
(added Conglomerate's bugzilla-tracking list to cc)
Could you expand on why you believe that passing a pangoLayout to gnomeprint is the wrong way around ?
The way it should work is roughly that you create a PangoContext for a GnomePrintContext, then create PangoLayout's using that PangoContext. http://people.redhat.com/otaylor/grid-fitting/ comes out ofthinking I did about gnome-print / Pango integration, and is essentially (if not obviously) an argument why GnomeGlyphList is wrong and should be abandoned. The simplest thing for now to do is to simply do device-independent layout; doing relay-out based on device gridding as described in that article might require some Pango API changs. To get reasonable Pango / gnome-print integration, one thing that you have to be clear on is that GnomePrintMeta is not a *file* but simply a serialization of drawing commands, and needs to be replayed in an environment with exactly the same set of fonts and Pango shapers.
To answer Jody Goldberg's question, passing a GnomePrintContext to Pango is preferable to passing a PangoLayout to Pango because it parallels how Pango works with existing backends. You don't pass a PangoLayout to a FT2_Bitmap, so why would it be preferable to pass a PangoLayout to a GnomePrintContext? Pango, in making the PangoLayout, has done the work of sorting out the fonts and the positions of the glyphs, and from that it should be simpler to then drive GNOME Print from Pango than pass a PangoLayout to GNOME Print and have GNOME Print rediscover fonts, etc. from the PangoLayout.
To respond to Owen Taylor's comment: - On one level, I don't care how it should work as long as it does work. - PangoPDF currently attempts device-independent layout. - I'm no great fan of GnomeGlyphList. - When the final output is PDF, there's another set of grid-fitting going on when the PDF application displays or prints the output.
For device independent metafiles like PS or PDF, you can't do better than position independent positioning. But if we are using the same API for screen display (preview, e.g.) then you can do significantly better. This is probably a little less important for gnome-print, since gnome-print is basically a printer-only API but I'm trying to keep gnome-print and Cairo in mind at the same time.
Think this belongs in gnome-print, not Pango.
If it's in gnome-print, then the subject should change
I believe Bug #102809 addresses the same issue!
How is just adding a GNOME Print function that prints PangoLayouts from existing Pango backends going enable layout of text for device independent metafiles like PS or PDF?
I've linked in bug 102809 to my suggested patch for this issue; it doesn't actually create a new backend for Pango, but simply integrates the FT2 backend with gnome-print. My current feeling is that the work of creating a separate backend doesn't make sense with the current direction of Cairo as the long term direction for printing.
*** Bug 102809 has been marked as a duplicate of this bug. ***
For reference, the link to my mail is: http://mail.gnome.org/archives/gnome-print-list/2004-June/msg00001.html
Maybe I am missing out something, but it would be nice to have a replacement for gnome_font_get_width_utf8_sized() - it is extensively used in the gtkhtml printing code.
Details of the patch would be better discussed on the gnome-print mailing list. Can you bring it up there? (I should mention that I'm almost done with a patch to get GtkHTML working using my new API, I'll send that to the gtkhtml mailing list when I'm done with it.)
Created attachment 28425 [details] [review] new Pango-support API The patch sent to the list, as it turns out, was against a 2.5.x snapshot. Here's a patch that should compile cleanly against CVS HEAD.
None of my patches have been accepted to pango and I have no experience with gnome print. I believe my patches were mostly rejected due to the fact it was near freeze. Anyway, I gave this patch a cursory overview. I like the way this works. However, it still seems that many common font attributes, such as thos defined in xsl and other platforms, seem to be missing. Maybe I am just not looking close enough. A few of my complaints may be fixed by Owen Taylor if he does his fix up of underlining... namely that it should be able to be done in a color other than the text... single, double, and triple are available in other places as well.
Trever : Owen's patches went in for 2.7.0 As for the other attributes, underline color, triple underline etc, Those should be added in pango rather than at the g-p level. I'll close this out. We can open new reports with issues specific to owen's code as necessary.