DO NOT REPLY [Bug 10935] - Sheet.getColumnWidth sometimes doesnt return the correct width

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10935

Sheet.getColumnWidth sometimes doesnt return the correct width





--- Additional Comments From [EMAIL PROTECTED]  2002-07-18 04:39 ---
Created an attachment (id=2393)
TestHSSFSheet patch for column width test. Please commit both patches

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10935] - Sheet.getColumnWidth sometimes doesnt return the correct width

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10935

Sheet.getColumnWidth sometimes doesnt return the correct width





--- Additional Comments From [EMAIL PROTECTED]  2002-07-18 03:46 ---
Created an attachment (id=2390)
Patch to Sheet.java

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10935] New: - Sheet.getColumnWidth sometimes doesnt return the correct width

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10935

Sheet.getColumnWidth sometimes doesnt return the correct width

   Summary: Sheet.getColumnWidth sometimes doesnt return the correct
width
   Product: POI
   Version: unspecified
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: HSSF
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The Sheet.getColumnWidth and Sheet.setColumnWidth if test within the for loop 
is not right so when the column lies within a columninfo range it doesnt return 
the correct columninfo object

Patch which corrects will be supplied immediately.

Patch to the unit tests to follow, so that the problem doesnt happen again.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: GCJ and Office Suite Filters

[Andrew C. Oliver]

/>> Well how well does GCJ work?  /
>
>GCJ is mostly complete expect for some AWT stuff.
>
>Actually, we have thrown out the idea of using the OpenOffice filters. 
>Right now, to implement MS filters for KOffice it comes down to:
>
>* wv2 (rewrite of wvware, not complete, only for MS Word)
>* POI HDF and HSSF for MS Word and MS Excel
>
>Any thoughts on using wv2 vs. POI?

Well if folks are willing to contribute then I'd go for POI.  Wv2 has been around a 
lot longer
and hasn't really gone IMO that far.  (but I've not looked real recently)

/>> * Andy uses Gnome ;-)/

> It would be great to see POI used for Gnome Office (Abiword and Gnumeric),
> as well as KOffice.
>One issue is that the Gnome office uses the GPL which is incompatible with 
>the Apache license.

That is Richard Stallman's belief.  IANAL but its not my belief.  So basically:
work on POI is APL and can be used in KOFFICE, we can't use KOFFICE in POI.  (which is 
fine)

/> I'm totally for this and I'll do everything in my power to help!  /

> Great!  The license issue has been brought as a reason why POI can't be 
> used with GPL Office suites.  It would be really great if we could sort 
> out these license issues so that POI was compatible with the GPL.  I was 
> thinking of e-mailing the general-jakarta list to ask for help with this, 
> and if I could get your approval for allowing POI to be used with the GPL, 
> that would be great, because you have much better connections to the 
> Jakarta project.

Well lets start off with this: We're not GPLing anything.  Next, there isn't IMHO
a problem, other than anyone working on POI will have to agree to release their code
under ASL.  Read this:

http://www.apache.org/foundation/licence-FAQ.html#GPL

> Also, I'd like to help with the HDF project, and I was wondering if I 
> would have to purchase Windows/Office?  I'm currently a happy Linux user, 
> and it would be great if I could just use a free Linux solution like 
> OpenOffice Word filters to hack the Word format, but somehow I have a 
> feeling that I might have to get Windows.

I use Linux with CrossOver Office.  Its $50.  I already had a version of MS Office 97.
Office runs on linux better than does OpenOffice!  (faster!) 

You should be able to pick up a legal copy of Office 97 pretty cheap I would imagine.  

In conclusion:

1. We're not switching our license, you're welcome to switch yours (why should we make 
our
software anti-commercial?)
2. We don't feel its incompatible, if you do, that is fine.
3. Any code going into POI must be ASL because of the "viral clause" of the GPL
4. I still think this would be really really cool.

-Andy

>Thanks,
>TJ




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Viewer directions

[Andrew C. Oliver]

I don't doubt the methods are all wrong.  Please correct them as you find true and 
supply unit tests and I'll apply them.  The Excel docs are confused on this issue so
I tried.  I have magic formulas to do it in the serializerif you can find a 
rational
correlation in this, please do!


OK will do.

I am trying at the moment to focus on the viewing functionality.

I want to add correct column and row widths to the viewer. I have a problem
at the moment that I am unsure about.

Firstly, I think that the units of measurement for the column widths and
default column widths need to be standardized. The java doc currently states
that the HSSFSheet.getColumnWidth ie 1/256th of a character, the
HSSFSheet.getDefaultColumnWidth is in characters and even worse the
Sheet.getColumnWidth is in twips. 

Note: The HSSFSheet.getColumnWidth calls directly to Sheet.getColumnWidth so
one of those javadoc comments on the return value units is WRONG. But I dont
know which one is ;-)

Secondly, there seems to be a problem with the decoding of column widths.
The statetax2.xls example that I have been using (which came with the
original viewer code but attached for convienence) the column widths (as
reported by the HSSFSheet.getColumnWidth) are:

9106, 4644, 8, 8, 8, 8, 8

Looking at the file in excel the first column is larger (about twice the
size) but the rest are very much the same. I think that the 8's are actually
referring to default column widths. Could it be that what should be returned
by these calls is:

9106, 4644, 4644, 4644, 4644, 4644, 4644

In which case there is either a bug in the decoding of the column widths, or
the Sheet.getColumnWidth call.

Jason



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Resolution 002 - CVS, Unit tests and Tree Pruning

[Andrew C. Oliver]

> Why is that?

Unmaintained code requires more work to get it up and running, sometimes it will
have to be broken in the process.  Sometimes advanced collaboration will be required.

While I trust most everyone whom is a committer's judgement, moving it to the 
scratchpad would constitute a product change and hence would require a consensus 
vote.  This means that in all practicality it would never happen.

I like test-first design for a number of things, especially formulas.  Due to the rest 
of this
checking in a non-passing unit test must be explained.  A good example of the use of 
test-first 
design lets say that these were hard:

SUM(A1:A2)
SUM(A1:A2,B3:B7)
AVERAGE(A1:A2)
AVERAGE(A1:A2,B3:B7)

+ the binary representations to render back for each.

Supposing the matter is complicated you want to map out the inputs and outputs and 
work on a 
complicated issue possibly over weeks and with the help of multiple developers, the 
unit tests
could serve as an increadible guide.  You get half way into #2 and #1 stops working, 
thats 
really valuable, or suprislingly #4 starts working, wow good info!  

Test first works and I'd want to make sure we didn't prohibit it.

And those are my reasons why I'm unwilling to submit this seperately.  

-andy


/> I withdraw the proposal then.  I could only support it in the entirely./
/>/
/> /> Please make any gramatical corrections and signify a//
/> />//
/> /> -1  [ ]  strongly against  state your reason//
/> /> __//
/> /> -0  [ ]  against but not standing in the way//
/> /> +0 [ ]  neither for or against, or abstain//
/> /> +1 [ ]  agree//
/> />//
/> /> -Andy//
/>/
/>/
/>/



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Viewer directions

[JHeight]

Actually just looking at the column widths in excel the second column is
different to the third columns. So i think that the problem may just be the
differences in the units of measurements between default widths and defined
widths

