Re: AW: PS Renderer patch

[Jeremias Maerki]

I wonder. What exactly would you like to tell us with this mail? I don't
get it.

> The coordinates x/y have to be defined: outer, inner, center of the border
> line?
> 
> PDF renderer FOP-0.20.1
> 
> o draws a box with 4 filled rectangles - each border line is a filled
> rectangle. The SVG trace below demonstrates this.
> 
> o 4 calls to method addFilledRect(int x, int y, int w, int h, PDFPathPaint
> fill) in PDFRenderer
> 
> 
> (x,y) is the center of the line
> 
> border height = 3
> ---center (y for horizontal line)
> 
> 
> Other renderers might have to operate with (y +- h/2), (x +- w/2)
> 
> 
> http://www.w3.org/2000/svg";>
>  fill="rgb(255.0,0.0,0.0)"/>
>  fill="rgb(255.0,0.0,0.0)"/>
>  fill="rgb(255.0,0.0,0.0)"/>
>  fill="rgb(255.0,0.0,0.0)"/>

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Running Prefligh PDF tools on PDF files produced by FOP

[Matthew Brook O'Donnell]

I've found that FOP 0.20.1 and 0.20.2 produce PDFs that do not
cause a 'fatal PDF error' in PitStop, even without the modification
of (_data.size() + 1) to _data.size() in the PDFStream class that Hansuli
proposed.

However, I haven't been able to produce PDF that pass with 0.20.3 (even with
the proposed patch).

I am still pursuing the nature of the 'fatal error' with Enfocus. Apparently
these errors frequently occur when "PostScript is inserted in various PDF
objects - something that the spec allows, but shouldn't since it prevents
the file from being printer-agnostic." I can understand what that means, but
do not know how it relates to PDF render in FOP, or whether this is causing
the reported problem.

Were there significant change in the PDF output classes between 0.20.2 and
0.20.3?

Matt O'Donnell



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Structure Handlers - RTF Renderer

[Peter B. West]

  Bertrand,

<
I started writing this before the flurry of messages in the last day or 
two, so it may now be redundant.  If so, however, I have missed part of 
the conversation.  My recollection of consensus of opinion some months 
ago was as I state just below.
 >

I think you will still have attribute resolution problems.  Remember 
that some attributes are only going to be resolved during the layout.

It seems to me that the general solution would involve the definition of 
a structure api, taking account of the layout dependencies.  to get 
there, you need to define an XML equivalent of the structure that is 
presented to the RTF renderer.  Define all of the data types that are 
being passed into RTF, and isolate the circumstances in which 
information cannot be passed across prior to layout.  Out of that you 
might get three interface definitions: ideal RTF, layout RTF and FOTree 
RTF.  With any luck, ideal RTF would co-incide completely with layout 
RTF, and differ only in a few minor details from FOTree RTF.

Then have the same thing done for, say, MIF.  From a comparison of the 
layout MIF and FOTree MIF, try to develop a general FOStructure API 
which will hopefully be flexible enough to accommodate any other 
structure renderers which come along.  The danger in not doing that is 
that you end up with an FOStructure API that is only an RTFStructure API.

It may be necessary to build in a fundamental option to choose, e.g., 
layout RTF or FOTree RTF.  In the latter case, the User Agent would 
arbitrate unresolved arrtibutes; in the former, the layout engine would 
have to proceed far enough to resolve all of the attributes.  One 
possibility in the former case is that you _may_ find it is possible to 
do the transformation to FOTree RTF in XSLT.  Just a flight of fancy 
perhaps.

You may already have documented the structure transformations needed for 
FO->RTF.  If so, it would be a very good idea to include them in the NEW 
DESIGN documentation.

Peter


Bertrand Delacretaz wrote:

