Hi Christian,
On Sat, Apr 10, 2010 at 05:46:48PM +0300, Christian Vogel wrote:
But if we want to do it proper, I have a few question
to you and the list:
- If we stick to multiple-of-8-high fonts (at least on the C128) we
can just blindly write at the proper location. The C155 (?) might
have different restrictions. Is this ok or should we try to support
arbitrary sized fonts?
we need arbitrary sized fonts :(
- If we want to support arbitrary sized fonts, we
either should buffer
the display in RAM (might be wasteful on high res color displays?)
or read/modify/write over i2c (might be slow, occupy the bus for too
long). What's your opinion on that?
yes, we need a memory frame buffer that is periodically synchronized (if
any changes have happened) to the real device by means of a low-priority
task.
- Which font-encoding should we use? I know that GSM
03.38 specifies
the encoding used for SMSs, but should we stick with that for
on-screen output? It's not ASCII compatible regarding []{}\...
I think we should use ASCII for screen output despite what the GSM
standard alphabet does. libosmocore already has conversion functions I
believe.
Note:
<steve|m> in IRC told me that prom is probably already working on that?
Is he reading the list? prom, can you confirm?
He's reading the list and the plan was to commit his unfinished code to
a branch in the repository.
OK, I agree with that. Btw: fixing the topmost line in
the 8x8 font
will have to be done by whoever contributed the 8x8 font in the
first place :-)
ah, ok, that would be me. I still have the perl script somewhwere that
was used to generate the code.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)