Jason  
> OK will do. 
> 
> Looking at the file in excel the first column is larger (about twice the
> size) but the rest are very much the same. I think that the 8's are
> actually referring to default column widths. Could it be that what should
> be returned by these calls is:
> 
> 9106, 4644, 4644, 4644, 4644, 4644, 4644 
> 
> In which case there is either a bug in the decoding of the column widths,
> or the Sheet.getColumnWidth call. 
> 
> Jason 
> 

RE: GCJ and Office Suite Filters

[T.J. Mather]

On Wed, 17 Jul 2002, Andrew C. Oliver wrote:

> > There is some discussion on the KOffice mailing list about how they are 
> > going to implement filters.  Currently there are two proposals, the first 
> > is to use the OpenOffice file format and re-use the OpenOffice filters 
> > for MS Word, and the second is to use the Apache POI library compiled 
> > under GCJ.
> 
> Well how well does GCJ work?  

GCJ is mostly complete expect for some AWT stuff.

Actually, we have thrown out the idea of using the OpenOffice filters. 
Right now, to implement MS filters for KOffice it comes down to:

* wv2 (rewrite of wvware, not complete, only for MS Word)
* POI HDF and HSSF for MS Word and MS Excel

Any thoughts on using wv2 vs. POI?

> * Andy uses Gnome ;-)

It would be great to see POI used for Gnome Office (Abiword and Gnumeric),
as well as KOffice.
One issue is that the Gnome office uses the GPL which is incompatible with 
the Apache license.

> I'm totally for this and I'll do everything in my power to help!  

Great!  The license issue has been brought as a reason why POI can't be 
used with GPL Office suites.  It would be really great if we could sort 
out these license issues so that POI was compatible with the GPL.  I was 
thinking of e-mailing the general-jakarta list to ask for help with this, 
and if I could get your approval for allowing POI to be used with the GPL, 
that would be great, because you have much better connections to the 
Jakarta project.

Also, I'd like to help with the HDF project, and I was wondering if I 
would have to purchase Windows/Office?  I'm currently a happy Linux user, 
and it would be great if I could just use a free Linux solution like 
OpenOffice Word filters to hack the Word format, but somehow I have a 
feeling that I might have to get Windows.

Thanks,
TJ


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Viewer directions

[JHeight]

Title: RE: Viewer directions





OK will do.


I am trying at the moment to focus on the viewing functionality.


I want to add correct column and row widths to the viewer. I have a problem at the moment that I am unsure about.


Firstly, I think that the units of measurement for the column widths and default column widths need to be standardized. The java doc currently states that the HSSFSheet.getColumnWidth ie 1/256th of a character, the HSSFSheet.getDefaultColumnWidth is in characters and even worse the Sheet.getColumnWidth is in twips. 

Note: The HSSFSheet.getColumnWidth calls directly to Sheet.getColumnWidth so one of those javadoc comments on the return value units is WRONG. But I dont know which one is ;-)

Secondly, there seems to be a problem with the decoding of column widths. The statetax2.xls example that I have been using (which came with the original viewer code but attached for convienence) the column widths (as reported by the HSSFSheet.getColumnWidth) are:

9106, 4644, 8, 8, 8, 8, 8


Looking at the file in excel the first column is larger (about twice the size) but the rest are very much the same. I think that the 8's are actually referring to default column widths. Could it be that what should be returned by these calls is:

9106, 4644, 4644, 4644, 4644, 4644, 4644


In which case there is either a bug in the decoding of the column widths, or the Sheet.getColumnWidth call.


Jason
 <> 


-Original Message-
From:   Andrew C. Oliver [SMTP:[EMAIL PROTECTED]]
Sent:   Thursday, 18 July 2002 11:11
To: [EMAIL PROTECTED]
Subject:    RE: Viewer directions


BTW Jason,


Add yourself to the who we are page as a developer and I'll apply the 
patch.  You've made a number of important contributions to the project 
over time and I'd like to see them recognized.


-Andy



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 





statetax2.xls
Description: MS-Excel spreadsheet

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: POI Logo (cc: sam regarding the legal stuff)

[Glen Stampoultzis]

Sounds like a reasonable approach.

+1


> Hi All,
>
> We need to wrap the logo thing up soon.  As it turns out I don't think
> the winning logo is legal.  I got several negative views from folks with
> experience in such matters and basically its enough ammo to shut us down
> for awhile.  We'd probably win a court battle, but that would be well
> the problem.  I'm unable to find an ASF member whom is willing to take
> the matter to the legal body and our advisor is in the middle of the
> ocean somewhere on a sabatical of sorts.  This means, its just up to us.
>
> I move the following:
>
> 1. We disqualify the problematic but popular logo.
> 2. We start voting first for which logos will move to round 2 (you have
> the advice of the general populace as well), each committer can pick 2
> 3. We then vote among those, pick 1.
> 4. We vote among those.
>
> if we get to a dead lock then we'll try adding veto votes.  If that
> doesn't work I've got some dice.
>
> -Andy
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Resolution 002 - CVS, Unit tests and Tree Pruning

[Glen Stampoultzis]

Why is that?


> I withdraw the proposal then.  I could only support it in the entirely.
>
> /> Please make any gramatical corrections and signify a/
> />/
> /> -1  [ ]  strongly against  state your reason/
> /> __/
> /> -0  [ ]  against but not standing in the way/
> /> +0 [ ]  neither for or against, or abstain/
> /> +1 [ ]  agree/
> />/
> /> -Andy/
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: GCJ and Office Suite Filters

[Andrew C. Oliver]

> I posted a little while back on developing C++ port of POI, so that 
> KOffice could use POI to develop filters for Excel and Word.  It now
> appears that developing a C++ port isn't necessary anymore, because it 
> turns out that we can invoke the Java code from C++ using GCJ [1].

Interesting.  I think thats splendid.  BTW, there may one day be a port of POI 
to D (www.digitalmars.com/d)

> There is some discussion on the KOffice mailing list about how they are 
> going to implement filters.  Currently there are two proposals, the first 
> is to use the OpenOffice file format and re-use the OpenOffice filters 
> for MS Word, and the second is to use the Apache POI library compiled 
> under GCJ.

Well how well does GCJ work?  

> The advantage of using the existing OpenOffice filters is that they 
> are already developed for Word as well as Excel.  However, Apache POI 
> seems more suitable in the long term, since the quality of the code seems 
> to be much higher than the OpenOffice filter code.  Does anybody have any 
> thoughts on this?

advantages:

* Higher quality, better documented, more modular code
* Committment to quality, a gazillion unit tests
* Community developed and supported with no funding from Sun et al. (well nothing 
direct
at least, arguably I'm sure Sun helped pay for Apache's servers somewhere, just a 
guess)
* Ultimately, I think we'll get it more correct.

disadvantages:

* POI is a bit fat memory-wise
* We're a bit behind them at the moment I bet as far as support.
* potential problems with GCJ (only a guess)
* Andy uses Gnome ;-)

I'm totally for this and I'll do everything in my power to help!  

Thanks,

Andy


