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: 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: 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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>





statetax2.xls
Description: MS-Excel spreadsheet

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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: