Re: [Mlterm-dev-en] mlterm, tibetan, and bitmap fonts?

[MINAMI H. <mi...@mi...>]

On Wed, 2006-03-08 at 03:32 -0500, Rich Felker wrote:...

> > With old x core font, I don't think we can use glyphs outside of
> > Unicode.
> > 
> > Do you think we can force to use Xft?
> 
> My question was about _bitmap_ fonts, which are totally outside the
> domain of Xft. This is a terminal, not a typesetting system. High
> quality scalable fonts have their place, but tiny character-cell
> systems is not one of them, IMHO.

Using Xft is not a mechanism to handle anti-aliased/scalable fonts.
Xft *can* handle embedded bitmap glyphs.

So what I care was about the overhead required to use Xft.
Does Xft work for you with acceptable load? 

> > The problem is, mlterm can't know whether an application running on it
> > knows Tibetan or not. When both of mlterm and the application perform
> > conversion, the result will be horrible. But some problems also occur
> > if none of them cares about combined characters.
> 
> Conversion? There is no conversion, and nothing at all
> Tibetan-specific. The above applies to all combining characters
> equally, in all scripts including Latin.

I agree processing of combined chars are not Tibetan specific.

But it means most existing console applications do not care about
combining characters including Latin's ones.
If you want to make such programs work on mlterm, you may need
some tricks like sending a few, instead of one, "^?" when BS key
was pressed.  


> > > > - What should we do if part of combined character was overwritten? 
> > > 
> > > I don't think this is possible. The terminal control codes to move to
> > > a position are based on character cells, not characters, right?
> > 
> > There are no standard to handle combined characters on terminal.
> > So an application may be implemented in either way. 
> 
> Any terminal implementation that uses character-count positioning
> rather than character-cell positioning is hopelessly broken for both
> wide and combining characters..


Not really. (Maybe-good) old days when a real terminal was developed,
everyone can believe that character-count ==  character-cell position.
So there's no standard for terminals describes about how to count 
characters in column.
Since a emulator is not required to do more than what it emulates did,
we can't blame a terminal emulator for it is not conforming particular
specs.



> > > On the other hand, what happens when you overwrite just half of a cjk
> > > doublewidth character?
> > 
> > If the application is wise enough, entire character will be erased.
> > Otherwise, we see garbage.
> 
> I think you mean the terminal, not the application..

Ah yes, form my point of view, a terminal emulator is
nothing but an application :)

regards,