>Hi Keiron,
>
>  
>
>>. . .
>>This structure handler will have a number of methods for the start and
>>end of elements like block, table, list item etc. and others for
>>external graphic etc. 
>>. . .
>>
>>
>
>I agree that high-level events like start/end block, table, etc. are what we 
>need for structure rendering. 
>
>Currently jfor works by mapping SAX events (that come directly from parsing 
>the XSL-FO) to the construction of RTF objects, so the kind of interface that 
>you mention would certainly help integrating the current jfor code.
>
>  
>
>>It will pass appropriate information, mostly the
>>current fo object.
>>
>>
>
>Maybe passing a compound object (StructureRendererContext?) that *contains* 
>the current fo object would help, as the renderer might need to access 
>configuration, logging or other services.
>
>  
>
>>. . .
>>Currently the StreamRenderer does a very limited version with start, end
>>document and end page sequence. This could become a subclass of the
>>structure handler where it will only use a few methods (probably should
>>rename it to RenderHandler).
>>. . .
>>
>>
>
>Looks good to me - basing the current rendering process on the structure 
>rendering stuff certainly makes sense.
>
>If I get it right, the processing pipeline would then look as follows:
>parsing -> SAX events -> validation -> attribute resolution -> structure 
>rendering (SR)
>
>Where SR is either "RTF rendering" or "layout -> PDF rendering"
>
>- Bertrand
>  
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 9437] - Ican't use Fop apps with the examples of file fo

[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=9437

Ican't use Fop apps with the examples of file fo

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-05-27 19:06 ---
The XSLFO standard changed the property referencing a page master from
master-name to master-reference just before finishing. Your FO files
still match the draft standard. Change master-name to master-reference
on the fo:page-sequence and other FO elements referencing a page master.
This is also documented in the release notes distributed with FOP.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 8661] - FOP 0.20.3 Not running on solaris 2.6 / jdk 1.3.0