> Thanks,
> -TJ [http://maxmind.com]

> [1] http://gcc.gnu.org/onlinedocs/gcj/Invocation.html



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Viewer directions

[Andrew C. Oliver]

BTW Jason,

Add yourself to the who we are page as a developer and I'll apply the 
patch.  You've made a number of important contributions to the project 
over time and I'd like to see them recognized.

-Andy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Viewer directions

[Andrew C. Oliver]

IMHO, we should complete the viewer part.  Its a bigger demand.  Not that edit
isn't in demand, just viewer is a bigger deal.

-Andy


Andy,

Geez stop it youll make be blush! 

The trivial ammount of work that I have done to the viewer cant be compared
with the massive library that has been built under it. All you guys deserve
a medal.

Anyhow back to business, Is anyone interested in making the Viewer able to
edit the spreadsheet? (Ok I know that is a contradiction in terms) 

In my development area I can currently add, delete and rename sheets and I
am about to add editing functionality to the cells.

Should I worry about this or concentrate on the presentation of the viewing
functionality? What do others think? What is currently missing in terms of
the viewing functionality?

Thanks

Jason




/> -Original Mes/



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

POI Logo (cc: sam regarding the legal stuff)

[Andrew C. Oliver]

Hi All,

We need to wrap the logo thing up soon.  As it turns out I don't think 
the winning logo is legal.  I got several negative views from folks with 
experience in such matters and basically its enough ammo to shut us down 
for awhile.  We'd probably win a court battle, but that would be well 
the problem.  I'm unable to find an ASF member whom is willing to take 
the matter to the legal body and our advisor is in the middle of the 
ocean somewhere on a sabatical of sorts.  This means, its just up to us.

I move the following:

1. We disqualify the problematic but popular logo.
2. We start voting first for which logos will move to round 2 (you have 
the advice of the general populace as well), each committer can pick 2
3. We then vote among those, pick 1.
4. We vote among those.

if we get to a dead lock then we'll try adding veto votes.  If that 
doesn't work I've got some dice.

-Andy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-poi/src/documentation/xdocs news.xml

[acoliver]

acoliver2002/07/17 18:13:55

  Modified:src/documentation/xdocs news.xml
  Log:
  Added the blog of my speech... b booo me
  
  Revision  ChangesPath
  1.4   +4 -1  jakarta-poi/src/documentation/xdocs/news.xml
  
  Index: news.xml
  ===
  RCS file: /home/cvs/jakarta-poi/src/documentation/xdocs/news.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- news.xml  3 Jul 2002 21:13:05 -   1.3
  +++ news.xml  18 Jul 2002 01:13:55 -  1.4
  @@ -24,6 +24,9 @@
   
   
   
  +
  +   http://www.rollerweblogger.org/page/roller/20020715";>Poor Obfuscation 
Implementation. - Blog of David M. Johnson
  +
  
  http://www.jsurfer.org/article.php?sid=322";>
   POI 1.5-dev-rc2 released  - JSurfer
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Resolution 002 - CVS, Unit tests and Tree Pruning

[Andrew C. Oliver]

I withdraw the proposal then.  I could only support it in the entirely.

/> Please make any gramatical corrections and signify a/
/>/
/> -1  [ ]  strongly against  state your reason/
/> __/
/> -0  [ ]  against but not standing in the way/
/> +0 [ ]  neither for or against, or abstain/
/> +1 [ ]  agree/
/>/
/> -Andy/



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 8354] - HPSF should use the org.apache.poi.util.LittleEndian

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8354

HPSF should use the org.apache.poi.util.LittleEndian

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-07-18 00:07 ---
finally!

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Resolution 002 - CVS, Unit tests and Tree Pruning

[Glen Stampoultzis]

> From this point on to prevent further conflict I propose we vote the
> following rules in place.  Please vote to adopt this or not in its
> entirety or I withdraw the proposal.
>
> Rules for Sources within main CVS path jakarta-poi/src/java
>
> 1. Code must be compilable, existing code should not be checked in
> broken if it was not broken before.  Broken is defined as causing
> a unit test to fail or not compile.

+1

> 2. New features must be accompanied by unit tests, patches implementing
> features should be deferred until the accompanying unit test is written.

+1

> 3. It is acceptable to check in a failing unit test before writing a
> feature.  The opposite is not true. (supports test-first design -- keep
> the XP types happy)

-0 I'm not sure why you'd only check in a test and not implement it (unless
maybe you were going to get someone else to do it).  Do the test, implement,
then check it in.

> 4. APIs or subcomponents that have not been worked on in 6 months should
> be moved to the scratchpad.  The exception is any APIs that are mature
> (read/write/reasonably feature complete), are depended heavily upon by
> other active components or are just more or less "done".  (Example: POIFS)

-1:  I would want a vote before doing anything rather than automatically
removing/moving any component.

> Please make any gramatical corrections and signify a
>
> -1  [ ]  strongly against  state your reason
> __
> -0  [ ]  against but not standing in the way
> +0 [ ]  neither for or against, or abstain
> +1 [ ]  agree
>
> -Andy
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[VOTE] Resolution 002 - CVS, Unit tests and Tree Pruning

[Andrew C. Oliver]

 From this point on to prevent further conflict I propose we vote the 
following rules in place.  Please vote to adopt this or not in its 
entirety or I withdraw the proposal.

Rules for Sources within main CVS path jakarta-poi/src/java

1. Code must be compilable, existing code should not be checked in 
broken if it was not broken before.  Broken is defined as causing
a unit test to fail or not compile.

2. New features must be accompanied by unit tests, patches implementing 
features should be deferred until the accompanying unit test is written.

3. It is acceptable to check in a failing unit test before writing a 
feature.  The opposite is not true. (supports test-first design -- keep 
the XP types happy)

4. APIs or subcomponents that have not been worked on in 6 months should 
be moved to the scratchpad.  The exception is any APIs that are mature 
(read/write/reasonably feature complete), are depended heavily upon by 
other active components or are just more or less "done".  (Example: POIFS)

Please make any gramatical corrections and signify a

-1  [ ]  strongly against  state your reason 
__
-0  [ ]  against but not standing in the way
+0 [ ]  neither for or against, or abstain
+1 [ ]  agree

-Andy



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10215] - [RFE] No way to create cell comments with API

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10215

[RFE] No way to create cell comments with API

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|No way to create cell   |[RFE] No way to create cell
   |comments with API   |comments with API
Version|1.5 |2.0-dev



--- Additional Comments From [EMAIL PROTECTED]  2002-07-17 23:04 ---
Folks might want to start voting for bugs.  Some of the ones that are low
priority for me I might fix if masses of people voted for them.  Otherwise its
quite honestly based on the 2.0 vision, my interests, my $business interests$
ones that got many votes might peak my interest.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] HPSF priorities

[Nicola Ken Barozzi]

Rainer Klute wrote:
> Hi POI folks,

Here is where everyone stopped thinking and ranting began.

Just a few notes:

