Created attachment 100807 [details]
sample file to show the failure to render text in Helvetica

Note that changing the font family to Sans shows that this code, based on the pango documentation, should be correct. It fails to render any text in teh case of Helvetica.

*** Bug 503191 has been marked as a duplicate of this bug. ***

*** Bug 503162 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 474418 ***

How is this bug a duplicate of 474418? 474418 seems to drop some glyphs. This bug is talking about pango not rendering any strings in Helvetica, Times and some other common fonts?

Behdad, you marked this as a duplicate of bug 474418.  I take that to mean
that you have diagnosed the problem, at least superficially.  Would you
care to elaborate a bit about what is going on here?

There has been multiple reports that with certain fonts, pangocairo code working on screen, generates PDF that has "dropped" aka "missing" aka "not there" glyphs.  

Adrian Johnson, our cairo PDF hacker has diagnosed it a bit and confirmed that Pango is passing large off-the-page glyph positions to cairo.  No further diagnosis is done.

I have not been able to reproduce it at all.  But it's suspected to only happen with bitmap fonts, or fonts with bitmap strikes.  Helvetica and Times both fit that bill.  I think there was at least one report that this happened with the Postscript backend too.

What you can do to debug it:  add printf's in pango_cairo_renderer_draw_glyphs()'s main (that is the second one) loop and see if the glyph positions passed to cairo are sane.  They should be in Postscript points (that is, one inch is 72.0 points).  If the value is off the page, see where the wrong value's coming from.   Then track down up to the caller, ....  You know, debug it :).

Alternatively, I'll do the debugging at some point, if you send me the offending font.  I don't have a Helvetica and your code sample works here.

+ Trace 181682

That "y" is impressive.

In pango_renderer_draw_layout, pango_layout_iter_get_baseline (iter)
returns -2147483648

(gdb) p *(Extents*)iter->line_extents_link->data
$27 = {baseline = -2147483648, ink_rect = {x = 14001308, y = 0, width = 14001296,
    height = 0}, logical_rect = {x = 0, y = 0, width = 43008,
    height = -2147483648}}


Do you have Adobe's New Century Schoolbook?

That's consistent with what I remember.

No, I don't have any proprietary fonts actually.  Feel free to contact me privately.  ssh access works for example.

Reopening since discussion is going on here.

*** Bug 474418 has been marked as a duplicate of this bug. ***

Over in pango_layout_run_get_extents, we have (in my case) a 7-glyph string
that causes the trouble.  (It's "aaaaaaa" with Adobe New Century Schoolbook.)

Right after the pango_glyph_string_extents call we have:

(gdb) p *run_logical
$52 = {x = 0, y = -2147483648, width = 43008, height = -2147483648}

(gdb) p *run->glyphs
$50 = {num_glyphs = 7, glyphs = 0xdb13f0, log_clusters = 0xd76c10, space = 8}


(gdb) p run->glyphs->glyphs[0]
$42 = {glyph = 67, geometry = {width = 6144, x_offset = 0, y_offset = 0}, attr = {
    is_cluster_start = 1}}
(gdb) p run->glyphs->glyphs[1]
$43 = {glyph = 67, geometry = {width = 6144, x_offset = 0, y_offset = 0}, attr = {
    is_cluster_start = 1}}
(gdb) p run->glyphs->glyphs[2]
$44 = {glyph = 67, geometry = {width = 6144, x_offset = 0, y_offset = 0}, attr = {
    is_cluster_start = 1}}
(gdb) p run->glyphs->glyphs[3]
$45 = {glyph = 67, geometry = {width = 6144, x_offset = 0, y_offset = 0}, attr = {
    is_cluster_start = 1}}
(gdb) p run->glyphs->glyphs[4]
$46 = {glyph = 67, geometry = {width = 6144, x_offset = 0, y_offset = 0}, attr = {
    is_cluster_start = 1}}
(gdb) p run->glyphs->glyphs[5]
$47 = {glyph = 67, geometry = {width = 6144, x_offset = 0, y_offset = 0}, attr = {
    is_cluster_start = 1}}
(gdb) p run->glyphs->glyphs[6]
$48 = {glyph = 67, geometry = {width = 6144, x_offset = 0, y_offset = 0}, attr = {
    is_cluster_start = 1}}

gdb) p ((char *(*) (gpointer))g_type_name_from_instance) (run->item->analysis.font)
$58 = 0x2b7089525f0e "PangoCairoFcFont"

(gdb) p *(PangoCairoFcFont *)run->item->analysis.font
$59 = {font = {parent_instance = {parent_instance = {g_type_instance = {
          g_class = 0x663600}, ref_count = 3, qdata = 0x0}},
    font_pattern = 0xe64190, fontmap = 0x5dd9c0, priv = 0xe67c80, matrix = {
      xx = 1, xy = 0, yx = 0, yy = 1, x0 = 0, y0 = 0}, description = 0xf45910,
    metrics_by_lang = 0x0, is_hinted = 0, is_transformed = 0}, cf_priv = {
    cfont = 0xe67bb0, data = 0x0, scaled_font = 0xd9c9a0, hbi = 0x0,
    is_hinted = 0, gravity = PANGO_GRAVITY_SOUTH, font_extents = {x = 0,
      y = -2147483648, width = 0, height = -2147483648},
    glyph_extents_cache = 0xd9dde0, metrics_by_lang = 0x0},
  gravity = PANGO_GRAVITY_SOUTH}

Ok, can you check _pango_cairo_font_private_glyph_extents_cache_init()?  Seems like the line height we are computing based on return value of cairo_font_extents() is the cause.

Well, here's your guy.

+ Trace 181694

