Is it possible to access Pango GlyphItem fields?

[jmcavanillas]

Hi, I am currently trying to use pango for layout typography and get the data to render text with skia. I think I need to access the struct GlyphItem which is returned by a proc

// The struct in Gtk docs
struct PangoGlyphItem {
  PangoItem        *item;
  PangoGlyphString *glyphs;
};

# pango.nim
# nim bindings I need that returns GlyphItem
proc getRun*(self: LayoutIter): GlyphItem =
  new(result, gBoxedFreePangoGlyphItem)
  result.impl = pango_layout_iter_get_run(cast[ptr LayoutIter00](self.impl))
  result.ignoreFinalizer = true

proc run*(self: LayoutIter): GlyphItem =
  new(result, gBoxedFreePangoGlyphItem)
  result.impl = pango_layout_iter_get_run(cast[ptr LayoutIter00](self.impl))
  result.ignoreFinalizer = true

# pango.nim
# typedefs
type
  GlyphItem00* {.pure.} = object

  GlyphItem* = ref object
    impl*: ptr GlyphItem00
    ignoreFinalizer*: bool
# ....
type
  Item00* {.pure.} = object
  Item* = ref object
    impl*: ptr Item00
    ignoreFinalizer*: bool
# ....
type
  GlyphString00* {.pure.} = object
  GlyphString* = ref object
    impl*: ptr GlyphString00
    ignoreFinalizer*: bool

Is it possible to obtain PangoItem and GlyphString from GlyphItem? How?

Sorry, maybe this is obvious but Im new to Nim and bindings

[StefanSalewski]

Thanks for testing.

Unfortunately I do know not much about Pango, and a short Google search does not really help. Pango seems to be complicated. We should be able to draw pango text on cairo contex with gintro, I think I have seen simple examples for that task somewhere. But advanced Pango stuff may be hard. Generally for most GTK related libs we do not have to access fields of structs directly, as procs are available for that access. In early versions of gintro we generated all the fields for structs, so low level access was basically possible, like myNimObj.impl.fielda. But such field access was generally discouraged in API docs, and nobody used that, so we finally decided to not generate fields any more at all. For Pango that may be different. We can again generate fields for Pango or we can provide special, manually created procs for accessing these fields. Currently I can not do this, because I do not understand Pango well. (And well understanding is needed, as we have to care for memory management -- when we access a field which is again an object, do we make a copy, do we have to increase ref counter, how do we free allocated memory?)Google search provides no examples in higher level languages, so it may be mostly used from C only, and maybe Pango internals are only used by Pango core devs at all. So I would suggest you not using gintro for that now, maybe better use C. (There is also the oldgtk3 Nim module still available, I used that for my NEd texteditor years ago. That module is low level and allows field access.) When you have working C code, we should be able to understand it and do the same from Nim.

Generally I have seen a closer connection of Pango to Cairo than to Skia. Do you have Nim bindings for Skia already?

Generally for Glyph rendering you may contact an active Nim dev called treeform, he seems to work in this area, see

https://github.com/treeform

[jmcavanillas]

This is not a common task indeed, is rather an experiment Im doing. I want to use skia as it can draw using opengl and cario-opengl-backend seems not to be so fast. I got skia working on GtkGLArea with the bindings at https://github.com/mvenditto/nimskia, they are not finished but my plan is to contribute filling gaps if I can.

Skia does not provide text layouting, so the docs says its often used with HarfBuzz, but no examples, no bindings for nim either. I thought using pango might be ok because it gets the active config from gtk, but its not an easy task, at least not common, I only found a Proof of Concept in Rust and nothing more.

I think I will ask treefrom if I can resuse part of https://github.com/treeform/typography as it seems to cover also text rendering in the same module

[jmcavanillas]

I finally managed to get the required data using an alternative approach :D

Actually I dont know whether or not GlyphItem struct should be exposed, but as my use case is possible with current pango bindings and it is unlikely to come across with other use cases I think we can close this issue