1. [http://jakarta.apache.org/site/source.html]
Simple patches to fix bugs can be committed then reviewed.

NKB says: "If Rainer saw that Andy committed bugged code, he could have 
reverted it immediately"

2. [http://jakarta.apache.org/site/source.html]
Half complete projects should never be committed to the main branch 
of a development repository. All code changes must be successfully 
compiled on the developer's platform before being committed. Also, any 
unit tests should also pass.

NKB says: "Andy should not have committed bugged code"

3. [http://jakarta.apache.org/site/source.html]
The current source code tree for a subproject should be capable of 
complete compilation at all times. However, it is sometimes impossible 
for a developer on one platform to avoid breaking some other platform 
when a change is committed. If it is anticipated that a given change 
will break the build on some other platform, the committer must indicate 
that in the commit message.

4. [http://jakarta.apache.org/site/source.html]
A committed change must be reversed if it is vetoed by one of the 
voting members and the veto conditions cannot be immediately satisfied 
by the equivalent of a "bug fix" commit. The veto must be rescinded 
before the change can be included in any public release.

NKB says: "Rainer could have -1ed Andy's commit and make him revert it 
unless Andy fixed it right away"

5. [http://jakarta.apache.org/site/roles.html]
At times, Committers may go inactive for a variety of reasons. A 
Committer that has been inactive for 6 months or more may lose their 
status as a Committer. Getting access back is as simple as re-requesting 
it on the project's Developer mailing list.

NKB says: "no comment"

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] HPSF priorities

[Niall Pemberton]

Apologies if this has been sorted, I'm not actually on the POI mailing
list - just getting into it.

It seems to me that the org.apache.poi.util.LittleEndian class doesn't cater
the for situation for ClassID as it returns numbers and not byte[] - so if
you use it's methods you still have to convert to a byte[] after.

I think the following version of ClassID should work:

==> ClassID STARTS HERE
<=
package org.apache.poi.hpsf;

public class ClassID {

private byte[] bytes;

public ClassID(final byte[] src, final int offset) {
   bytes = read(src, offset);
}

public final static int LENGTH = 16;

public int length() {
return LENGTH;
}

public byte[] getBytes() {
return bytes;
}

public byte[] read(byte[] src, int offset) {

byte[] dest = Util.copy(src, offset, 24);

int destOffset = 0;
int srcOffset = 0;
Util.copy(readField(src, offset, 8), 0, 8, dest, destOffset);
Util.copy(readField(src, offset += 8, 4), 0, 4, dest, destOffset +=
8);
Util.copy(readField(src, offset += 4, 4), 0, 4, dest, destOffset +=
4);

return dest;

}

public static byte[] readField(byte[] src, int offset, int lth) {

byte[] dest = new byte[lth];
for (int i = 0; i < lth; i++) {
dest[i] = src[offset + lth - 1 - i];
}
return dest;

}

}
==> ClassID ENDS HERE
<=

Niall

> -1 - a more reasonable alternative: quit sulking and help me understand
>
http://jakarta.apache.org/poi/javadocs/javasrc/org/apache/poi/hpsf/ClassID_j
ava.html#ClassID
> (scroll to the method clearly marked REWRITE ME REWRITE ME)
>
> Read this method before you vote!  and if someone other than rainer (who
donen't have time)
> wants to give me a hand in figuring that method out, that would be
appreciated and
> probably
> make this whole argument moot!
>
> Buenos Dias,
>
> Andy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-poi/src/documentation/xdocs/hpsf todo.xml

[klute]

klute   2002/07/17 09:28:13

  Modified:src/documentation/xdocs/hpsf todo.xml
  Log:
  
  
  Revision  ChangesPath
  1.9   +1 -9  jakarta-poi/src/documentation/xdocs/hpsf/todo.xml
  
  Index: todo.xml
  ===
  RCS file: /home/cvs/jakarta-poi/src/documentation/xdocs/hpsf/todo.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- todo.xml  15 Jul 2002 15:18:09 -  1.8
  +++ todo.xml  17 Jul 2002 16:28:13 -  1.9
  @@ -16,18 +16,10 @@
   
  
   
  - Rollback Andy's changes in order to have HPSF working again.
  -
  -
Complete writing the HPSF documentation.
   
   
Write up some junit tests.
  -
  -
  - Use the general POI little-endian classes (see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8354";>bug
  -  8354).
   
   
Add writing capability for property sets.
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] HPSF priorities

[Rainer Klute]

>Thanks.  This may be enough for me to fix the method.  I'll investigate it fur
ther.  Give me a few 
>days as I'm working on something else at this very moment.  (days not months).

I just fixed it. Took me a few hours, though.

Best regards
Rainer Klute

   Rainer Klute IT-Consulting GmbH
  Dipl.-Inform.
  Rainer Klute E-Mail:  [EMAIL PROTECTED]
  Körner Grund 24  Telefon: +49 172 2324824
D-44143 Dortmund   Telefax: +49 231 5349423


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-poi/src/java/org/apache/poi/hpsf ClassID.java PropertySet.java Section.java

[klute]

klute   2002/07/17 09:23:22

  Modified:src/contrib/src/org/apache/poi/contrib/poibrowser Codec.java
POIBrowser.java PropertySetDescriptorRenderer.java
   src/java/org/apache/poi/hpsf ClassID.java PropertySet.java
Section.java
  Log:
  Broken HPSF usage of POI's general little-endian classes fixed.
  
  Revision  ChangesPath
  1.2   +46 -1 
jakarta-poi/src/contrib/src/org/apache/poi/contrib/poibrowser/Codec.java
  
  Index: Codec.java
  ===
  RCS file: 
/home/cvs/jakarta-poi/src/contrib/src/org/apache/poi/contrib/poibrowser/Codec.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Codec.java14 Feb 2002 04:00:58 -  1.1
  +++ Codec.java17 Jul 2002 16:23:21 -  1.2
  @@ -60,6 +60,7 @@
   
   import java.io.*;
   import java.util.*;
  +import org.apache.poi.hpsf.ClassID;
   
   
   
  @@ -137,6 +138,50 @@
   sb.append((char) hexval[(b & 0xF0) >> 4]);
   sb.append((char) hexval[(b & 0x0F) >> 0]);
   return sb.toString();
  +}
  +
  +
  +
  +/**
  + * Converts an int value (32-bit) into its hexadecimal
  + * notation.
  + */
  +public static String hexEncode(final int i)
  +{
  +StringBuffer sb = new StringBuffer(8);
  +sb.append((char) hexval[(i & 0xF000) >> 28]);
  +sb.append((char) hexval[(i & 0x0F00) >> 24]);
  +sb.append((char) hexval[(i & 0x00F0) >> 20]);
  +sb.append((char) hexval[(i & 0x000F) >> 16]);
  +sb.append((char) hexval[(i & 0xF000) >> 12]);
  +sb.append((char) hexval[(i & 0x0F00) >>  8]);
  +sb.append((char) hexval[(i & 0x00F0) >>  4]);
  +sb.append((char) hexval[(i & 0x000F) >>  0]);
  +return sb.toString();
  +}
  +
  +
  +
  +/**
  + * Converts a long value (64-bit) into its hexadecimal
  + * notation.
  + */
  +public static String hexEncode(final long l)
  +{
  +StringBuffer sb = new StringBuffer(16);
  +sb.append((l & 0xL) >> 32);
  +sb.append((l & 0xL) >>  0);
  +return sb.toString();
  +}
  +
  +
  +
  +/**
  + * Converts a class ID into its hexadecimal notation.
  + */
  +public static String hexEncode(final ClassID classID)
  +{
  +return hexEncode(classID.getBytes());
   }
   
   
  
  
  
  1.4   +2 -2  
jakarta-poi/src/contrib/src/org/apache/poi/contrib/poibrowser/POIBrowser.java
  
  Index: POIBrowser.java
  ===
  RCS file: 
/home/cvs/jakarta-poi/src/contrib/src/org/apache/poi/contrib/poibrowser/POIBrowser.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- POIBrowser.java   22 Feb 2002 04:27:18 -  1.3
  +++ POIBrowser.java   17 Jul 2002 16:23:21 -  1.4
  @@ -159,7 +159,7 @@
 new PropertySetDescriptorRenderer());
   treeUI.setCellRenderer(etcr);
   setSize(600, 450);
  -setTitle("POI Browser 0.06");
  +setTitle("POI Browser 0.07");
   setVisible(true);
   }
   
  
  
  
  1.3   +4 -12 
jakarta-poi/src/contrib/src/org/apache/poi/contrib/poibrowser/PropertySetDescriptorRenderer.java
  
  Index: PropertySetDescriptorRenderer.java
  ===
  RCS file: 
/home/cvs/jakarta-poi/src/contrib/src/org/apache/poi/contrib/poibrowser/PropertySetDescriptorRenderer.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- PropertySetDescriptorRenderer.java19 May 2002 18:09:26 -  1.2
  +++ PropertySetDescriptorRenderer.java17 Jul 2002 16:23:21 -  1.3
  @@ -85,9 +85,6 @@
 final int row,
 final boolean hasFocus)
   {
  -
  -throw new RuntimeException("THIS FUNCTION BROKEN -- FIX IT");
  -/*
   final PropertySetDescriptor d = (PropertySetDescriptor)
   ((DefaultMutableTreeNode) value).getUserObject();
   final PropertySet ps = d.getPropertySet();
  @@ -110,9 +107,8 @@
   
   if (ps instanceof SummaryInformation)
   {
  -*/
   /* Use the convenience methods. */
  -/*final SummaryInformation si = (SummaryInformation) ps;
  +final SummaryInformation si = (SummaryInformation) ps;
   text.append("\n");
   text.append("\nTitle:   " + si.getTitle());
   text.append("\nSubject: " + si.getSubject());
  @@ -136,7 +132,7 @@
   
   if (selected)
   Util.invert(text);
  -return p;*/
  +return p;
   }
   
   
  @@ -16