[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=8661

FOP 0.20.3 Not running on solaris 2.6 / jdk 1.3.0





--- Additional Comments From [EMAIL PROTECTED]  2002-05-27 17:13 
---
I had the same problem and installing Xvfb solved it... Try this or PJA or Sun's
JDK 1.4 headless option...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

C# Version of FOP

[Mark Griffiths]

Dear FOP Developers

Out of courtesy I wanted to let you all know that we have ported a recent
version of FOP to C# and have decided to market it as a commercial
component.

FOP has proved a excellent starting point for the project and I would like
to thank all the FOP developers, past and present, for their contributions.

Assuming the component is commercially successful, we are looking forward to
repaying the Apache community by donating money or resources.

Thanks again to all those involved with FOP and good luck for the future.

Kind regards
Mark

--
Mark Griffiths
mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/src/org/apache/fop/layout AreaTree.java

[keiron]

keiron  02/05/27 05:34:19

  Modified:src/org/apache/fop/apps Driver.java Fop.java
   src/org/apache/fop/extensions Bookmarks.java
   src/org/apache/fop/fo FONode.java FOTreeBuilder.java
FObj.java FObjMixed.java
   src/org/apache/fop/fo/flow Block.java
   src/org/apache/fop/fo/pagination PageSequence.java
   src/org/apache/fop/layout AreaTree.java
  Added:   src/org/apache/fop/apps LayoutHandler.java
StructureHandler.java
  Removed: src/org/apache/fop/apps StreamRenderer.java
  Log:
  start of structure handler concept and adjusted the layout
  handling appropriately
  
  Revision  ChangesPath
  1.48  +4 -4  xml-fop/src/org/apache/fop/apps/Driver.java
  
  Index: Driver.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/apps/Driver.java,v
  retrieving revision 1.47
  retrieving revision 1.48
  diff -u -r1.47 -r1.48
  --- Driver.java   22 Apr 2002 13:23:20 -  1.47
  +++ Driver.java   27 May 2002 12:34:18 -  1.48
  @@ -1,5 +1,5 @@
   /*
  - * $Id: Driver.java,v 1.47 2002/04/22 13:23:20 keiron Exp $
  + * $Id: Driver.java,v 1.48 2002/05/27 12:34:18 keiron Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
  @@ -453,11 +453,11 @@
* events but isn't a SAX Parser itself.
*/
   public ContentHandler getContentHandler() {
  -StreamRenderer streamRenderer = new StreamRenderer(_stream, _renderer);
  -streamRenderer.setLogger(getLogger());
  +StructureHandler handler = new LayoutHandler(_stream, _renderer, true);
  +handler.setLogger(getLogger());
   _treeBuilder.setLogger(getLogger());
   _treeBuilder.setUserAgent(getUserAgent());
  -_treeBuilder.setStreamRenderer(streamRenderer);
  +_treeBuilder.setStructHandler(handler);
   
   return _treeBuilder;
   }
  
  
  
  1.11  +3 -3  xml-fop/src/org/apache/fop/apps/Fop.java
  
  Index: Fop.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/apps/Fop.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- Fop.java  8 Jan 2002 09:52:16 -   1.10
  +++ Fop.java  27 May 2002 12:34:18 -  1.11
  @@ -1,5 +1,5 @@
   /*
  - * $Id: Fop.java,v 1.10 2002/01/08 09:52:16 keiron Exp $
  + * $Id: Fop.java,v 1.11 2002/05/27 12:34:18 keiron Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
  @@ -17,8 +17,8 @@
   Starter starter = options.getStarter();
   starter.run();
   } catch (FOPException e) {
  -if("null".equals(e.getMessage())) {
  -System.err.println("NullPointerException");
  +if("null".equals("" + e.getMessage())) {
  +System.err.println("Exception occured with a null error message");
   } else {
   System.err.println("" + e.getMessage());
   }
  
  
  
  1.1  xml-fop/src/org/apache/fop/apps/LayoutHandler.java
  
  Index: LayoutHandler.java
  ===
  package org.apache.fop.apps;
  
  import java.io.OutputStream;
  import java.io.IOException;
  import java.util.HashSet;
  
  import org.xml.sax.SAXException;
  
  import org.apache.fop.layout.FontInfo;
  import org.apache.fop.area.PageViewport;
  import org.apache.fop.area.AreaTree;
  import org.apache.fop.area.Title;
  import org.apache.fop.render.Renderer;
  import org.apache.fop.fo.pagination.PageSequence;
  
  import org.apache.avalon.framework.logger.Logger;
  
  /**
   * Layout handler that receives the structure events.
   * This initiates layout processes and corresponding
   * rendering processes such as start/end.
   */
  public class LayoutHandler extends StructureHandler {
  private static final boolean MEM_PROFILE_WITH_GC = false;
  
  /**
Somewhere to get our stats from.
   */
  private Runtime runtime = Runtime.getRuntime();
  
  /**
Keep track of the number of pages rendered.
   */
  int pageCount = 0;
  
  /**
Keep track of heap memory allocated,
for statistical purposes.
   */
  private long initialMemory;
  
  /**
Keep track of time used by renderer.
   */
  private long startTime;
  
  /**
The stream to which this rendering is to be
written to. Note that some renderers
do not render to a stream, and that this
member can therefore be null.
   */

Re: Structure Handlers - RTF Renderer

[Keiron Liddle]

On Mon, 2002-05-27 at 14:22, Bertrand Delacretaz wrote:
> What about:
> 
> a) base class with all start/end methods but most of them are empty (costs 
> very little to call IMHO compared to the whole rendering process)
> 
> b) derived class for RTFHandler and such, where most or all methods do 
> something.
> 
> But you know the code much better than I do, so I'll let you choose the best 
> option.
> 
> How about actually starting to implement this? I can spare a few hours a week 
> to help, but having some skeleton code to start with would help me a lot.
> 
> -Bertrand

That is roughly the idea.
I will commit the bits I have (and fix another problem) and we can go
from there.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Structure Handlers - RTF Renderer

[Bertrand Delacretaz]

On Monday 27 May 2002 13:37, Keiron Liddle wrote:
>. . .
> I'm thinking of the start as setting up the current context and the
> properties, then when others start it will belong to the current
> context. The end can then indicate context and finish off the formatting
> object and if easier then to handle the children and put everything into
> the output.
>. . .

Sounds good. I was just afraid of having to hold the entire table in memory 
until all rows are done, but as I understand this would not be the case.

>. . .
> fo -> rtf
> startTable -> setup table
> endRow -> create row info in rtf
> endTable -> end table in rtf
>. . .

Sounds good too.

