The algorithm for signing a 7bit 2's complement value is cool, but i am
confused as to select which approach from the 2 given below.
let me consider an example, say byte x = 3; -> 00000011
now x = -3 will be ->
11111101 (as per the usual representation of negative values)
Ist approach:
if we find the 7 bit value as ->
0000011
then check the 7th bit (Hi bit), its 0 so its a positive 3
if we find the 7 bit value as ->
1000011
then check the 7th bit (Hi bit), its 1 so its a negative 3
2nd approach:
if we find the 7 bit value as ->
0000011
then check the 7th bit (Hi bit), its 0 so its a positive 3
if we find the 7 bit value as ->
1111101
then check the 7th bit (Hi bit), its 1 , also its similar to the
representation of negative values for primitive data types, so its a
negative 3.
if we are going for the wrong approach from what actually was meant by
Microsoft, then sure its disaster.
Thanks & Regards
Praveen
Praveen Mathew
"Ryan Ackley" <[EMAIL PROTECTED]>
31/07/2003 01:01
Please respond to "POI Developers List"
To: "POI Developers List" <[EMAIL PROTECTED]>, "Praveen Mathew"
<[EMAIL PROTECTED]>
cc:
Subject: Re: HWPF queries
> For the sprms 0x8,0x3f i have done some bit manipulations
> considering the facts : the 3 byte "param" which we pass as an int
> will be having the 0th byte at the low order and the rest of the
> 1st 2nd 3rd bytes towards the high order of the "int".
> The >>> operator will fill in the vaccant spaces at the left with
> 0's & not 1's.
> Please verify them for their correctness when you have time
> Regarding the sprmCSizePos(0x3f), I didnt understand the way
> "cInc" is applied as newCHP.setHps(Math.max(newCHP.getHps() +
> (cInc * 2), 2));
If you can't understand it, just re-write it because I do not understand
what I was trying to do either.
> The spec refers to some index in the font size array to determine
> the new hps for a run. is this the rgftc[] array. Why r you maxing
> with 2. The spec says to do certain manipulations with the font
> size array indexes, I am confused!!
I don't know where this array is, I think thats why I just came up with
some
kind of hack.
> The spec tells to handle 2 conditions for the parameter (+ve &
> -ve).
> How could this be possible, since we are taking the 7 bit twos
> complement number, i.e the 7 bits towards the high order of the
> byte.
> We will get a sign only if we take the whole 8bits including cInc
> & fAdjust, but then the value is 8bit 2's complement .
> If we take only 7bits as specified ,then always the value will be
> +ve.
It is possible to come up with a twos complement. Use this algorithm to
convert a 7-bit twos complement to an 8-bit twos complement:
if ((7bit & 0x40) > 0) // look for sign bit
{
7bit = (byte)(7bit | 0x80)
}
> One last querry.
>
> In the unCompressProperty(), you are passing a parametr "doIstd",
> which is hardcoded to TRUE now . what is its significance?
Don't remember...
> ___________________________________________________
> Download the hottest & happening ringtones here!
> OR SMS: Top tone to 7333
> Click here now:
> http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