RE: Record Generator

[Laubach, Shawn - TAFB/LAB NCC (SAIC)]

First, I realized that I need to just make them implement an interface.  For
now, I generated the records, modified the output, and then removed the
*record.xml files.  I plan on looking into possibly allowing an implements
clause in the declaration.  This would cover my little problem.  

Last, I don't know how many other records could benifit from something like
this.  If none, then it doesn't make much sense to mess with it further.

BTW, it worked great for making the basic classes.

Shawn Laubach
SAIC - Web Developer
B-1B System Support Management Division
OC-ALC/LAB, Building 3001, Tinker AFB, Oklahoma
dsn: 336-2473  comm: 405-736-2473  mobile: 405-245-9562


-Original Message-
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 17, 2002 9:38 AM
To: POI Developers List
Subject: Re: Record Generator



The record generator is not necessarily appropriate for every record type.

You could modify the code generated if you need to.  Just be careful not to
break the other records.

If you wish to do a one off generation then what you suggest will work.

You might be able to use XML entities to include your common code.  You will
get lots of duplicated generated code but since it's generated this is not
too evil.  Even with this case however you probably want a common interface
yes?  If so you might need to tweak the generator slightly to allow you to
specify a particular interface.

The record generator is a hammer but you might have a screw there instead of
a nail.

Regards,

Glen

PS:  Sorry it took a while to answer you.

> I'm working on margins and need to create records for them.  They all have
> the same structure except the sid is different.  I was wanting to create a
> MarginRecord using the record generator and then sub-class the actual
margin
> classes.  This does not work because of the requirement of needing a sid.
> Is there a way to make it work nicely without a sid or do I need to
generate
> the class, clean it up, and destroy the record file (so it does not get
> overridden)?  Basically, I'm wanting to stay along the lines that the rest
> of the code follows.
>
> Shawn
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Record Generator

[Glen Stampoultzis]

The record generator is not necessarily appropriate for every record type.

You could modify the code generated if you need to.  Just be careful not to
break the other records.

If you wish to do a one off generation then what you suggest will work.

You might be able to use XML entities to include your common code.  You will
get lots of duplicated generated code but since it's generated this is not
too evil.  Even with this case however you probably want a common interface
yes?  If so you might need to tweak the generator slightly to allow you to
specify a particular interface.

The record generator is a hammer but you might have a screw there instead of
a nail.

Regards,

Glen

PS:  Sorry it took a while to answer you.

> I'm working on margins and need to create records for them.  They all have
> the same structure except the sid is different.  I was wanting to create a
> MarginRecord using the record generator and then sub-class the actual
margin
> classes.  This does not work because of the requirement of needing a sid.
> Is there a way to make it work nicely without a sid or do I need to
generate
> the class, clean it up, and destroy the record file (so it does not get
> overridden)?  Basically, I'm wanting to stay along the lines that the rest
> of the code follows.
>
> Shawn
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-poi/src/testcases/org/apache/poi/hssf/record TestSSTRecordSizeCalculator.java

[glens]

glens   2002/07/17 07:18:03

  Modified:src/java/org/apache/poi/hssf/dev FormulaViewer.java
   src/java/org/apache/poi/hssf/record SSTRecord.java
SSTRecordSizeCalculator.java SSTSerializer.java
   src/testcases/org/apache/poi/hssf/record
