poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yegor Kozlov <ye...@dinom.ru>
Subject Re: HSLF TextProp refactoring
Date Tue, 16 Jan 2007 10:25:38 GMT
Nick,

I'm glad you started this thread. We learned a lot about all this style stuff since the first
version of StyleTextPropAtom
and with this knowledge in mind the things can be greatly improved.

Let's not rush with it. I already have experimental code. As soon as it gets a stable shape
I will share it and 
we will discuss.

First I will state what I don't like in the current implementation:

 (a) The logic in TextPropCollection.addWithName is wrong.
It relies on the ordering of properties by mask value and in the light of the recent changes
it is wrong. 

 (b) TextPropCollection should be aware of potential properties. I mean the list of potential
properties should be a class member.
 There shouldn't be direct references to StyleTextPropAtom.characterTextPropTypes and StyleTextPropAtom.paragraphTextPropTypes.

 (c) Use Iterator to access LinkedList items. Don't use LinkedList.get() or switch to ArrayList
if you need to you List.get(). 

Ideas for refactoring:
 (d) Keep static constants in one class. I mean to collect all known text style properties
and put them in
model.TextProperties class. 

 (e) Eliminate subclasses of TextProp. 
 (f) Eliminate use of TextProp.clone(). 

I'm not sure about (e) and (f). The "pro" argument is that BitMaskTextProp is plain TextProp
by nature.
The code to interpret the bitmask value (e.g. to get/set bits) can be in TextRun or in RichTextRun.

Also I didn't like the TextProp.clone() logic from the beginning. Maybe it's time to improve
it?

 (g) Make sure the design is flexible. It's going to be more text atoms: 
  - TextRuler. Stores user's ruler marks.
  - extended format record which stores info about numbered lists.
  (it's not part of StyleTextPropAtom)

P.S. If time allows, I'm going to create a set of examples how one can render ppt slides into
Java graphics.
I mean a set of simple examples demonstrating how to read shape and text properties using
HSLF API and translate them into Java2D calls.
I want to do it for the following purposes:

 - better understand what all these style props mean. I know what bold, italic and underlined
mean.
 But what is stored in asian_or_complex or in para_unknown_6... ? Do you know? I think if
we render a slide into JPEG and compare it with what we see in PowerPoint it may give us a
hint.

 - Converting ppt slides into images is a common question in poi-user. I'm sure it's impossible
to create a 100% rendering engine but simple slides can be rendered pretty close to the originals.

 - Better understand how to polish HSLF API. Which of the
 character/paragraph accessors are missing? What else do we need to add?

Yegor

NB> Hi All

NB> Just a heads-up that I've done the easy bit of the HSLF TextProp 
NB> refactoring. I've moved the definitions for TextPropCollection and 
NB> the TextProps into model.textproperties. All the tests still pass.

NB> Next up, we should probably shift some of the logic for dealing with 
NB> TextProps out of TxMasterStyleAtom and StyleTextPropAtom. While we're at 
NB> it, we can probably make TxMasterStyleAtom and StyleTextPropAtom more 
NB> similar. However, it'll require some thought on the best way to do all of 
NB> this.

NB> So, any suggestions on the best way to refactor this lot appreciated :)

NB> Nick

NB> ---------------------------------------------------------------------
NB> To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
NB> Mailing List:    http://jakarta.apache.org/site/mail2.html#poi
NB> The Apache Jakarta POI Project: http://jakarta.apache.org/poi/


---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
Mailing List:    http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/


Mime
View raw message