poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Praveen Mathew" <prmat...@in.ibm.com>
Subject Re: HWPF again
Date Wed, 25 Jun 2003 05:56:35 GMT
Thanks Ryan for your detailed explanations

Thanks & Regards
Praveen

Praveen Mathew
IBM Software Labs,Airport Road,
Bangalore - 560 017,India.
Ph : +91- 80 - 504 4609 (Direct)
       +91 - 80 - 5262355 Extn: 3609
Email: prmathew@in.ibm.com




"Ryan Ackley" <sackley@cfl.rr.com>
24/06/2003 19:35
Please respond to "POI Developers List"

 
        To:     "POI Developers List" <poi-dev@jakarta.apache.org>
        cc: 
        Subject:        Re: HWPF again

 


----- Original Message ----- 
From: "Praveen Mathew" <prmathew@in.ibm.com>
To: "POI Developers List" <poi-dev@jakarta.apache.org>
Sent: Tuesday, June 24, 2003 8:07 AM
Subject: Re: HWPF again


> Ryan,
>
>              According to spec an STTBF  has 3 shorts followed by the
String and extra Data following it. It also
> says that all the pascal strings are concatenated one after another 
until
the length of the STTBF
> recorded in the FIB is exhausted ( lcbSttbfffn).
>
> What I understand is STTBF is one single BLOCK in table Stream, with the
> small header (3 shorts), & then Strings (font names) concatenated to 
each
> other.
>
> I suppose this should be implemented using an array of Strings which has
> 1. initial byte storing the no: of characters in the string excluding
> itself
> 2. last 2 bytes(short)  having extra data for that string.

An STTBF and STTBFFFN are completely different because the STTBFFFN uses 
FFN
structures instead of Strings. So the first 3 shorts are there but instead
of Strings you have FFN structures. If you do create an STTBF class I 
think
it should use byte arrays instead Strings so it can handle arbitrary data
and not just Strings.

> My doubt:
> in the header I asumed a short  indicating the size in bytes of the 
extra
> data stored ( not able to find which string's data its refering?) , is 
it
> correct? or is it the short after each String storing the extra data ?

I believe the way you have done it is correct.

> In case of Fontable i,e sttbfffn, we should replace the Strings with FFN
> structure acc to spec.
> but the spec of FFN structure says that it has some more header fields.
> My Doubt:
>          is the XCHAR[] storing 2 strings i,e Main font & alternate font
> concatenated to each other?

Yes, but both names are zero terminated. So there will be '\0' character
between the Main and alternate font. XCHAR[] is the same as char[].

> also 65 is the limit for these 2 combined??

Yes, but I'm not sure if this is 65 bytes or 65 double-byte chars.

>         is  cbFfnM1 the total no of bytes including the XCHAR[] minus 1 
??

I believe so.

>         is ixchSzAlt  (the index) always 1 since XCHAR[0] is main font
> XCHAR[1] is alternate font?

No, I believe this is the index in XCHAR[] where the alternate font 
starts.
XCHAR[] is an array of characters not Strings.


> Lastly  for STTBFFFN we may have to use an array of FFN rit??

Yes.

> Also how will we track the end of STTBFFFN ??
> is it using lcbSttbfffn ???

Yes.

Keep asking me questions no matter how small. A lot of times I will step
through the code with a debugger and it makes some things clearer.

If you want to step through your FontTable class you need to get my latest
update from CVS. Add the following line to the end of the HWPFDocument
constructor:

FontTable ft = new FontTable(_tableStream, _fib.getFcSttbfffn(),
_fib.getLcbSttbfffn());

There is a main function in HWPFDocument whose only argument is Word file.
Just step into the above line of code.

Keep asking questions!

Ryan



---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-dev-help@jakarta.apache.org




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message