TestSSTRecordSizeCalculator.java
  Log:
  More refactoring of SST
  
  Revision  ChangesPath
  1.6   +1 -1  jakarta-poi/src/java/org/apache/poi/hssf/dev/FormulaViewer.java
  
  Index: FormulaViewer.java
  ===
  RCS file: /home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/dev/FormulaViewer.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- FormulaViewer.java15 Jul 2002 00:14:38 -  1.5
  +++ FormulaViewer.java17 Jul 2002 14:18:03 -  1.6
  @@ -233,7 +233,7 @@
   
   private String composeFormula(FormulaRecord record)
   {
  -   return  
FormulaParser.toFormulaString((SheetReferences)null,record.getParsedExpression());
  +   return  
org.apache.poi.hssf.model.FormulaParser.toFormulaString((SheetReferences)null,record.getParsedExpression());
   }
   
   /**
  
  
  
  1.5   +6 -7  jakarta-poi/src/java/org/apache/poi/hssf/record/SSTRecord.java
  
  Index: SSTRecord.java
  ===
  RCS file: /home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/record/SSTRecord.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- SSTRecord.java9 Jun 2002 12:48:34 -   1.4
  +++ SSTRecord.java17 Jul 2002 14:18:03 -  1.5
  @@ -60,6 +60,7 @@
   
   import java.util.Iterator;
   import java.util.List;
  +import java.util.ArrayList;
   
   /**
* Title:Static String Table Record
  @@ -513,18 +514,16 @@
   {
   SSTSerializer serializer = new SSTSerializer(
   _record_lengths, field_3_strings, getNumStrings(), 
getNumUniqueStrings() );
  -return serializer.serialize( offset, data );
  +return serializer.serialize( getRecordSize(), offset, data );
   }
   
   
  -// we can probably simplify this later...this calculates the size
  -// w/o serializing but still is a bit slow
   public int getRecordSize()
   {
  -SSTSerializer serializer = new SSTSerializer(
  -_record_lengths, field_3_strings, getNumStrings(), 
getNumUniqueStrings() );
  -
  -return serializer.getRecordSize();
  +SSTRecordSizeCalculator calculator = new 
SSTRecordSizeCalculator(field_3_strings);
  +int recordSize = calculator.getRecordSize();
  +_record_lengths = calculator.getRecordLengths();
  +return recordSize;
   }
   
   SSTDeserializer getDeserializer()
  
  
  
  1.2   +22 -16
jakarta-poi/src/java/org/apache/poi/hssf/record/SSTRecordSizeCalculator.java
  
  Index: SSTRecordSizeCalculator.java
  ===
  RCS file: 
/home/cvs/jakarta-poi/src/java/org/apache/poi/hssf/record/SSTRecordSizeCalculator.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SSTRecordSizeCalculator.java  15 Jun 2002 06:04:26 -  1.1
  +++ SSTRecordSizeCalculator.java  17 Jul 2002 14:18:03 -  1.2
  @@ -57,6 +57,8 @@
   import org.apache.poi.util.LittleEndianConsts;
   
   import java.util.ArrayList;
  +import java.util.List;
  +import java.util.Map;
   
   /**
* Used to calculate the record sizes for a particular record.
  @@ -65,8 +67,6 @@
*/
   class SSTRecordSizeCalculator
   {
  -private SSTSerializer serializer;
  -
   private UnicodeString unistr = null;
   private int stringReminant = 0;
   private int unipos = 0;
  @@ -77,11 +77,13 @@
   private boolean firstRecord = true;
   private int totalWritten = 0;
   private int recordSize = 0;
  +private List recordLengths = new ArrayList();
   private int pos = 0;
  +private Map strings;
   
  -public SSTRecordSizeCalculator(SSTSerializer serializer)
  +public SSTRecordSizeCalculator(Map strings)
   {
  -this.serializer = serializer;
  +this.strings = strings;
   }
   
   /**
  @@ -94,9 +96,8 @@
   {
   initVars();
   
  -serializer.recordLengths = new ArrayList();
  -int retval = 0;
  -int totalStringSpaceRequired = serializer.calculateUnicodeSize();
  +int retval;
  +int totalStringSpaceRequired = SSTSerializer.calculateUnicodeSize(strings);
   
   if ( totalStringSpaceRequired > SSTRecord.MAX_DATA_SPACE )
   {
  @@ -106,11 +107,16 @@
   {
   // short data: write one simple SST record
   retval = SSTRecord.SST_RECORD_OVERHEAD + totalStringSpaceRequired;
  -serializer.recordLength

Re: problems reading simple formulas

[Avik Sengupta]

> What do we know aobut shared formulas from a read perspective?  How are 
> they implemented?  

pg 386 of the excel book. Basically, you need to append bits of a Formula and 
Sharedformula records to form equivalent formula records. You then get the ptg 
array, but with ptgs like ptgRefN instead of ptgRef .. whose only difference is 
in the sid. 


> BTW, did you look at my changes to HSSF to avoid storing workbook 
> context in the workbook and cleaning
> up the dependency tree?  

yeah, i did. I think it'll work, so thats ok. 


Quoting "Andrew C. Oliver" <[EMAIL PROTECTED]>:

> Hi Avik,
> 
> What do we know aobut shared formulas from a read perspective?  How are 
> they implemented?  What
> all do we need to do to support them?  
> 
> BTW, did you look at my changes to HSSF to avoid storing workbook 
> context in the workbook and cleaning
> up the dependency tree?  It might be over-reliance on the utility 
> pattern (or collections depending on how you
> look at it), but I think its better.  Thoughts?
> 
> -Andy
> 
> Avik Sengupta wrote:
> 
> >Yeah, thats what shared formulas are.. a method excel uses to optimise
> storage 
> >of formulas. It stores ONE formula record, and stores shared formula records
> 
> >for each cell, referencing the original formula record. 
> >
> >As you figured, there is no support in poi for reading shared formulas. As
> far 
> >as writing is concerned, we dont need to write shared formualas. Probabaly
> 
> >never will.
> >
> >So, as Andy mentioned, as far as formulas are concerned, write functionality
> is 
> >more robust than read functionality. Hopefully, we'll get there soon. 
> >
> >Quoting David N Horn <[EMAIL PROTECTED]>:
> >
> >  
> >
> >>Actually, folks, after some digging around I have come up with the
> solution
> >>to my own problem.  It turns out the formulas which were not being read
> >>correctly by HSSF had been generated in Excel in the standard manner of
> >>"dragging down".  That is, when a range of cells all need to contain the
> >>same formula but applied to different ranges, you enter the formula for
> the
> >>first range and then drag-copy that cell into the rest of the range,
> making
> >>it apply correctly to the various cell ranges (but you all knew that
> >>already!)
> >>
> >>It appears to be this which causes the api to read the cell formula
> >>incorrectly.  I have replaced the dragged versions of all formulae in my
> >>test-case workbook with the longhand versions and they now read
> correctly.
> >>This is good in the short term, but might need to be looked at in the
> >>future
> >>as we can only assume that most .xls workbooks will have been generated
> in
> >>the "dragged-down" manner.
> >>
> >>Thanks anyway.
> >>
> >>David
> >>
> >>-Original Message-
> >>From: David N Horn [mailto:[EMAIL PROTECTED]]
> >>Sent: 16 July 2002 21:57
> >>To: [EMAIL PROTECTED]
> >>Subject: problems reading simple formulas
> >>
> >>
> >>Hello all.  This is my first post to the list and I hope someone will be
> >>able to help me out.
> >>
> >>I am currently using the poi api as part of a larger project (aren't we
> >>all?!) and I need to be able to read in any .xls file and then manipulate
> >>its contents as per the needs of the project.  I am able to read in the
> >>files and output the cell contents well enough but I am having problems
> >>when
> >>it comes to formula cells.
> >>
> >>Now, from what I have read here, I know formulas are not yet well
> >>supported,
> >>but I understand there is _some_ support.  I am using dev version 1.8.0
> and
> >>my formulas are far from complicated.  They are of the type SUM(D3:D15)
> or
> >>AVERAGE(C9:I9), nothing fancy.
> >>
> >>The code I use reads in the formula cells okay and even recognises them
> to
> >>be formula cells, but usually displays them as "NO IDEA SHARED FORMULA
> EXP
> >>PTG".  I understand this to mean a shared formula is being used (a shared
> >>formula being one that spans sheets/workbooks?) which is not the case.
> >>Moreover, some of the cells read using poi (actually HSSF) do show as the
> >>correct formula, even though I can see no difference whatsoever between
> >>those that read right and those that do not!  Which only adds to the
> >>confusion.
> >>
> >>Is there something I am doing wrong here?  Is there no support yet for
> what
> >>I am trying to do?  What can I do to my code to ensure formulas are read
> >>right across the board?
> >>
> >>Thanks for your help folks.
> >>
> >>David N Horn
> >>
> >>
> >>"I like work: it fascinates me.  I could sit and look at it for hours."
> >>
> >>- Jerome K Jerome
> >>  "Three Men in a Boat"
> >>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:  
> 
> >>For additional commands, e-mail:
> 
> >>
> >>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:  
> 
> >>For additional commands, e-mail:
> 

DO NOT REPLY [Bug 10884] - Ability to read and set margins for sheets

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10884

Ability to read and set margins for sheets





--- Additional Comments From [EMAIL PROTECTED]  2002-07-17 13:52 ---
cool.  I'll apply this shortly if someone else doesn't beat me too it.  Please
add yourself as a developer on the src/documentation/xdocs/who.xml page which
matches to: http://jakarta.apache.org/poi/who.html -- You're a frequent and
valued developer on this project and I feel you should be recognized.  Thanks -Andy.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] HPSF priorities

[Andrew C. Oliver]

> No, I did not mean this because it really does not help you and
> it is in a different context.
>
> I meant this one: 
>
> Following the header is the section list. This is an array of 
> pairs each consisting of a section format ID and an offset. 
> This array has as many pairs of ClassID and and DWord fields 
> as the section count field in the header says. The Summary 
> Information stream contains a single section, the Document 
> Summary Information stream contains two. 
> 
> ... 
> 
> 0xF29F85E04FF91068AB9108002B27B3D9 for the single section in the Summary
> Information stream.
> 
> 0xD5CDD5022E9C101B939708002B2CF9AE for the first section in the Document Summary
> Information stream.

Thanks.  This may be enough for me to fix the method.  I'll investigate it further.  
Give me a few 
days as I'm working on something else at this very moment.  (days not months).  

Finally you lend me a hand with this.  Sheesh.

As for the "Take it or leave it"  - thats up to you.  You've been given an opportunity 
with this project, that
I made the mistake of giving you too freely without you really earning it.  Hence why 
you're the only one here 
who I think doesn't value it.  So if we have to do everything your way and on your 
time:  "leave it"  -- if you
plan to start living up to your end of the bargain, then I feel differently.  Lets 
work together or not, lets 
try to be less pedantic and have fewer stupid long winded discussions.  You FINALLY 
answered my question.  This
finally helps.

Please do the following:  open your browser, goto javadoc on the poi project page and 
click on the LittleEndian class,
if you still feel this is hard to understand, then you scare me...you really do.  
Next, open a class I modified to us 
Little endian in the cvs web viewer thing, do a quick diff.  If this still feels like 
a learning curvethen I'm really
scared.  This will be a time investment of 3 minutes (1 for javadoc, 1 for diffing, 1 
for browser/navigation overhead).

Thanks,

-Andy




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] HPSF priorities

[Rainer Klute]

"Ryan Ackley" <[EMAIL PROTECTED]> wrote:
>I just committed changes to the ClassID class that allow it to compile. I
>wasn't sure of the original intention of the author but I think I got it. My
>wife is yelling at me as I write this because we are going out of town.
>Could someone please test it for me? I will be gone until next Monday.

Unfortunately it doesn't work yet. The POI Browser does still 
not recognize the property sets. But thanks for your effort!

Best regards
Rainer Klute

   Rainer Klute IT-Consulting GmbH
  Dipl.-Inform.
  Rainer Klute E-Mail:  [EMAIL PROTECTED]
  Körner Grund 24  Telefon: +49 172 2324824
D-44143 Dortmund   Telefax: +49 231 5349423


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] HPSF priorities

[Ryan Ackley]

All,

I just committed changes to the ClassID class that allow it to compile. I
wasn't sure of the original intention of the author but I think I got it. My
wife is yelling at me as I write this because we are going out of town.
Could someone please test it for me? I will be gone until next Monday.

Ryan



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-poi/src/java/org/apache/poi/hpsf ClassID.java

[sackley]

sackley 2002/07/17 05:01:50

  Modified:src/java/org/apache/poi/hpsf ClassID.java
  Log:
  made the read method compile
  
  Revision  ChangesPath
  1.3   +26 -29jakarta-poi/src/java/org/apache/poi/hpsf/ClassID.java
  
  Index: ClassID.java
  ===
  RCS file: /home/cvs/jakarta-poi/src/java/org/apache/poi/hpsf/ClassID.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ClassID.java  19 May 2002 18:09:26 -  1.2
  +++ ClassID.java  17 Jul 2002 12:01:50 -  1.3
  @@ -56,6 +56,7 @@
   package org.apache.poi.hpsf;
   
   import java.io.*;
  +import org.apache.poi.util.LittleEndian;
   
   /**
*  REWRITE ME
  @@ -111,34 +112,30 @@
   public byte[] read(byte[] src, int offset) {
   byte[] retval = new byte[24];
   
  -throw new RuntimeException("This fucntion must be rewritten");
  -/*
  -Object[] b = new Object[11]; 
  -b[0] = new Long(LittleEndian.getUInt(src, offset));
  -b[1] = new Integer(LittleEndian.getInt(src, offset += 
LittleEndian.INT_SIZE));
  -b[2] = new Integer(LittleEndian.getInt(src, offset += 
LittleEndian.INT_SIZE));
  -b[3] = new Byte(LittleEndian.getUnsignedByte(src, offset += 
LittleEndian.INT_SIZE);  
  -b[4] = new Byte(LittleEndian.getUnsignedByte(src, offset += 1));
  -b[5] = new Byte(LittleEndian.getUnsignedByte(src, offset += 1));
  -b[6] = new Byte(LittleEndian.getUnsignedByte(src, offset += 1));
  -b[7] = new Byte(LittleEndian.getUnsignedByte(src, offset += 1));
  -b[8] = new Byte(LittleEndian.getUnsignedByte(src, offset += 1));
  -b[9] = new Byte(LittleEndian.getUnsignedByte(src, offset += 1));
  -b[10] = new Byte(LittleEndian.getUnsignedByte(src, offset += 1));
  -int capacity = 24;
  -//for (int i = 0; i < b.length; i++) {
  -//capacity += b[i].getBytes().length;
  -//}
  -bytes = new byte[capacity];
  -int pos = 0;
  -
  -for (int i = 0; i < b.length; i++) {
  -byte[] s = b[i].getBytes();
  -for (int j = 0; j < s.length; j++) {
  -bytes[pos++] = s[j];
  -}
  -}
  -return bytes;*/
  +//throw new RuntimeException("This fucntion must be rewritten");
  +
  +//Number[] b = new Number[11];
  +
  +//b[0] = new Integer(LittleEndian.getInt(src, offset));
  +//transfer the first Int from little to big endian
  +retval[0] = src[3];
  +retval[1] = src[2];
  +retval[2] = src[1];
  +retval[3] = src[0];
  +
  +//b[1] = new Short(LittleEndian.getInt(src, offset += 
LittleEndian.INT_SIZE));
  +//transfer the second short from little to big endian
  +retval[4] = src[5];
  +retval[5] = src[4];
  +
  +//b[2] = new Short(LittleEndian.getInt(src, offset += 
LittleEndian.SHORT_SIZE));
  +//transfer the third short from little to big endian
  +retval[6] = src[7];
  +retval[7] = src[6];
  +
  +System.arraycopy(src, 8, retval, 8, retval.length - 8);
  +
  +return retval;
   }
   
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: problems reading simple formulas

[Andrew C. Oliver]

Hi Avik,

What do we know aobut shared formulas from a read perspective?  How are 
they implemented?  What
all do we need to do to support them?  

BTW, did you look at my changes to HSSF to avoid storing workbook 
context in the workbook and cleaning
up the dependency tree?  It might be over-reliance on the utility 
pattern (or collections depending on how you
look at it), but I think its better.  Thoughts?

-Andy

Avik Sengupta wrote:

>Yeah, thats what shared formulas are.. a method excel uses to optimise storage 
>of formulas. It stores ONE formula record, and stores shared formula records 
>for each cell, referencing the original formula record. 
>
>As you figured, there is no support in poi for reading shared formulas. As far 
>as writing is concerned, we dont need to write shared formualas. Probabaly 
>never will.
>
>So, as Andy mentioned, as far as formulas are concerned, write functionality is 
>more robust than read functionality. Hopefully, we'll get there soon. 
>
>Quoting David N Horn <[EMAIL PROTECTED]>:
>
>  
>
>>Actually, folks, after some digging around I have come up with the solution
>>to my own problem.  It turns out the formulas which were not being read
>>correctly by HSSF had been generated in Excel in the standard manner of
>>"dragging down".  That is, when a range of cells all need to contain the
>>same formula but applied to different ranges, you enter the formula for the
>>first range and then drag-copy that cell into the rest of the range, making
>>it apply correctly to the various cell ranges (but you all knew that
>>already!)
>>
>>It appears to be this which causes the api to read the cell formula
>>incorrectly.  I have replaced the dragged versions of all formulae in my
>>test-case workbook with the longhand versions and they now read correctly.
>>This is good in the short term, but might need to be looked at in the
>>future
>>as we can only assume that most .xls workbooks will have been generated in
>>the "dragged-down" manner.
>>
>>Thanks anyway.
>>
>>David
>>
>>-Original Message-
>>From: David N Horn [mailto:[EMAIL PROTECTED]]
>>Sent: 16 July 2002 21:57
>>To: [EMAIL PROTECTED]
>>Subject: problems reading simple formulas
>>
>>
>>Hello all.  This is my first post to the list and I hope someone will be
>>able to help me out.
>>
>>I am currently using the poi api as part of a larger project (aren't we
>>all?!) and I need to be able to read in any .xls file and then manipulate
>>its contents as per the needs of the project.  I am able to read in the
>>files and output the cell contents well enough but I am having problems
>>when
>>it comes to formula cells.
>>
>>Now, from what I have read here, I know formulas are not yet well
>>supported,
>>but I understand there is _some_ support.  I am using dev version 1.8.0 and
>>my formulas are far from complicated.  They are of the type SUM(D3:D15) or
>>AVERAGE(C9:I9), nothing fancy.
>>
>>The code I use reads in the formula cells okay and even recognises them to
>>be formula cells, but usually displays them as "NO IDEA SHARED FORMULA EXP
>>PTG".  I understand this to mean a shared formula is being used (a shared
>>formula being one that spans sheets/workbooks?) which is not the case.
>>Moreover, some of the cells read using poi (actually HSSF) do show as the
>>correct formula, even though I can see no difference whatsoever between
>>those that read right and those that do not!  Which only adds to the
>>confusion.
>>
>>Is there something I am doing wrong here?  Is there no support yet for what
>>I am trying to do?  What can I do to my code to ensure formulas are read
>>right across the board?
>>
>>Thanks for your help folks.
>>
>>David N Horn
>>
>>
>>"I like work: it fascinates me.  I could sit and look at it for hours."
>>
>>- Jerome K Jerome
>>  "Three Men in a Boat"
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   
>>For additional commands, e-mail: 
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   
>>For additional commands, e-mail: 
>>
>>
>>
>>
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] HPSF priorities

[Rainer Klute]

>>You did, I did it to collaborate in finishing the work.  Because no one under
stands this 
>>underdocumented piece, no one could work on it but you.  Catch-22.
>>
>>If I kept the code locally, no one could help finish this right? right.

No. There is *never* any reason to check in broken code. I have 
worked on several projects with a resource management system, 
and this is always a very critical point. If you break something 
a lot of other developers are concerned. You'd never to this. 
The way to go is to give your work to your co-developer by some 
other means, i.e. private e-mail, a temporary CVS branch, module, 
or server, or whatever. But you will never check in broken code.

At the time you checked in the broken code you should have known 
that I could not donate *any* time to HPSF, not even to check 
whether your changes were okay or not. I think I had made this 
clear in advance.


>>>It was you who hesitated to do that changes, not me. As I pointed
>>>out in my original posting, there was no reason to hesitate. No
>>>one would have noticed any performance degradation if the code
>>>would have been left unchanged for 5 years.
>>>
>>>You broke HPSF. This fact speaks for itself.
>>>
>>>
>>
>>Yup.  I'm the only one who's worked on it recently.
>>...

Oh, well, what a cool argument! :-)

I'd prefer old code that works over new code that doesn't. But I
understand we cannot come to a conclusion.


>>>I'll do that if I have a clean and working code base.
>>>
>>>
>>
>>Well rainer, you don't want to help getting there with one method of one clas
s.

You put it too simple. It is not just one method in one class.
It is all the general little-endian classes and the way they work
versus the HPSF classes. This takes more than snipping your fingers.
(As you found out.)


>>So 
>>we go back to the issue whether you want to do this collaboratively or if its
 your 
>>pet project?
>>Help me fix this one tiny little underdocumented method, and le
ts move on.

I agree with you on fixing this issue, I just want it to do
differently than you. You accused me that my pride was hurt and that
HPSF were my pert project. However, it seems that this is true
for you regarding your "fixes". Let me do it and you'll all get
quality code and documentation.


>>You're not willing, but it sounds like with Ryan and Glen's help we may be ab
le to get this
>>done anyhow.  so this is moot to me.

I am willing, but sticking to quality first. Then follows code reuse etc.


>>>-1. HPSF must be fixed *immediately*. Rolling back to the old
>>>revisions can be done in an instant. Anything else would first
>>>require me to understand the general little-endian classes, consider
>>>whether they suit my need, probably adding some functionality
>>>to them - and eventually the general classes and the HPSF classes
>>>might be incompatible and thus might require a major code rewrite.
>>
>>That is a rediculous estimate.  What you're doing is parsing little endian va
lues,
>>writing little endian values.  These may be signed or unsigned.  Anyone else 
pipe up if
>>this sounds like a major ordeal, perhaps I'm dull, but this sound pretty dern
 generic.

May be. But it surely takes longer than rolling back the changes and 
*then* considering the details. It might well be that your changes are
the solution. They are not lost when rolling back. But I'd want
working code first, and *then* fixing stuff with junit test at hand.


>>>What we need now is a quick action to get HPSF working again. Any 
>>>other action can be taken afterwards.
>>>
>>>
>>
>>No.  I disagree.  We need to make HPSF into a real POI component that others 
can 
>>collaboratively work on, that fits in with the common facillities of the proj
ect, that
>>meets community standards...  Otherwise it needs to go in the scratchpad.  If
 we move it 
>>to the scratchpad, you can do whatever you like with it.  Maybe one day you'l
l have enough
>>time to achieve this alone.

You make two statements in one here:

1. You say its okay that HPSF continues to be broken for some time and
   does not need an immediate fix, i.e. within a few minutes.
   I don't agree.

2. You say that HPSF should be a POI component that we can work on
   collaboratively.
   I do agree.

But please keep these two different statement apart!


>>But at the moment with Ryan and Glen's help I'm confident we can fix this sin
gle method and 
>>get this up and running so HPSF works.  From there if you feel that is not a 
clean enough base
>>to work with then I don't know what to say.

I am sure Ryan and Glen are both able to do this. However, I can
imagine that it were more effective for the POI project as a whole
if they forstered the HSSF and HDF components instead of fixing
HPSF.

As I said, I am offering my time and effort to continue working on 
HPSF. Take it or leave it.


>>Rainer, look at the list and the feedback you're getting.  No one understands
 why fixing
>>this method is such a big deal (including me),