Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

character cell fonts and combining characters?

2 views
Skip to first unread message

Rich Felker

unread,
Jan 21, 2006, 1:29:50 PM1/21/06
to
i'm facing a problem with the seeming lack of any way to encode
correct glyph-combining information in character-cell bdf bitmap fonts
for use in x. i've heard of people doing horrible hacks like just
making the combining characters zero-width and offset to the left of
the cell, so that they naturally overstrike, but this has several
major problems that cannot be solved:

- it only works for programs that render a whole string with x, not
actual character-cell based programs that will draw and redraw
characters in their respective cells, i.e. terminal emulators.

- it does not allow vertical stacking of combining marks, i.e. if
there's more than one they'll just overstrike one another and become
illegible.

- it does not account for the fact that the base character may have to
change form to accomodate the combining characters (either due to
conventions of the script itself or limitations of the font size,
e.g. uppercase latin characters having to become shorter to make
space for accents in small fonts).

what i would like is a standardized system for (ab)using or extending
the x11 font metrics to store the data on how characters should
combine. unfortunately i don't yet understand the x font system well
enough; however i believe that the width/ascent/descent/etc
information, which are otherwise not very useful on combining
characters, could be used to store the offsets for rendering the
combined character in the correct position relative to the base
character or the previous combining character. this rendering could be
performed one-character-at-a-time by the application, and possibly
also by an extension to the x server.

as for alternate glyphs for the base character when it's used in
combinations, i don't know what to do since x seems to have a shortage
of glyph numbers already.

the only alternative i know is for unicode terminals to ignore the
whole x font system and load their own pixmaps and data tables of
combining information. i don't think anyone particularly likes this
solution, but perhaps i'm mistaken.

other ideas...?

rich

--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/


0 new messages