cleaned up typos mostly

git-svn-id: https://svn.apache.org/repos/asf/jakarta/poi/trunk@352098 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Mark Johnson 2002-02-16 15:57:08 +00:00
parent 345bb2bfbc
commit e2dc98aea5
1 changed files with 38 additions and 42 deletions

View File

@ -1,6 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "../dtd/document-v10.dtd"> <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "../dtd/document-v10.dtd">
<document> <document>
<header> <header>
<title>PoiFS</title> <title>PoiFS</title>
@ -10,37 +9,34 @@
<person name="Nicola Ken Barozzi" email="barozzi@nicolaken.com"/> <person name="Nicola Ken Barozzi" email="barozzi@nicolaken.com"/>
</authors> </authors>
</header> </header>
<body> <body>
<s1 title="Overview"> <s1 title="Overview">
<p>POIFS is a pure Java implementation of the OLE 2 Compound
<p>POIFS is a pure Java implementation of the OLE 2 Compound Document format.</p> Document format.</p>
<p> <p>By definition, all APIs developed by the POI project are
By very definition, all APIs developed by the POI project are based somehow based somehow on the POIFS API.</p>
on the POIFS API. <p>A common confusion is on just what POIFS buys you or what OLE
</p> 2 Compound Document format is exactly. POIFS does not buy you
<p> DOC, or XLS, but is necessary to generate or read DOC or XLS
A common confusion is on just what POIFS buys you or what OLE 2 Compound files. You see, all file formats based on the OLE 2 Compound
Document format IS exactly. POIFS does not buy you DOC, or XLS Document Format have a common structure. The OLE 2 Compound
but is necessary to generate DOCs or XLS files. You see all file Document Format is essentially a convoluted archive
formats based on the OLE 2 Compound Document Format have a common format. Think of POIFS as a "zip" library. Once you can get
structure. The OLE 2 Compound Document Format is essentially a the data in a zip file you still need to interpret the
convoluted archive format. Think of POIFS as a "zip" library. So once data. As a general rule, while all of our formats <b>use</b>
you can get at the data in a zip file you still need to interperate the POIFS, most of them attempt to abstract you from it. There
data. As a general rule, while all of our formats USE POIFS, most of are some circumstances where this is not possible, but as a
them attempt to abstract you from it. There are some circumstances general rule this is true.</p>
where this is not possible, but as a general rule this is ture. <p>If you're an end user type just looking to generate XLS
</p> files, then you'd be looking for HSSF not POIFS; however, if
<p> you have legacy code that uses MFC property sets, POIFS is
If you're an enduser type just looking to generate XLS files, then you'd for you! Regardless, you may or may not need to know how to
be looking for HSSF not POIFS; however, if you have legacy code that use POIFS but ultimately if you use technologies that come
uses MFC property sets. POIFS is for you! Regarless, you may or may from the POI project, you're using POIFS underneith. Perhaps
not need to know how to use POIFS but ultimately if you use technologies we should have a branding campaign "POIFS Inside!". ;-)</p>
that come from the POI project, you're using POIFS underneith. Perhaps <p>TODO: copy POIFS docs and port to XML (in progress). For now
we should have a branding campaign "POIFS Inside!". ;-) please reference <link href="http://poi.sourceforge.net">old
</p> site</link>.</p>
<p> TODO: copy POIFS docs and port to XML. For now please reference <link href="http://poi.sourceforge.net">old site</link>.
</p>
</s1> </s1>
</body> </body>
</document> </document>