>. . .
> > I'd prefer many event calls, . . .
> I think the fastest way to handle this would be to have a boolean where
> if true it calls all start/end otherwise it only calls the ones required
> by the layout structure handler.
>. . .

What about:

a) base class with all start/end methods but most of them are empty (costs 
very little to call IMHO compared to the whole rendering process)

b) derived class for RTFHandler and such, where most or all methods do 
something.

But you know the code much better than I do, so I'll let you choose the best 
option.

How about actually starting to implement this? I can spare a few hours a week 
to help, but having some skeleton code to start with would help me a lot.

-Bertrand

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Structure Handlers - RTF Renderer

[Keiron Liddle]

On Mon, 2002-05-27 at 11:37, Bertrand Delacretaz wrote:
> Would this scenario be easy to implement?
> 
> startTable
>   startRow (maybe after all FOs for the row have been parsed)
> startCell (maybe  after all FOs for the cell have been parsed)
>   start/end stuff for cell contents
> endCell
> more start/endCell
>   endRow
>   more start/endRow
> endTable
> 
> or do you mean just one startTable with row/columns contained in the FO?

If you need to output the row after all FOs for the row then you could
simply use the endRow to get the row and output its children.

I'm thinking of the start as setting up the current context and the
properties, then when others start it will belong to the current
context. The end can then indicate context and finish off the formatting
object and if easier then to handle the children and put everything into
the output.
These methods are called by the fo tree objects themselves as a result
of the FOTreeBuilder calling through the SAX events.

fo -> rtf
startTable -> setup table
endRow -> create row info in rtf
endTable -> end table in rtf

> I'd prefer many event calls, as the StructureHandler wouldn't need to know as 
> much about FOs in this case. Conceptually (and this might be useful for 
> concrete stuff like testing too), I think the StructureHandler needs to 
> be able to rebuild the XSL-FO structure with as little code as possible.
> 
> Maybe (if easier to implement or to avoid slowing down PDF 
> rendering) this "event generation" can be done by an intermediate component 
> that "decodes" the FOs and generates detailed events?

I think the fastest way to handle this would be to have a boolean where
if true it calls all start/end otherwise it only calls the ones required
by the layout structure handler.
I can't think of any better way without having two fo trees or something
slower being handled in the FOTreeBuilder.

I think the names should be StructureHandler, LayoutHandler, RTFHandler
etc.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: diffs and new files for tempfile-based PDFStream support

[Keiron Liddle]

Hi Paul,

Thanks for the patch.
I have committed it.
For the testing, it works for a simple file. Eventually this sort of
testing could be done with the area tree xml -> pdf conversion but this
is not fully working right now.

Eventually we should try to use some common caching system that will
also handle other caching needs. Probably using some library.


The patch didn't quite compile properly. Sometimes you need to do a
build clean first to catch things.

