pangocairo ➫ pangovkvg? about vkvg

[Rubo3]

We can use this issue to coordinate on the development of this integration.

[Rubo3]

If the glyph API uselessly complicates vkvg, then it's "just" a matter of finding a way for Pango to render text without that API.

[Rubo3]

It's hard to tell now, since at the moment I can't even get a trimmed down version of pangovkvg to compile...

[Rubo3]

At long last, it compiles. Now I can test the features. In the repository I have added an example Makefile which takes care of the needed files and compiler flags.

[jpbruyere]

For sure, pango can do higher level shaping, this would be great.

[jpbruyere]

Note that I never used pango, even if I knew that it was able to output full text frame. Also Harfbuzz is part of vkvg core lib (optional).

[Rubo3]

Here https://github.com/Rubo3/pangovkvg I am working on this port, in the README I added some notes on what (I think) is missing. Currently I ported some enums and some structs (I mean I translated them from cairo_* to Vkvg*, I haven't written any new structs yet).

[Rubo3]

I see many functions require cairo_font_type_t, which can be one of CAIRO_FONT_TYPE_TOY, CAIRO_FONT_TYPE_FT, CAIRO_FONT_TYPE_WIN32, CAIRO_FONT_TYPE_QUARTZ, CAIRO_FONT_TYPE_USER. What shall we implement? Also, Cairo has FreeType-specific headers and source files, should we do the same?

[jpbruyere]

That's a very good question. For now we have Freetype or stb_true_type as a compile option, this would be nice to implement also signed distance field font systems. For now vkvg does not discriminate font type, and I didn't felt the need to do so, maybe take some time on the question. I known that clear type native on win could achieve better polished output. Also freetype implementation in vkvg is quiet raw, cairo goes far more in details between options, I don't know if we should go that way, I want to keep things simple, having only font discimination between (bitmap, vector, sdf), not between font backends (quartz, win32, etc...)....

[jpbruyere]

Also cairo implemented win32 native fonts system surely to be able to compile without freetype on win platforms. We could have a native win32 font system implementation as a compile option but I think it should be transparent for the api.

[Rubo3]

I want to keep things simple

I like to keep things simple, so maybe we could afford an API change. Actually, on the public PangoCairo API, there are just two functions which use cairo_font_type_t, pango_cairo_font_map_new_for_font_type (implemented here) and pango_cairo_font_map_get_font_type (implemented here). What should we replace cairo_font_type_t with?

I think it should be transparent for the api.

So should we avoid multiple run-time backends and use the compile-time one?

[Rubo3]

Since there are a lot of things to implement, I thought it would be a good exercise to port the functions used by a program I am studying (weston-editor): pango_cairo_create_layout, pango_cairo_update_layout and pango_cairo_show_layout (still a lot under the hood). Some Cairo functions and structures which are currently missing in Vkvg can be easily implemented, but others need careful thought. Specifically, how should we implement _cairo_font_options? For example, does cairo_antialias_t correspond to the VkSampleCountFlags passed to vkvg_device_create? Also, some functions need cairo_glyph_t, which correspond to vkvg_glyph_info_t. Why did you choose to make it private? (Just asking, maybe it could be useful to make it public, maybe not)

[jpbruyere]

There, I made a conversion antialias->samplecount: https://github.com/jpbruyere/vgperf/blob/master/src/vkvg/common.c#L21
glyph_t has been quickly implemented to have stb_trutype implemented, we could think to make it public, but for harfbuzz, what overhead will it have...

[jpbruyere]

weston_editor is not really an editor, it's just some piece of code to output one single line of text as a sample app. I've made some complete editors, and I implemented in vkvg what I needed to replace cairo by vkvg in my apps: see https://github.com/jpbruyere/CrowEdit

[Rubo3]

There, I made a conversion antialias->samplecount

see https://github.com/jpbruyere/CrowEdit

Great, thanks!

but for harfbuzz, what overhead will it have...

I'm sorry I'm not aware of this, what overhead will it have?

weston_editor is not really an editor

That's true, but I am using it as an exercise to study Wayland, Cairo and Pango and as a base to make a text editor.

[Rubo3]

There, I made a conversion antialias->samplecount

Compared with Cairo, I don't see equivalents (maybe I'm wrong or there are other ways to implement them) to CAIRO_ANTIALIAS_GRAY and CAIRO_ANTIALIAS_SUBPIXEL, the latter being related to another two components of _cairo_font_options: cairo_subpixel_order_t and cairo_lcd_filter_t. For the moment we could set them to *VKVG_*_NONE, but should we implement them?

[jpbruyere]

developping pieces for each levels of the desktop graphic stack, gives a general idea of what's important, and helps to put at each levels good api's... vkvg has freetype lcd filter option as a compile option, but I have to double check it's not broken with all the recent changes. Selecting font filter is a global OS option in general...high dpi device no longer need lcd filter...

[jpbruyere]

The most important task on the vkvg font system I see now is fully implementing harfbuzz text direction.

[Rubo3]

developping pieces for each levels of the desktop graphic stack, gives a general idea of what's important, and helps to put at each levels good api's

So true. Then should we get rid of cairo_lcd_filter_t? What about cairo_subpixel_order_t?

[jpbruyere]

will lcd font filtering be still relevant with future harware....?

[Rubo3]

I guess the answer is no. I only recently started to learn these concepts, so I don't know much, that's why I ask silly questions, I'm sorry.

[jpbruyere]

Having lcd or not as a runtime option is not an easy task to implement in vkvg. lcd fonts are cached in rgb textures, non lcd are cached in single chanel textures. handling both as a runtime option is quiet some work to do....

[Rubo3]

Ok, thanks for the explanation. I'm removing them from pangovkvg. And what about cairo_hint_style_t, cairo_hint_metrics_t and cairo_round_glyph_positions_t? Are they needed in vkvg?

[jpbruyere]

this should be handled by harfbuzz I guess, there some discussions on hinting problems with latest pango-harfbuzz online....

[jpbruyere]

hinting should be internal anyway...

[Rubo3]

So cairo_font_options_t should be nuked.

[jpbruyere]

For now I don't see a good reason to implement further details of font option, but I'm working on multithreading, and I will maybe come back to this later....for now you can go along without....

[Rubo3]

Fine, thank you.

[Rubo3]

Hi, I updated the pangovkvg repo. Just an informative note: from the compiler warnings I see we currently miss some functions related to the scaled font and font options structs, which still need be removed from pangovkvg and an alternative be found, then we miss font face creation and destruction, vkvg_pattern_get_rgba, vkvg_user_to_device_distance, and some functions related to text, namely vkvg_text_path, vkvg_glyph_path, vkvg_show_text_glyphs, vkvg_show_glyphs.

[Rubo3]

Actually, from the docs, cairo_show_text_glyphs is an advanced version of cairo_show_glyphs, and if the target surface doesn't support it, it acts like cairo_show_glyphs.

[jpbruyere]

I don't known if the glyph based api really makes sense...

[jpbruyere]

If this api shows a real added value, than we can implement it...

[Rubo3]

It seems I don't get anymore warnings nor errors! It still doesn't compile though, I get undefined references on pango_fc_font_map_* functions, I updated the readme with the steps to reproduce.