keiron 01/06/06 05:34:17
Modified: docs/xml-docs fop.xml
docs/xml-docs/fop architecture.xml examples.xml
implemented.xml involved.xml readme.xml running.xml
Added: docs/xml-docs/fop svg.xml testing.xml
Log:
updates to website xml docs for svg and testing
Revision Changes Path
1.7 +2 -0 xml-fop/docs/xml-docs/fop.xml
Index: fop.xml
===================================================================
RCS file: /home/cvs/xml-fop/docs/xml-docs/fop.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- fop.xml 2001/03/03 08:10:00 1.6
+++ fop.xml 2001/06/06 12:33:52 1.7
@@ -13,9 +13,11 @@
<document id="config" label="Configuration"
source="fop/configuration.xml" />
<document id="fonts" label="Fonts" source="fop/fonts.xml" />
<document id="extensions" label="Extensions" source="fop/extensions.xml" />
+ <document id="svg" label="SVG" source="fop/svg.xml" />
<separator/>
<document id="compiling" label="Compiling" source="fop/compiling.xml" />
<document id="embedding" label="Embedding" source="fop/embedding.xml" />
+ <document id="testing" label="Testing" source="fop/testing.xml" />
<document id="involved" label="Getting involved" source="fop/involved.xml"
/>
<document id="architecture" label="Architecture" source="fop/architecture.xml"/>
<separator/>
1.10 +15 -10 xml-fop/docs/xml-docs/fop/architecture.xml
Index: architecture.xml
===================================================================
RCS file: /home/cvs/xml-fop/docs/xml-docs/fop/architecture.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- architecture.xml 2001/03/25 23:02:17 1.9
+++ architecture.xml 2001/06/06 12:34:01 1.10
@@ -321,22 +321,27 @@
<s2 title="SVG">
<p>
-FOP supports some svg rendering. SVG is supported as an instream-foreign-object
-embedded in an FO document. FOP also supports rendering of an external SVG image.
+FOP supports svg rendering. SVG is supported as an instream-foreign-object
+embedded in an FO document or as an external SVG image.
</p>
<p>
-Since the intream object that contains the SVG returns a single fo area then
-the construction of the SVG document is handled differently. The SVG is created
-by calling the <code>createGraphic()</code> on each SVG element. The element is then
-responsible for loading the necessary information and child elements and creating
-the corresponding SVG DOM element. When the FO tree is being layed out the
-SVG tree is turned into the SVG DOM document which is stored for later rendering.
+If the svg is embedded in an instream-foreign-object then all the elements and
+attributes are read directly and converted into an SVG DOM representation
+using the Batik library. This is then stored as a DOM until required for rendering.
+The rendering process depends on the what type of renderer is being used.
</p>
<p>
-The SVG document is then held as a DOM tree which is then rendered by going through
-the elements of the tree and rendering then in turn.
+The SVG DOM is rendered in the PDF renderer by using the abitlity of Batik to render
+DOM to a Graphics2D. First the DOM is converted into an intermediate representation
+then this is rendered to a PDFGraphics2D graphic object which writes the drawing
+instructions directly as PDF markup.
+</p>
+
+<p>
+The AWTRenderer and the PrintRenderer use Batik directly to draw the SVG image
+into the current java Graphics2D context.
</p>
<p>
1.9 +1 -1 xml-fop/docs/xml-docs/fop/examples.xml
Index: examples.xml
===================================================================
RCS file: /home/cvs/xml-fop/docs/xml-docs/fop/examples.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- examples.xml 2000/11/26 00:00:33 1.8
+++ examples.xml 2001/06/06 12:34:03 1.9
@@ -51,7 +51,7 @@
</li>
</ul>
<p>Developers will find the first steps to a test suite for all implemented
formatting objects and
- properties in xml-fop/docs/bugtests.</p>
+ properties in xml-fop/test/xml/.</p>
</s1>
1.15 +11 -69 xml-fop/docs/xml-docs/fop/implemented.xml
Index: implemented.xml
===================================================================
RCS file: /home/cvs/xml-fop/docs/xml-docs/fop/implemented.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- implemented.xml 2001/03/25 23:02:18 1.14
+++ implemented.xml 2001/06/06 12:34:04 1.15
@@ -221,75 +221,17 @@
<p>All other properties are not implemented.</p>
</s2>
- <s2 title="3) SVG elements supported">
- <ul>
- <li>rect</li>
- <li>circle</li>
- <li>line</li>
- <li>text - tref, tspan</li>
- <li>path</li>
- <li>polygon</li>
- <li>ellipse</li>
- <li>g</li>
- <li>svg (inside)</li>
- <li>image</li>
- <li>use</li>
- <li>defs (including referenced items not in defs element)</li>
- <li>linearGradient</li>
- <li>radialGradient</li>
- <li>stop</li>
- </ul>
- </s2>
- <s2 title="4) SVG properties supported">
- <ul>
- <li>style</li>
- <li>fill (style)</li>
- <li>stroke (style)</li>
- <li>stroke-width (style)</li>
- <li>stroke-dasharray (style)</li>
- <li>stroke-offset (style)</li>
- <li>stroke-linecap (style)</li>
- <li>stroke-linejoin (style)</li>
- <li>stroke-miterlimit (style)</li>
- <li>stop-color (style)</li>
- <li>color (style)</li>
- <li>font (style)</li>
- <li>font-size (style)</li>
- <li>font-family (style)</li>
- <li>font-weight (style)</li>
- <li>font-style (style)</li>
- <li>x</li>
- <li>y</li>
- <li>x1</li>
- <li>y1</li>
- <li>x2</li>
- <li>y2</li>
- <li>r</li>
- <li>cx</li>
- <li>cy</li>
- <li>x (list)</li>
- <li>y (list)</li>
- <li>dx</li>
- <li>dy</li>
- <li>transform</li>
- <li>rotate (transform)</li>
- <li>translate (transform)</li>
- <li>scale (transform)</li>
- <li>matrix (transform)</li>
- <li>skewX (transform)</li>
- <li>skewY (transform)</li>
- <li>d</li>
- <li>id</li>
- <li>width</li>
- <li>height</li>
- <li>xlink:href</li>
- <li>refX</li>
- <li>refY</li>
- <li>offset</li>
- <li>points</li>
- <li>fx</li>
- <li>fy</li>
- </ul>
+ <s2 title="3)SVG Support">
+<p>
+FOP uses <jump href="http://xml.apache.org/batik/";>Batik</jump> directly for its
SVG support. Therefore FOP supports the same
+elements and properties as are supported by Batik. As FOP is designed for
+rendering to a static medium then only static SVG is rendered.
+</p>
+<p>
+Due to some limitations in PDF some SVG images, particularly ones with effects
+or transparency, may not come out correctly. The images should still be rendered
+correctly for the AWT and Print renderers.
+</p>
</s2>
</s1>
1.7 +4 -3 xml-fop/docs/xml-docs/fop/involved.xml
Index: involved.xml
===================================================================
RCS file: /home/cvs/xml-fop/docs/xml-docs/fop/involved.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- involved.xml 2001/03/25 23:02:18 1.6
+++ involved.xml 2001/06/06 12:34:05 1.7
@@ -31,12 +31,13 @@
[EMAIL PROTECTED]</jump>. If you want to contribute to the
development of Fop you should subscribe,
because it is important that you follow changes being made. </p>
</s2>
- <s2 title="Contributing code and documentation">
- <p>If you want to contribute code (p.e. a bugfix) or documentation (p.e. an
additional example), please do the following: </p>
+ <s2 title="Contributing code, tests and documentation">
+ <p>If you want to contribute code (p.e. a bugfix), a test or documentation (p.e.
an additional example), please do the following: </p>
<p>1) Make sure your code doesn't break the existing one and that Fop still
compiles.</p>
<p>2) Create a file which shows the differences to the existing code.</p>
- <p>3) Send this file to [EMAIL PROTECTED]</p>
+ <p>3) Send this file to <jump
href="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]</jump></p>
<p>One of the committers will test your code and commit it to the code
repository.</p>
+ <p>If you have a test or useful bug test you should <jump
href="testing.html">read this page</jump>.</p>
<p>BTW: The Apache project knows different roles for contributors, namely
'users', 'developers', 'committers' and the 'Project
Management Committee' (An explanation of these roles can be found <jump
href="http://xml.apache.org/roles.html";>here</jump>).</p>
</s2>
1.9 +4 -3 xml-fop/docs/xml-docs/fop/readme.xml
Index: readme.xml
===================================================================
RCS file: /home/cvs/xml-fop/docs/xml-docs/fop/readme.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- readme.xml 2001/03/25 23:02:18 1.8
+++ readme.xml 2001/06/06 12:34:07 1.9
@@ -49,9 +49,10 @@
identified as such.
</p>
- <p>Another secondary goal is to promote the conversion of SVG into PDF. The
most natural mechanism for doing so is within
- fo:instream-foreign-object FO's. The powerful graphics offered by both SVG
and PDF are a natural fit, and it is
- desirable that FOP natively supports an SVG content processor for the
fo:instream-foreign-object.
+ <p>Another secondary goal is to improve the conversion of SVG into PDF.
+ This includes the use of FOP to work as a transcoder for Batik to convert
+ an SVG document into a PDF document and the fully support embedding SVG
inside
+ fo documents in an fo:instream-foreign-object.
</p>
<p>A final secondary goal is the continued refinement of the FOP design and
implementation. In particular, maintaining the
1.13 +1 -1 xml-fop/docs/xml-docs/fop/running.xml
Index: running.xml
===================================================================
RCS file: /home/cvs/xml-fop/docs/xml-docs/fop/running.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- running.xml 2001/05/18 09:55:58 1.12
+++ running.xml 2001/06/06 12:34:08 1.13
@@ -17,7 +17,7 @@
</li>
<li>An XSLT processor
</li>
- <li>The SVG library batik.jar is the library from the batik project at
xml.apache.org.
+ <li>The SVG library batik.jar is the library from the <jump
href="http://xml.apache.org/batik/";>batik project</jump> at xml.apache.org.
</li>
<li>The imaging library Jimi from Sun
</li>
1.1 xml-fop/docs/xml-docs/fop/svg.xml
Index: svg.xml
===================================================================
<?xml version="1.0" standalone="no"?>
<!-- SVG in FOP -->
<s1 title="SVG in FOP">
<s2 title="Introduction">
<p>
FOP uses the SVG library from <jump href="http://xml.apache.org/batik/";>Batik</jump>
to handle SVG.
This format can be handled as an <code>fo:instream-foreign-object</code> or in a
separate
file referenced with <code>fo:external-graphic</code>. Either way the SVG document
will be
read in and converted into a DOM in Batik. This DOM will then be used by the
renderer to
create the graphical image.
</p>
<p>
The AWT and Print renderers simply use batik to draw the SVG into a graphic.
</p>
<p>
In the case of the PDF renderer there is a PDFGraphics2D class that Batik uses
to render the image into. This class converts the drawing instructions into
PDF markup which is placed into the current PDF document.
</p>
</s2>
<s2 title="Converting SVG to a PDF Document">
<p>
It is possible to convert a standalone SVG document directly into a simple page PDF
document.
This is possible through the use of Batik's transcoder mechanism.<br/>
<code>java org.apache.batik.apps.rasterizer.Main -m application/pdf
document.svg</code>
<br/>
This will output the svg document as "document.pdf" containing a PDF rendering of
the SVG file.
</p>
<p>
It is also possible to specify the width and/or height of the PDF document.
Currently the SVG image is simply scaled in PDF so the result my not be the best
possible.
</p>
<p>
For more information see <jump href="http://xml.apache.org/batik/";>Batik</jump> for
how transocders work.
</p>
</s2>
</s1>
1.1 xml-fop/docs/xml-docs/fop/testing.xml
Index: testing.xml
===================================================================
<?xml version="1.0" standalone="no"?>
<!-- Testing FOP -->
<s1 title="Testing FOP">
<s2 title="">
<p>
Testing is an important part of getting FOP to operate correctly and conform to the
necessary standards.
</p>
<p>
A testing system has been set up that works with as a build target when developing
with FOP. A developer can run the tests after making changes to the code, the aim
is to have the tests run to verfiy that nothing working has been broken.
</p>
<p>
To setup the testing the developer must place a reference fop.jar in the
"<cvs_repository>/test/reference/" directory. This jar will be dynamically
loaded to create the reference output.
</p>
</s2>
<s2 title="Writing a Test">
<p>
A test belongs to one of a few catagories. A basic test should excercise one
element in a number of situations such as changing a property. This should have
at least one normal value, one border value and one invalid value. If the property
can be of different types then this should also be included.
</p>
<p>
A bug test is a test that is specifically aimed at a problem with FOP. That is, the
test
is not excercising the specification but rather a problem with FOP in handling a
particular
situation that is not exposed with the other testing.
</p>
<p>
A system test is one that tests the abitlity of FOP to handle a number of different
elements together.
</p>
<p>
A test can consist of a complete fo document or a part of the document such as
some elements that will be placed into the flow of a standard document.
</p>
</s2>
<s2 title="Submitting a Test">
<p>
If you have a test which you think would be useful you should supply the
test and a diff to the appropriate test suite xml file. Make sure that the
test works as would be expected against the current build.
</p>
</s2>
<s2 title="How Testing Works">
<p>
The tests are stored in the "<cvs_repository>/test" directory.
</p>
<p>
You can run the tests by specifying the build target "test" ie: <br/>
<code>build.sh test</code>
</p>
<p>
This will then compare the current code in the local src directory to a specified
release of FOP. Any differences between the current code and the output from
the reference version will be reported. If the test previously passed then the
test run will have failed.
</p>
<p>
The testing is done by reading a test suite xml file, which corresponds to the
standard testsuite.dtd supplied from w3c. This xml file contains a test xml
file and an xsl file (which may simply copy the file). It also contains information
such as if the test has passed and any comments.
</p>
<p>
For FOP the testing is done by rendering all the testing documents using the
XML renderer. The XML files are then compared to see if there are any differences.
</p>
</s2>
<s2 title="SVG Testing">
<p>
The testing of SVG is not part of this testing system. SVG is tested for its
rendering
accuracy by using the transcoding mechanism via Batik. So that the only part that
needs
testing is how the SVG image is embedded inside the flow of the fo document.
</p>
</s2>
</s1>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
