gnokii-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fix EMS + concat message, cleanup gnokii.c


From: Pavel Machek
Subject: Re: Fix EMS + concat message, cleanup gnokii.c
Date: Sat, 8 Jun 2002 21:30:34 +0200
User-agent: Mutt/1.3.28i

Hi!

> > > > > Bitmaps know NOTHING about UDH. Don't mess it.
> > > >
> > > > They have to. Whole bitmap is in the UDH. Yep, UDH is then 128+
> > > > bytes. I do not want to encode whole bitmap inside EncodeUDH...
> > >
> > > No. Pavel, please DO read the specifications first. Bitmap is NOT
> > > UserDataHeader.
> >
> > EMS guidelines:
> >
> > picture size is included in IEDL field, and that is in turn included
> > in TP-UDL field. It seems to me like EMS pictures really are in
> > UDH. (Or what's definition of "being in UDH"? Being included in TP-UDL
> > seems reasonable definition...)
> 
> Again. Look at the SMS layout:
> 
> .... | A | .... | B | ... | C | D.... | E .... |
> A is User Data Header Indicator. It's just one bit.
> B is User Data Length. It contains the length of the User Data field.
> There are following cases:
>  - User Data is coded using Default Alphabet (7bit), then UDL is number of
> the septets in the UserData plus User Data Header (including the
> alignment)
>  - User Data is coded 8bit, then UDH is number of the octets in the UD +
> UDH
>  - User Data is cuded using UCS2, then as 8bit.
> 
> Now, if A is set, C denotes User Data Header length, and D is User Data
> Header (it may contain many parts). If A is not set, C and D are not
> present.
> 
> D is User Data. I belive all picutres belong to User Data.
  ~-- E?

No, in EMS case, bitmap is encoded in "D", that's "User Data Header",
not "User Data", AFAICS.

> There's a common way (or few common ways) to encode the bitmap. There's
> some boundary around some of them needed for some SMS schemas. What I
> would like is to move image packing into the boundary into the gsm-sms.c,
> not in the gsm-bitmaps.

I could do that, but it would make code with pretty ugly dependencies.

EncodeUDH would add UDH, but would not know its length. It would have
to ask gsm-bitmaps how big bitmap is going to be. Then it would have
to call it again to actually fill it.
                                                                        Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa



reply via email to

[Prev in Thread] Current Thread [Next in Thread]