LCDproc development and user support list

Text archives Help


[Lcdproc] Character set mapping and other API related (was the } issue).


Chronological Thread 
  • From: joris AT robijn.net (Joris Robijn)
  • Subject: [Lcdproc] Character set mapping and other API related (was the } issue).
  • Date: Mon Dec 3 13:26:01 2001

> > Some driver writers have used character mapping to enhance the
> > displaying of special characters. Many umlaut (") characters are
> > displayed correctly. But there is no guarantee at all.
>
> What code page is asumed then? Latin-1?
> Maybe this would be a usefull information to gather and propagate.

Yes that's right. Mark Haemmerling added a charmap for the HD44780
driver that translates from ISO 8859-1. Is that Latin-1 ? It is not
the 'DOS' charset.

The charmap in use translates all umlaut (") chars to the
corresponding umlaut-chars on the HD44780 and all the other accent-
char to normal chars without accents. It also translates some other
special characters, like beta (=ringel-S).

> What can expect a client (expect for ASCII 7 bits)?

I think only chars from 32 to 126 are guaranteed. And the HD44780
cannot even display a backslash !

> What should other driver try to mimic (MtxOrb???)?

Should we not make it as easy as possible for client writers ? If we
assume _one_ device to be the best supported device I think we'll get
stuck at some point. If they change the charmap for example, like
CFontz recently did.

> > > CrystalFontz Rom V2 support a scroller line widget (see the web site).
> > > This would be possible too by software on a MatrixOrbital LCD and many
> > > other.
> > > But to support that we need to change the API (hint hint hint).
> >
> > What parameters should we need for the call ?
>
> A scroller is a bit like a string,
> except that the string we send is bigger than the space were
> we want to print it...
> So something like (x,y,lenght,string) should be OK
> [No warping please]

What is warping ?

Is the length necesary ? Can we not just place a zero terminated
string there ? Or do we need to be sure that we're able to use char 0
in the string ? You cannot transport the 0 char through the widget
language in a string anyway, isn't it ?

> Another issue is that the driver need to receave some kind of a "beat"
> to be able to "move" the scroller on the LCD.
> This is kind of a silent _heartbeat or IBM PC BIOS ticks interupt.
> That way driver don't need to implement "alarm" mechanisme.

You can do it in flush. Screen should be flushed every tick...

> Now for the API, we may want a bit more, like style...
> Start shifting on the left
> Start shifting on the right
> Continuous shifting (bouncing shifting)
> Or restart from the begining (Left or Right) when we reach the end.
> Complete char or with custom char to make smoth shifting like
> CrystalFontz
> And a speed
> How many ticks before we move a complete char?
> And delay
> When do we start shifting (after how much time to let peaple read the
> begining)?

Should we really put all this in the API ? That means that a widget
is geting stored in the driver, and I don't know if that is good.
Drivers are also getting quite big like this.

> > I'm working on it. It's a damn lot of work :) I've already decided to
> > postpone the modification of the hbar/vbar function for now. It seems
> > the lcdproc protocol also uses pixels, so we need an extra conversion
> > anyway :(
>
> We have a momentum on this mailing list.
> Developper are arround and working.
> So we need to avoid posponing too much or it would be too late.
> What help do you need?

Oh that's great. I've now completed the transition of the API and the
curses and text drivers (without hbar/vbar, also wid and hgt still
exist). I will now start with wid/hgt and other drivers. But for the
hbar/vbar a lot needs to be done. Everything needs to be converted
from the pixel based stuff that is used in the widget language. Also
new features may be supported for the bars. Should we really do this
now ? Or should we wait with this for the next widget language
upgrade... Can you have a look at it ? Should I send you my current
(BIG) diff ?

Joris

--
Joris Robijn
<joris AT robijn.net>
Home: 053 4311 553
Mobile: 06 288 41 964

// To understand recursion, we must first understand recursion




Archive powered by MHonArc 2.6.18.

Top of page