[cairo] [PATCH]A cairo-ps-surface.c issue for modern finicky versions of ghostscript

[Adrian Johnson]

Alan W. Irwin wrote:
> Hi Adrian:
> 
> Thanks for working so hard to replicate the problem and also thanks for your
> explanation of how the various kinds of fonts get embedded.
> 
> That leads to another question.  Why doesn't the (patched) PostScript
> backend give consistent results for pscairo and pngcairo (and xcairo) for
> example 24? At least for the fonts I have installed on my Debian testing
> system, the Korean peace word is blank for pscairo (and pdfcairo) and
> one-tenth size for pngcairo and xcairo.  From your explanation I now assume
> the small size is due to having a bitmapped Korean font installed somewhere
> on my Debian testing system that fontconfig finds as a last desperate try to
> find something that vaguely works, but why don't we see that small result
> for postscript (and pdf)?  Or is this an artifact of the minimalist approach
> I took to applying your patches?

Looking at the the x24c.pscairo file the Type 3 font is named
"CairoFont-0-0"

  8 dict begin
  /FontType 3 def
     ....
  currentdict
  end
  /CairoFont-0-0 exch definefont pop


Then searching for each occurrence of CairoFont-0-0

  /CairoFont-0-0 [ 0 -24 -24 0 0 0 ] selectfont
  -2096679.5 626.100006 M
  <0102>
  [-24 0 ] yS

and

  /CairoFont-0-0 [ 0 -24 -24 0 0 0 ] selectfont
  -2096949.399994 387.5 M
  <0304>
  [-24 0 ] yS

The x coordindate -2096679 is off the page. I've seen this problem
before when using pango with bitmap fonts. PS and PDF files would have
large negative numbers in the moveto used to position text. However the
text would appear ok in PNG files. Using gdb I confirmed that pango is
passing in large negative coordinates to cairo_show_glyphs(). There is
also a bug report here

  http://bugs.freedesktop.org/show_bug.cgi?id=10118

and pango bug report here

  http://bugzilla.gnome.org/show_bug.cgi?id=474418

The pango developers do not appear to have made any progress on this bug.