Re: PANGO_GLYPH_EMPTY

[Behdad Esfahbod <behdad cs toronto edu>]

On Thu, 4 May 2006, Dov Grobgeld wrote:

> Hello,
>
> There seems to be a problem in the visibility of the PANGO_GLYPH_EMPTY
> enum. On the one hand it is defined privately, but on the other hand
> it is encoded in the PangoGlyphString which is returned in a
> PangoLayoutLine which is public. I encountered it while trying to skip
> non-printable characters in my program paps...

That's true.  During the 1.11 cycle I introduced
PANGO_GLYPH_EMPTY, but later in the cycle it became clear that we
may be going to change its value, and add new API for dealing
with pseudo-glyphs (like the empty glyph, hexboxes, etc), so
Matthias and I decided to hide PANGO_GLYPH_EMPTY in the backend
interface to keep the possible damage of the future API change in
control...  You can access it by defining PANGO_ENABLE_BACKEND
before including pango.  That's what gnome-print does for
example...  It's a hack, true. But I believe you could have the
same problem previously too, with hexboxes.  There's still no
public way to check whether a PangoGlyph is a hexbox.  That
probably is not an issue with the FT2 backend that paps uses
though.

> Regards,
> Dov
>
> P.S. I have realized that all the font and outline traversals that I
> do in paps are now preferably done through cairo. The question is if
> the released postscript backend of cairo is up to it yet, or if I
> should hold off the porting for another while?

You could use pangocairo to get the paths since the first
release, without needing the cairo PS backend, but with the PS
backend as it stands now in the devel tree, and will be in the
upcoming cairo 1.2 release, you can retire most of the code in
paps.  The PS backend right now generates Type3 fonts for all
text operations.  That's about what PAPS does AFAIR.


--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
	-- Dan Bern, "New American Language"