On Thu, 2002-05-23 at 19:11, Paul Reavis wrote:
> Here's the output from `cvs diff` as well as the new files (how do I
> get a diff or patch equivalent for files that are new? I can't `cvs
> add` since I don't have write access, and it ignores non-cvs files) 
> 
> This patch:
> 1) adds a new class, org.apache.fop.util.StreamUtilities, that
> provides some buffered stream copying routines - InputStream to
> OutputStream. Adapted from my own IOLib, nice and fast and clean. Used
> by several of the new classes.
> 
> 2) modifies the current behavior of PDFFilters to operate on streams
> instead of byte arrays.
> 
> 3) changes the type of the ByteArrayOutputStream _data field of PDFStream to a new
> abstract class, StreamCache
> 
> 4) Added two implementations of StreamCache, InMemoryStreamCache and
> TempFileStreamCache. The InMemory behaves much like the current FOP
> implementation, with a ByteArrayOutputStream. The TempFile
> implementation uses temp files.
> 
> 5) a static factory method, PDFStream.createStreamCache(), creates the
> desired type. Another static method,
> PDFStream.setCacheToFile(boolean), sets which to use. 
> 
> Other StreamCache implementations are certainly possible; perhaps a
> smart one that only caches to file when a certain size is reached
> (StreamUtilities.BUFFER_SIZE perhaps). The problem with such a
> solution is death-of-a-thousand-paper-cuts - you may have quite a few
> small StreamCaches that end up killing scalability anyway.
> 
> Note that I was not able to test these changes - the current
> cvs fop does not run and says so plainly. Is there some way I can run some
> basic sanity tests at least? I would like to do some memory audits (we
> own a seat of OptimizeIt) but need to be able to run some real-life
> examples.
> 
> Thanks...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/src/org/apache/fop/util StreamUtilities.java

[keiron]

keiron  02/05/27 03:59:08

  Modified:src/org/apache/fop/pdf ASCII85Filter.java
ASCIIHexFilter.java DCTFilter.java FlateFilter.java
PDFFilter.java PDFICCStream.java PDFStream.java
PDFT1Stream.java PDFTTFStream.java
   src/org/apache/fop/tools AreaTreeBuilder.java
  Added:   src/org/apache/fop/pdf InMemoryStreamCache.java
StreamCache.java TempFileStreamCache.java
   src/org/apache/fop/util StreamUtilities.java
  Log:
  changed pdf streams to use io streams so that they
  can be cached
  Submitted by: Paul Reavis <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.4   +15 -19xml-fop/src/org/apache/fop/pdf/ASCII85Filter.java
  
  Index: ASCII85Filter.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/pdf/ASCII85Filter.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ASCII85Filter.java30 Jul 2001 20:29:29 -  1.3
  +++ ASCII85Filter.java27 May 2002 10:59:07 -  1.4
  @@ -1,5 +1,5 @@
   /*
  - * $Id: ASCII85Filter.java,v 1.3 2001/07/30 20:29:29 tore Exp $
  + * $Id: ASCII85Filter.java,v 1.4 2002/05/27 10:59:07 keiron Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
  @@ -9,6 +9,7 @@
   
   import java.io.ByteArrayOutputStream;
   import java.io.IOException;
  +import java.io.*;
   
   public class ASCII85Filter extends PDFFilter {
   private static final char ASCII85_ZERO = 'z';
  @@ -30,9 +31,7 @@
   return null;
   }
   
  -public byte[] encode(byte[] data) {
  -
  -ByteArrayOutputStream buffer = new ByteArrayOutputStream();
  +public void encode(InputStream in, OutputStream out, int length) throws 
IOException {
   
   int i;
   int total = 0;
  @@ -40,16 +39,16 @@
   
   // first encode the majority of the data
   // each 4 byte group becomes a 5 byte group
  -for (i = 0; i + 3 < data.length; i += 4) {
  +for (i = 0; i + 3 < length; i += 4) {
   
  -long val = ((data[i] << 24)
  +long val = ((in.read() << 24)
   & 0xff00L)  // note: must have the L at the
  -+ ((data[i + 1] << 16) & 0xffL)// end, otherwise you get into
  -+ ((data[i + 2] << 8) & 0xff00L)// weird signed value problems
  -+ (data[i + 3] & 0xffL);// cause we're using a full 32 bits
  ++ ((in.read() << 16) & 0xffL)// end, otherwise you get into
  ++ ((in.read() << 8) & 0xff00L)// weird signed value problems
  ++ (in.read() & 0xffL);// cause we're using a full 32 bits
   byte[] conv = convertWord(val);
   
  -buffer.write(conv, 0, conv.length);
  +out.write(conv, 0, conv.length);
   
   }
   
  @@ -57,12 +56,12 @@
   // with n leftover bytes, we append 0 bytes to make a full group of 4
   // then convert like normal (except not applying the special zero rule)
   // and write out the first n+1 bytes from the result
  -if (i < data.length) {
  -int n = data.length - i;
  +if (i < length) {
  +int n = length - i;
   byte[] lastdata = new byte[4];
   for (int j = 0; j < 4; j++) {
   if (j < n) {
  -lastdata[j] = data[i++];
  +lastdata[j] = (byte)in.read();
   } else {
   lastdata[j] = 0;
   }
  @@ -82,18 +81,15 @@
   }
   }
   // assert n+1 <= 5
  -buffer.write(conv, 0, n + 1);
  +out.write(conv, 0, n + 1);
   // System.out.println("ASCII85 end of data was "+n+" bytes long");
   
   }
   // finally write the two character end of data marker
  -buffer.write(ASCII85_EOD.getBytes(), 0,
  +out.write(ASCII85_EOD.getBytes(), 0,
ASCII85_EOD.getBytes().length);
   
   
  -byte[] result = buffer.toByteArray();
  -
  -
   // assert that we have the correct outgoing length
   /*
* int in = (data.length % 4);
  @@ -103,8 +99,8 @@
* System.out.println("inlength = "+data.length+" inlength % 4 = 
"+(data.length % 4)+" outlength = "+(result.length-ASCII85_EOD.getBytes().length)+" 
outlength % 5 = "+((result.length-ASCII85_EOD.getBytes().length) % 5));
* }
*/
  -return result;
   
  +out.close();
   }
   
   /**
  
  
  
  1.3   +10 -12xml-fop/src/org/apache/fop/pdf/ASCIIHexFilter.java
  
  Index: ASCIIHexFilter.

DO NOT REPLY [Bug 9437] New: - Ican't use Fop apps with the examples of file fo

[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=9437

Ican't use Fop apps with the examples of file fo

   Summary: Ican't use Fop apps with the examples of file fo
   Product: Fop
   Version: all
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: awt renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


hello,
when i launch the Fop apps (I type : java org.apache.fop.apps.Fop -d 
corresprop.fo test.pdf ), I have an error and the pdf has not generate.
This print the follow message:

[DEBUG]: setting up fonts
[ERROR]: 'master-reference' for 'fo:page-sequence'matches no 'simple-page-
master' or 'page-sequence-master'

I don't understand why.

Best regards

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Structure Handlers - RTF Renderer

[Bertrand Delacretaz]

Hi Keiron,

>. . .
> We should be able to set common objects like the logging and config on
> the structure handler itself.
> But the context idea could be useful for other objects that it may need
> to access.
>. . .

ok, It wasn't clear for me either what would go into the context object, but 
it is certainly better that passing the FO object directly.

>. . .
> I'm not sure about the best way to do things like the table columns. It
> would be simpler if it could do a start table after it has all the table
> columns rather than needing to get each table column individually
> through method calls.
>. . .

Would this scenario be easy to implement?

startTable
  startRow (maybe after all FOs for the row have been parsed)
startCell (maybe  after all FOs for the cell have been parsed)
  start/end stuff for cell contents
endCell
more start/endCell
  endRow
  more start/endRow
endTable

or do you mean just one startTable with row/columns contained in the FO?

I'd prefer many event calls, as the StructureHandler wouldn't need to know as 
much about FOs in this case. Conceptually (and this might be useful for 
concrete stuff like testing too), I think the StructureHandler needs to 
be able to rebuild the XSL-FO structure with as little code as possible.

Maybe (if easier to implement or to avoid slowing down PDF 
rendering) this "event generation" can be done by an intermediate component 
that "decodes" the FOs and generates detailed events?

-Bertrand


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Structure Handlers - RTF Renderer

[Keiron Liddle]

Hi Bertrand,

On Fri, 2002-05-24 at 15:25, Bertrand Delacretaz wrote:
> > It will pass appropriate information, mostly the
> > current fo object.
> 
> Maybe passing a compound object (StructureRendererContext?) that *contains* 
> the current fo object would help, as the renderer might need to access 
> configuration, logging or other services.

We should be able to set common objects like the logging and config on
the structure handler itself.
But the context idea could be useful for other objects that it may need
to access.

> Looks good to me - basing the current rendering process on the structure 
> rendering stuff certainly makes sense.
> 
> If I get it right, the processing pipeline would then look as follows:
> parsing -> SAX events -> validation -> attribute resolution -> structure 
> rendering (SR)
> 
> Where SR is either "RTF rendering" or "layout -> PDF rendering"

Yes.
Where the validation is done by the FO tree and attribute resolution is
handled by the current property handling system.
The RTF handler will get the fo java object, then it can get the
properties and children (at the end).

I'm not sure about the best way to do things like the table columns. It
would be simpler if it could do a start table after it has all the table
columns rather than needing to get each table column individually
through method calls.

Keiron.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]