[prev in list] [next in list] [prev in thread] [next in thread] 

List:       poi-dev
Subject:    Re: HSLF TextProp refactoring
From:       Nick Burch <nick () torchbox ! com>
Date:       2007-01-16 15:31:06
Message-ID: Pine.LNX.4.64.0701161503300.3832 () localhost ! localdomain
[Download RAW message or body]

On Tue, 16 Jan 2007, Yegor Kozlov wrote:
> 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.

Sounds good

> (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.

Yup, we'll need to fix that. It'll need to know what properties there 
might be, and in what order they need to come from

> (b) TextPropCollection should be aware of potential properties. I mean 
> the list of potential properties should be a class member.

Makes sense, and helps with the above. I think we should probably have one 
class, holding a static list of char and para base properties, for both 
StyleTextPropAtom and TxMasterStyleAtom.

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

Go for it

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

Yup

> (e) Eliminate subclasses of TextProp.

I don't think we should. They do have different behaviour, and it's 
probably a good thing to keep that behaviour with them. I'm not sure that 
that logic is best placed elsewhere, since it's quite linked to the 
TextProp.

> (f) Eliminate use of TextProp.clone().

We need to be able to say "I want a new one like that, to put my own data 
in", when building the list of properties, and adding new ones. I guess 
one alternative is to have

   TextProp - definition of the property details. Has size, name and mask.
               Only need one for each property
   TextProp.TextPropValue
     inherits from a given TextProp for name, size, mask etc. Has its own
      value. You create one of these every time you need to hold a value
      for a TextProp

So, one TextProp per property, and one TextPropValue for every occurance 
of the property. No more icky clones, and it'll make doing the static list 
of possible TextProps much simpler. Does that sound more like what you had 
in mind?

> (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)

Sure. Do you happen to know if those two have a pair of 
TextPropCollections (char and para), or do they just have the one? (It'll 
potentially affect how we store the static list of possible properties)


> 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:

Sounds like a huge task, but a great one if you can pull it off!

> - 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.

What'd be cool is if we can figure out the OLE calls to have powerpoint 
fire up, load a single sheet ppt file, export to png, and close down. That 
way, we can do evil things like itterate through the different possible 
values, and then look at the resultant pngs later to see what changed

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

One day, when I have a spare week, I keep meaning to write a ppt -> s5 
converter with hslf. I'm sure either of them will be good ways to identify 
things that are hard to do with hslf

Nick

---------------------------------------------------------------------
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/

[prev in list] [next in list] [prev in thread] [next in thread]