Re: GdkPangoRenderer



On 21.11.2004 17:32, Owen Taylor wrote:
On Sun, 2004-11-21 at 16:43 +0100, Hans Breuer wrote:

On 20.11.2004 22:56, Owen Taylor wrote:

[...]
The main remaining issue for getting the GTK+ changes into CVS is Win32
support. Possible steps in that direction:

- Simply implement drawable.draw_glyphs_transformed by calling
  drawable.draw_glyphs. That would at least keep what works currently
  working, but rotated text wouldn't work. Approximate time - 10 minutes.

- Implement support in PangoWin32Font for loading fonts with transformation
  matrices and implement pango_win32_render_transformed(). This is
  sufficient to get rotated text working. Approximate time - 2-3 hours(?)


Although I think your scheduling is overly optimistic I can try to get this into cvs today.

Some cheating was needed to get this going in time, i.e. *not* loading
fonts with transformations, but just using SetWorldTransform() in
pango_win32_render_transformed(). I'm a little bit sorry about outdated
'OS' version users (read Win9x) cause it won't work there - but I'm not
any longer one of them ;-)


Heh, well, with that offer on the table, I guess I can't stall on
committing to CVS... done.

My commit will follow soon. Eye Candy attached.


- Implement a PangoWin32Renderer. Not really needed for GDK, but would
  clean up duplicated code and provide some new capabilities.
  Approximate time - 2-3 hours(???)


Not that it is a precondition for me working at this, but it would be
nice to get the capabilities described in
http://bugzilla.gnome.org/show_bug.cgi?id=94791
and
http://bugzilla.gnome.org/show_bug.cgi?id=107668
(bitmap rendering and font outlines) into the pango renderer as well;
and not only for the FT2 case ...


While with PangoRenderer it's a whole lot easier to write alternate
rendering paths, some of the basic problems haven't changed:

 - The right interfaces likely involve introducing a number of
   abstractions that go away with Cairo; it's a lot of new
   API in general.

AFAIK Cairo has no way to get on any outlines yet (even no plans?)
so IMHO at least the Pango glyph outline wouldn't become obsolete.
For the bitmap stuff - as you write below - it is quite simple
to get such with the help of gtk, so it could as well be
postponed further.

 - This stuff isn't actually implementable with the Xft backend
   without a lot of work, since the Xft library doesn't expose
   the necessary pieces... it doesn't expose the bits it renders
   to the application.

Cruft must die? But serious: what's the reason to have all backends
provide the same facilities - they don't do today neither.

I've been thinking quite a bit about this area recently; I agree
there are problems here that need to be solved:
- Needing the FT2 backend on Windows for bitmap rendering
   is clearly a big pain.

You don't really need it if Gtk is available:
http://cvs.gnome.org/viewcvs/dia/lib/dialibartrenderer.c?r1=1.14&r2=1.15

- Outline decomposition isn't really even possible with the FT2 backend without duplicating code from inside Pango to
   get the right load flags.

See The GIMP (whiches FT2 dependency isn't avoidable currently)

 - People want to use the FT2 backend to do colored bitmap rendering

 - Everybody has to write their own render-FT_Bitmap-to-a-GdkPixbuf.
   while that's only 30-40 lines of code, it's not an obvious
   30-40 lines of code.

But it's just not clear to me that pre-Cairo baby steps are worthwhile
at this point.

It all depends on the size of Cairos baby steps, doesn't it?
[Given the speed they get a working win32 backend, PDF output,
reasonable PostScript etc. I personally doubt Cairo will be ready
for prime time before the end of the decade ;-]

At least I did not want to wait any longer, see :
http://bugzilla.gnome.org/show_bug.cgi?id=158972

	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert

PNG image



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]