(gdb) print scaled_font->extents
$107 = {
  ascent = -nan(0x8000000000000),
  descent = -nan(0x8000000000000),
  height = -nan(0x8000000000000),
  max_x_advance = -nan(0x8000000000000),
  max_y_advance = 0
}


(gdb) print *scaled_font
$108 = {
  hash_entry = {
    hash = 4236963717
  },
  status = CAIRO_STATUS_SUCCESS,
  ref_count = 1,
  user_data = {
    size = 0,
    num_elements = 0,
    element_size = 24,
    elements = 0x0,
    is_snapshot = 0
  },
  font_face = 0xe687e0,
  font_matrix = {
    xx = 10,
    yx = 0,
    xy = 0,
    yy = 10,
    x0 = 0,
    y0 = 0
  },
  ctm = {
    xx = 1,
    yx = 0,
    xy = 0,
    yy = 1,
    x0 = 0,
    y0 = 0
  },
  options = {
    antialias = CAIRO_ANTIALIAS_DEFAULT,
    subpixel_order = CAIRO_SUBPIXEL_ORDER_DEFAULT,
    hint_style = CAIRO_HINT_STYLE_DEFAULT,
    hint_metrics = CAIRO_HINT_METRICS_OFF
  },
  scale = {
    xx = 10,
    yx = 0,
    xy = 0,
    yy = 10,
    x0 = 0,
    y0 = 0
  },
  extents = {
    ascent = -nan(0x8000000000000),
    descent = -nan(0x8000000000000),
    height = -nan(0x8000000000000),
    max_x_advance = -nan(0x8000000000000),
    max_y_advance = 0
  },
  mutex = {
    __data = {
      __lock = 0,
      __count = 0,
      __owner = 0,
      __nusers = 0,
      __kind = 0,
      __spins = 0,
      __list = {
        __prev = 0x0,
        __next = 0x0
      }
    },
    __size = '\0' <repeats 39 times>,
    __align = 0
  },
  glyphs = 0xd09d60,
  surface_backend = 0x0,
  surface_private = 0x0,
  backend = 0x2b021a85a520
}

Ok, back to my suspection that it's a cairo bug :(.

What cairo version is this?  Not sure how to proceed.  You can dig into cairo-ft-font.c and see what's going on, but if you don't feel like doing that, oh well.  I go ping Adrian now.  Hopefully he still can reproduce it and he's a cairo hacker.

Cairo 1.4.6 in my case.

It's a division by zero right here:

+ Trace 181696

(gdb) p *face
$128 = {
  num_faces = 1,
  face_index = 0,
  face_flags = 146,
  style_flags = 0,
  num_glyphs = 757,
  family_name = 0xf35ee0 "Adobe New Century Schoolbook",
  style_name = 0xf35ec0 "Regular",
  num_fixed_sizes = 1,
  available_sizes = 0xf35f10,
  num_charmaps = 1,
  charmaps = 0xf35fb0,
  generic = {
    data = 0x0,
    finalizer = 0
  },
  bbox = {
    xMin = 0,
    yMin = 0,
    xMax = 0,
    yMax = 0
  },
  units_per_EM = 0,
  ascender = 0,
  descender = 0,
  height = 0,
  max_advance_width = 0,
  max_advance_height = 0,
  underline_position = 0,
  underline_thickness = 0,
  glyph = 0xecfca0,
---Type <return> to continue, or q <return> to quit---
  size = 0xecfde0,
  charmap = 0xf35f80,
  driver = 0x67e3e0,
  memory = 0x671e60,
  stream = 0xecfb38,
  sizes_list = {
    head = 0xecfe40,
    tail = 0xecfe40
  },
  autohint = {
    data = 0x0,
    finalizer = 0
  },
  extensions = 0x0,
  internal = 0xee7440
}

Perfect.  Not sure if it's a freetype bug now.  Is this a bitmap font?  I think I know what the fix should look like.  Also, can you print out face->size and face->size->metrics?

Ok, reproduced it now by using font Fixed.  I'll take care of the rest.

Would this bug also affect postscript output? I see both my native postscript printer and gs erroring on postscript produced by gtk print. It contains a word of Helvetica.

Jon-Kaare: yes, very likely.  The bug causes glyphs to be placed far, far
off the visible page.  I can imagine those coordinates making a printer
barf.

jon-Kare & Morten: I am quite sure there is more going on than just some glyphs being placed far off the visible page. If you enter xxx in a cell formatted with a font that usually prints fine and then change the middle x to a font that doesn't print (Helvetica, Fixed, Times,...) all three x disappear from the preview.

(In reply to comment #23)
> jon-Kare & Morten: I am quite sure there is more going on than just some glyphs
> being placed far off the visible page. If you enter xxx in a cell formatted
> with a font that usually prints fine and then change the middle x to a font
> that doesn't print (Helvetica, Fixed, Times,...) all three x disappear from the
> preview.

Yes, because the line height becomes verrrrrrrrrrrrrrrrry large and all the chars on the line shifted down.  Really, it's just it.

Behdad: thanks, that does make sense. So I hope that that bug can be fixed soon.

Behdad, any update on this?

Has been fixed in 1.5.8 (from Jan 30), and will be in 1.6, due to release in a week or two.  No 1.4 release with this yet.  Can you verify the fix please?

commit 3d2144b6af07ca44b6fbf1c96080b7e2b7c0285c
Author: Behdad Esfahbod <behdad@behdad.org>
Date:   Fri Jan 25 17:06:11 2008 -0500

    [cairo-ft] Fix font metrics computation for bitmap fonts and no metrics-hinting
    
    Preivously we were returning NAN font metrics.  Fixed now.  Makes bitmap-font
    test pass again.

Verified (with Cairo 1.5.12).