X11 fullscreen

[Russell Shaw]

Nicolas Mailhot wrote:
> 
> Le Ven 29 janvier 2010 00:53, Russell Shaw a écrit :
> 
>> One can make their own widget libraries based on Xlib, then write apps
>> using the libraries. Nothing hard about that ("hard" is relative;)
> 
> On the text processing front, hard is not relative. Working solutions are
> quickly being reduced to pango or qt, with pango and qt sharing components
> (harfbuzz) because they can't really cope alone.

They don't fit my idea of efficient maintainable code.

> Modern text processing is *very* hard. English speakers usually don't realize
> it till they're flooded with bug reports from non-English speakers (and,
> probably soon, reports by English speakers, as support for advanced latin
> typographic features is added to pango/qt).
> 
> If you want any proof, just check the OpenOffice.org bug tracker. They've not
> replaced their legacy text stack with pango yet, and get new text bug reports
> almost every day. (Not that OO.o is especially worse than other apps of the
> same age, but it's a heavy-duty app so people do report bugs instead of
> cursing privately).

I've looked at pango. Totally undocumented in how it works and how to use
it last time i looked. I might understand just looking at the source now.
It is really far too much code for what is required. I really dislike anything
connected with GObject anyway.

The right way is to make each font a smart font that is simply a C library
plugin. Feed in a run of UTF-8 + language/script tag + featuresettings and get
out an array of clusters for rendering. A family of font plugins for japanese
can use a jap-specific contextual rendering library, and a family of font 
plugins for hangul can use a hangul-specific contextual rendering library.
A creator of an english font file should need to know nothing about non-
english rendering. A widget-writer using a smart-font plugin should only
need to follow simple generic bidi and linebreaking algorithms. The smart-
font plugins can have an api for setting features. All this requires ditching
current font files, but i'm ok with that. I'm sure pango+freetype+fontconfig
does most of this in some roundabout kind of way i really can't stomach.
I can't even stand the XML configuration of fontconfig. I *really* dislike XML
for anything other than a file interchange format.