SV: blank screen in browser

[Klosa Uwe]

Hi Mike,

it's an old problem with IE.
If you do a refresh/reload in IE the pdf should appear on the screen.

But there are several solutions:

Try a &file=.pdf at the end of the url

Change the source of fop. There is somewhere a close outputstream
missing, but i forgot where it was. Search in the list archive.

Embed some tt-font in the output. This makes it also working. Don't
why.

Regards Uwe

-Ursprungligt meddelande-
Från: Zahigian, Mike [mailto:[EMAIL PROTECTED]]
Skickat: den 21 november 2002 19:59
Till: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Ämne: blank screen in browser


I am using FOP embedded in a Servlet.  Users trigger the servlet by clicking
a button on a web page.  The servlet then takes the response and performs a
transformation and renders to pdf.  The browser pops up a new window and
displays the pdf output.  1% or so of my user population cannot get the pdf
to display in the browser window that pops up (or any other browser window).
These users can open pdf files that exist on their local machine.  When
these users click the print button on my web page, the new browser window
pops up, but the contents are blank.  Any idea what is going on?

Mike Z.

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

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

RE: Alt-Design status: XML handling

[Keiron Liddle]

On Thu, 2002-11-21 at 21:14, Victor Mote wrote:
> OK, I just went back & reread it. There is still something I don't
> understand & I'll get to that in a minute. First, let me say that perhaps
> the better way for me to learn this would be to follow it in a debugger. I'm
> not too lazy to do that, and if /these issues/ are working pretty well right
> now, then that is probably what I should be doing -- just say the word.
> 
> Here is what (after reading the doc & considering your comments) my thick
> head doesn't yet grasp -- when we say the page is "cached", I understood
> that to mean that it is immutably laid out, but that it can't be rendered
> yet because some previous page cannot be finally laid out yet. What I am
> trying to address is the situation, like the auto table layout, where
> something I see while trying to lay out page 5000 changes pages 150-4999 as
> well. I have to now push some rows or lines from 150 to 151, which triggers
> pushing some lines from 151 to 152, etc. So the first question is whether
> the cached pages are changeable or unchangeable. If changeable, then we
> should be able to deal with arbitrarily long documents and (assuming some
> reasonable amount of basic memory) not worry about running out of memory --
> constrained only by disk space.

I see. That is a different angle than what I was thinking of.

The fo tree knows nothing about the area tree (in theory, some inline
areas are created in the fo tree for convenience at the moment) and the
two are completely separate.
The layout manager is the bridge between these two constructs. The
layout mangers first do the layout and then once the layout is complete,
except page reference, then it adds the areas to the area tree.

So in your scenario with an auto table layout. It does not start
creating and adding areas (to pages 150-4999) until it has reached page
5000 and has worked out the width of the columns.

So yes the area tree is immutably laid out and plays no part in the
layout process. Adding/adjusting and removing areas from the area tree
makes it much more complex and error prone. So the design is that the
area tree is a simple data structure that is created and used by the
renderers. The layout managers only create the area tree.

So the area tree plays its part in allowing for arbitrarily long
documents, by rendering pages as soon as possible, when added to the
area tree or allowing the caching of pages if it cannot render
immediately.

Now it is true that it is only part of the solution. To allow for the
important ability to do arbitrarily long documents it will also need to
handle the fo tree and layout manager information so that it can be
cached or kept minimal.

It might not be so obvious in the code but the layout managers work by
first getting breaks in a break position, then once the breaks are
decided it will add the areas that correspond to the breaks. So it is a
two step process that should be considered separately. Obviously adding
areas is dependant on the structure of the break information.


> The second question that I am trying to grasp is, if the cached pages are
> changeable, then how do we know enough to change those 4850 pages properly
> without having our fo tree at hand unless we duplicate the information from
> the fo tree in the area tree.

As above they are not changeable, the layout manager will change it's
breaks using the information from the fo tree.

> You are correct for the current use-case. I have jumped a bit past that into
> trying to make room for other use-cases that might require the fo to be
> changed and serialized (the WYSIWIG). Setting that issue aside for the
> moment, let me rephrase the question, because this is really the huge big
> issue that makes me uneasy with SAX. Don't we need random access to the fo
> tree for the current page sequence?
>   * If so, then, using SAX, don't we have to duplicate that same
> information in the area tree to be able to handle rebuilding
> 4850 pages?

That is true, the information must be somewhere for it to correctly do
the 4850 pages and I can't say that I really have an anwser to where it
should be except not in the area tree.

For live editing I think the situation would be the same. The layout
managers would adjust the layout and then recreate the areas and pages.

> OK, I see where I was not clear. In my mind, if there is no fo tree to tie
> the pieces of the area tree to, you basically have to build one. This is why
> I brought up Word & FrameMaker -- their object models keep the organization
> of the document (analagous to our fo tree) intact. My theory is that we
> eventually hurt ourselves by trying to avoid this. The difference is that
> they have to serialize that organization, and we don't, at least for our
> current use case. However, perhaps because I am still confused about our
> general strategy for dealing with the ripple-effect of downstream changes,
> their model seems to be a good one. I am envisioning an 

cvs commit: xml-fop/src/org/apache/fop/datatypes CountryLanguageScript.java

[pbwest]

pbwest  2002/11/21 18:54:56

  Added:   src/org/apache/fop/datatypes Tag: FOP_0-20-0_Alt-Design
CountryLanguageScript.java
  Log:
  Generated by XSL from xml-lang.xml
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +3341 -0   
xml-fop/src/org/apache/fop/datatypes/Attic/CountryLanguageScript.java
  
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/datatypes NCName.java

[pbwest]

pbwest  2002/11/21 18:51:45

  Modified:src/org/apache/fop/datatypes Tag: FOP_0-20-0_Alt-Design
NCName.java
  Log:
  Fixed RCS problems.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.7   +3 -3  xml-fop/src/org/apache/fop/datatypes/Attic/NCName.java
  
  Index: NCName.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/datatypes/Attic/NCName.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo FObjectSets.java FObjects.java FONode.java FOPropertySets.java FOTree.java ShorthandPropSets.java

[pbwest]

pbwest  2002/11/21 18:48:35

  Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
FObjectSets.java FObjects.java FONode.java
FOPropertySets.java FOTree.java
ShorthandPropSets.java
  Log:
  Fixed RCS problems.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.4   +2 -2  xml-fop/src/org/apache/fop/fo/Attic/FObjectSets.java
  
  Index: FObjectSets.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/FObjectSets.java,v
  retrieving revision 1.1.2.3
  retrieving revision 1.1.2.4
  diff -u -r1.1.2.3 -r1.1.2.4
  
  
  
  1.1.2.11  +3 -3  xml-fop/src/org/apache/fop/fo/Attic/FObjects.java
  
  Index: FObjects.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/FObjects.java,v
  retrieving revision 1.1.2.10
  retrieving revision 1.1.2.11
  diff -u -r1.1.2.10 -r1.1.2.11
  
  
  
  1.19.2.28 +3 -3  xml-fop/src/org/apache/fop/fo/FONode.java
  
  Index: FONode.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/FONode.java,v
  retrieving revision 1.19.2.27
  retrieving revision 1.19.2.28
  diff -u -r1.19.2.27 -r1.19.2.28
  
  
  
  1.1.2.10  +3 -3  xml-fop/src/org/apache/fop/fo/Attic/FOPropertySets.java
  
  Index: FOPropertySets.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/FOPropertySets.java,v
  retrieving revision 1.1.2.9
  retrieving revision 1.1.2.10
  diff -u -r1.1.2.9 -r1.1.2.10
  
  
  
  1.1.2.26  +3 -3  xml-fop/src/org/apache/fop/fo/Attic/FOTree.java
  
  Index: FOTree.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/FOTree.java,v
  retrieving revision 1.1.2.25
  retrieving revision 1.1.2.26
  diff -u -r1.1.2.25 -r1.1.2.26
  
  
  
  1.1.2.6   +3 -3  xml-fop/src/org/apache/fop/fo/Attic/ShorthandPropSets.java
  
  Index: ShorthandPropSets.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/ShorthandPropSets.java,v
  retrieving revision 1.1.2.5
  retrieving revision 1.1.2.6
  diff -u -r1.1.2.5 -r1.1.2.6
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/declarations FoColorProfile.java FoDeclarations.java

[pbwest]

pbwest  2002/11/21 18:17:22

  Modified:src/org/apache/fop/fo/declarations Tag:
FOP_0-20-0_Alt-Design FoColorProfile.java
FoDeclarations.java
  Log:
  REmoved numProps arg to super constructor.
  DECLARATIONS_SET now in FONode.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.2   +3 -5  
xml-fop/src/org/apache/fop/fo/declarations/Attic/FoColorProfile.java
  
  Index: FoColorProfile.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/org/apache/fop/fo/declarations/Attic/FoColorProfile.java,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- FoColorProfile.java   5 Nov 2002 14:11:52 -   1.1.2.1
  +++ FoColorProfile.java   22 Nov 2002 02:17:22 -  1.1.2.2
  @@ -11,7 +11,6 @@
   
   // FOP
   import org.apache.fop.fo.PropNames;
  -import org.apache.fop.fo.FOPropertySets;
   import org.apache.fop.fo.PropertySets;
   import org.apache.fop.fo.FObjectNames;
   import org.apache.fop.fo.FONode;
  @@ -83,8 +82,7 @@
   throws TreeException, FOPException
   {
   super(foTree, FObjectNames.COLOR_PROFILE, parent, event,
  -  FOPropertySets.DECLARATIONS_SET, sparsePropsMap, sparseIndices,
  -  numProps);
  +  FONode.DECLARATIONS_SET, sparsePropsMap, sparseIndices);
   makeSparsePropsSet();
   }
   
  
  
  
  1.1.2.2   +4 -6  
xml-fop/src/org/apache/fop/fo/declarations/Attic/FoDeclarations.java
  
  Index: FoDeclarations.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/org/apache/fop/fo/declarations/Attic/FoDeclarations.java,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- FoDeclarations.java   5 Nov 2002 14:11:52 -   1.1.2.1
  +++ FoDeclarations.java   22 Nov 2002 02:17:22 -  1.1.2.2
  @@ -5,7 +5,6 @@
   import java.util.NoSuchElementException;
   
   import org.apache.fop.apps.FOPException;
  -import org.apache.fop.fo.FOPropertySets;
   import org.apache.fop.fo.FObjectNames;
   import org.apache.fop.fo.FOTree;
   import org.apache.fop.fo.FONode;
  @@ -70,8 +69,7 @@
   throws TreeException, FOPException, PropertyException
   {
   super(foTree, FObjectNames.DECLARATIONS, parent, event,
  -  FOPropertySets.DECLARATIONS_SET, sparsePropsMap, sparseIndices,
  -  numProps);
  +  FONode.DECLARATIONS_SET, sparsePropsMap, sparseIndices);
   try {
   FoXMLEvent ev =
   xmlevents.expectStartElement
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/expr PropertyParser.java

[pbwest]

pbwest  2002/11/21 18:07:04

  Modified:src/org/apache/fop/fo/expr Tag: FOP_0-20-0_Alt-Design
PropertyParser.java
  Log:
  Correcting RCS problems.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.5.2.19  +2 -2  xml-fop/src/org/apache/fop/fo/expr/PropertyParser.java
  
  Index: PropertyParser.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/expr/PropertyParser.java,v
  retrieving revision 1.5.2.18
  retrieving revision 1.5.2.19
  diff -u -r1.5.2.18 -r1.5.2.19
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/flow FoTableAndCaption.java FoTableBody.java FoTableCaption.java FoTableCell.java FoTableColumn.java FoTableFooter.java FoTableHeader.java FoTable.java FoTableRow.java FoTitle.java FoWrapper.java

[pbwest]

pbwest  2002/11/21 17:05:24

  Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoTableAndCaption.java FoTableBody.java
FoTableCaption.java FoTableCell.java
FoTableColumn.java FoTableFooter.java
FoTableHeader.java FoTable.java FoTableRow.java
FoTitle.java FoWrapper.java
  Log:
  Fix RCS problems.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableAndCaption.java
  
  Index: FoTableAndCaption.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableAndCaption.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableBody.java
  
  Index: FoTableBody.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableBody.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableCaption.java
  
  Index: FoTableCaption.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableCaption.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableCell.java
  
  Index: FoTableCell.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableCell.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableColumn.java
  
  Index: FoTableColumn.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableColumn.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableFooter.java
  
  Index: FoTableFooter.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableFooter.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableHeader.java
  
  Index: FoTableHeader.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableHeader.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoTable.java
  
  Index: FoTable.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTable.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableRow.java
  
  Index: FoTableRow.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableRow.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoTitle.java
  
  Index: FoTitle.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTitle.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoWrapper.java
  
  Index: FoWrapper.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoWrapper.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/flow FoMarker.java FoMultiCase.java FoMultiProperties.java FoMultiPropertySet.java FoMultiSwitch.java FoMultiToggle.java FoNoFo.java FoPageNumberCitation.java FoPageNumber.java FoPageSequence.java FoPcdata.java FoRetrieveMarker.java FoStaticContent.java

[pbwest]

pbwest  2002/11/21 16:46:27

  Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoMarker.java FoMultiCase.java
FoMultiProperties.java FoMultiPropertySet.java
FoMultiSwitch.java FoMultiToggle.java FoNoFo.java
FoPageNumberCitation.java FoPageNumber.java
FoPageSequence.java FoPcdata.java
FoRetrieveMarker.java FoStaticContent.java
  Log:
  Fix RCS proplems.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoMarker.java
  
  Index: FoMarker.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoMarker.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoMultiCase.java
  
  Index: FoMultiCase.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoMultiCase.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoMultiProperties.java
  
  Index: FoMultiProperties.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoMultiProperties.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoMultiPropertySet.java
  
  Index: FoMultiPropertySet.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoMultiPropertySet.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoMultiSwitch.java
  
  Index: FoMultiSwitch.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoMultiSwitch.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoMultiToggle.java
  
  Index: FoMultiToggle.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoMultiToggle.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoNoFo.java
  
  Index: FoNoFo.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoNoFo.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  
xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageNumberCitation.java
  
  Index: FoPageNumberCitation.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageNumberCitation.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageNumber.java
  
  Index: FoPageNumber.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageNumber.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.5   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageSequence.java
  
  Index: FoPageSequence.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageSequence.java,v
  retrieving revision 1.1.2.4
  retrieving revision 1.1.2.5
  diff -u -r1.1.2.4 -r1.1.2.5
  
  
  
  1.1.2.5   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoPcdata.java
  
  Index: FoPcdata.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoPcdata.java,v
  retrieving revision 1.1.2.4
  retrieving revision 1.1.2.5
  diff -u -r1.1.2.4 -r1.1.2.5
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoRetrieveMarker.java
  
  Index: FoRetrieveMarker.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoRetrieveMarker.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  

cvs commit: xml-fop/src/org/apache/fop/fo/flow FoCharacter.java FoExternalGraphic.java FoFlow.java FoFootnote.java FoInitialPropertySet.java FoInlineContainer.java FoInline.java FoInstreamForeignObject.java FoLeader.java FoListBlock.java FoListItemBody.java FoListItem.java FoListItemLabel.java

[pbwest]

pbwest  2002/11/21 16:35:31

  Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoCharacter.java FoExternalGraphic.java FoFlow.java
FoFootnote.java FoInitialPropertySet.java
FoInlineContainer.java FoInline.java
FoInstreamForeignObject.java FoLeader.java
FoListBlock.java FoListItemBody.java
FoListItem.java FoListItemLabel.java
  Log:
  Correcting RCS problems.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoCharacter.java
  
  Index: FoCharacter.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoCharacter.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoExternalGraphic.java
  
  Index: FoExternalGraphic.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoExternalGraphic.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.5   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoFlow.java
  
  Index: FoFlow.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoFlow.java,v
  retrieving revision 1.1.2.4
  retrieving revision 1.1.2.5
  diff -u -r1.1.2.4 -r1.1.2.5
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoFootnote.java
  
  Index: FoFootnote.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoFootnote.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  
xml-fop/src/org/apache/fop/fo/flow/Attic/FoInitialPropertySet.java
  
  Index: FoInitialPropertySet.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoInitialPropertySet.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoInlineContainer.java
  
  Index: FoInlineContainer.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoInlineContainer.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoInline.java
  
  Index: FoInline.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoInline.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.8   +2 -2  
xml-fop/src/org/apache/fop/fo/flow/Attic/FoInstreamForeignObject.java
  
  Index: FoInstreamForeignObject.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoInstreamForeignObject.java,v
  retrieving revision 1.1.2.7
  retrieving revision 1.1.2.8
  diff -u -r1.1.2.7 -r1.1.2.8
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoLeader.java
  
  Index: FoLeader.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoLeader.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoListBlock.java
  
  Index: FoListBlock.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoListBlock.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoListItemBody.java
  
  Index: FoListItemBody.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoListItemBody.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoListItem.java
  
  Index: FoListItem.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoListItem.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.

DO NOT REPLY [Bug 14319] - Three problems in custom font metrics-file and embed-file value

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

Three problems in custom font metrics-file and embed-file value

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-22 00:07 ---
Fixed in cvs. Thanks to Jeremias.
I verified it with com.icl.saxon.aelfred.SAXDriver, works fine.

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

DO NOT REPLY [Bug 14419] - Imlplement SourceResolver, Image Resolver

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

Imlplement SourceResolver, Image Resolver

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 23:34 ---
*** Bug 4348 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 4348] - FOP has no mechanism to extend protocols

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

FOP has no mechanism to extend protocols

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 23:34 ---


*** This bug has been marked as a duplicate of 14419 ***

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

Re: org.apache.fop.viewer.PreviewDialog

[IvanLatysh]

Hello, Oleg!
You wrote to <[EMAIL PROTECTED]> on Wed, 20 Nov 2002 18:02:59 +0200:

 >> Just curious - why you recreate the dialog? You can use 1 instance
 >> and  to show/hide it by setVisible(boolean) method.
 >> But you maight be right, because PreviewDialog is not designed to be 
 >> reusable and recreatable.
 OT> Anyway, look at reload functionality, it solves the same problem by
 OT> cleaning  up renderer, internal counters, page image etc.
I didn't answer because I decide to go dipper into the code.

And I did figure out, that there are no way to reuse PreviewDialog.
I wrote panelPreview which I am going to use instead of PreviewDialog.

And I am experience a major problem with AWTRenderer, this renderer couldn't be reused.
I have to recreate it each time. It is terrific.

If someone interesting in my code, let me know.

---
Yours sincerely, Ivan Latysh.
IvanLatysh[a]yahoo.ca


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

Re: default page width

[W. Eliot Kimber]

Oleg Tkachenko wrote:

Hello!

I'm about to fix bug #10158 and I wonder, why in FOP default page width 
is 8in although spec recommends 8.26in[1]. Well, actually in absence of 
User Agent page width is implementation-defined, so we can leave 8in 
happily (actually XEP also uses 8x11in defaults, but Antenna - 8,26x11).
Opinions?

8.26--that gives you the A4 width and US length, that is, the universal 
page size that will give acceptable results on either US or A4 paper.

Cheers,

E.
--
W. Eliot Kimber, [EMAIL PROTECTED]
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139


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

default page width

[Oleg Tkachenko]

Hello!

I'm about to fix bug #10158 and I wonder, why in FOP default page width 
is 8in although spec recommends 8.26in[1]. Well, actually in absence of 
User Agent page width is implementation-defined, so we can leave 8in 
happily (actually XEP also uses 8x11in defaults, but Antenna - 8,26x11).
Opinions?

[1] http://www.w3.org/TR/xsl/slice7.html#page-width
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


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

cvs commit: xml-fop/src/org/apache/fop/fonts TTFSubSetFile.java

[klease]

klease  2002/11/21 13:58:49

  Modified:src/org/apache/fop/fonts Tag: fop-0_20_2-maintain
TTFSubSetFile.java
  Log:
  Correct ordering of loca table in embedded true type fonts
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.5.2.3   +46 -23xml-fop/src/org/apache/fop/fonts/TTFSubSetFile.java
  
  Index: TTFSubSetFile.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fonts/TTFSubSetFile.java,v
  retrieving revision 1.5.2.2
  retrieving revision 1.5.2.3
  diff -u -r1.5.2.2 -r1.5.2.3
  --- TTFSubSetFile.java8 Nov 2002 10:25:26 -   1.5.2.2
  +++ TTFSubSetFile.java21 Nov 2002 21:58:49 -  1.5.2.3
  @@ -311,31 +311,44 @@
   pad4();
   start = currentPos;
   
  +/* Loca table must be in order by glyph index, so build
  + * an array first and then write the glyph info and
  + * location offset.
  + */
  +int[] origIndexes = new int[glyphs.size()];
  +
   for (Iterator e = glyphs.keySet().iterator(); e.hasNext(); ) {
  -int glyphLength = 0;
   Integer origIndex = (Integer)e.next();
   Integer subsetIndex = (Integer)glyphs.get(origIndex);
  +origIndexes[subsetIndex.intValue()] = origIndex.intValue();
  +}
   
  +for (int i=0;i= (mtx_tab.length - 1))
  +int origGlyphIndex = origIndexes[i];
  +if (origGlyphIndex >= (mtx_tab.length - 1)) {
   nextOffset = (int)lastLoca;
  -else
  +}
  +else {
   nextOffset =
  -(int)mtx_tab[origIndex.intValue() + 1].offset;
  -
  +(int)mtx_tab[origGlyphIndex + 1].offset;
  +}
   glyphLength = nextOffset
  -  - (int)mtx_tab[origIndex.intValue()].offset;
  +  - (int)mtx_tab[origGlyphIndex].offset;
   
   // Copy glyph
  -System.arraycopy(in.getBytes((int)entry.offset + 
(int)mtx_tab[origIndex.intValue()].offset, glyphLength),
  +System.arraycopy(in.getBytes((int)entry.offset +
  +   (int)mtx_tab[origGlyphIndex].offset,
  +   glyphLength),
0, output, currentPos, glyphLength);
   
   
   // Update loca table
  -writeULong(locaOffset + subsetIndex.intValue() * 4,
  -   currentPos - start);
  -if ((currentPos - start + glyphLength) > endOffset)
  +writeULong(locaOffset + i * 4, currentPos - start);
  +if ((currentPos - start + glyphLength) > endOffset) {
   endOffset = (currentPos - start + glyphLength);
  +}
   
   currentPos += glyphLength;
   realSize += glyphLength;
  @@ -426,17 +439,21 @@
   offset += 2;
   }
   
  -if ((flags & 8) > 0)
  +if ((flags & 8) > 0) {
   offset += 2;// WE_HAVE_A_SCALE
  -else if ((flags & 64) > 0)
  +}
  +else if ((flags & 64) > 0) {
   offset += 4;// WE_HAVE_AN_X_AND_Y_SCALE
  -else if ((flags & 128) > 0)
  +}
  +else if ((flags & 128) > 0) {
   offset += 8;// WE_HAVE_A_TWO_BY_TWO
  -
  -if ((flags & 32) > 0)
  +}
  +if ((flags & 32) > 0) {
   moreComposites = true;
  -else
  +}
  +else {
   moreComposites = false;
  +}
   }
   
   return ret;
  @@ -491,10 +508,12 @@
   offset += 8;// WE_HAVE_A_TWO_BY_TWO
   }
   
  -if ((flags & 32) > 0)
  +if ((flags & 32) > 0) {
   moreComposites = true;
  -else
  +}
  +else {
   moreComposites = false;
  +}
   }
   }
   
  @@ -576,8 +595,9 @@
* Check if TrueType collection, and that the name
* exists in the collection
*/
  -if (!checkTTC(in, name, false))
  +if (!checkTTC(in, name, false)) {
   throw new IOException("Failed to read font");
  +}
   
   output = new byte[in.getFileSize()];
   
  @@ -733,8 +753,9 @@
*/
   private int readUShort(int pos) {
   int ret = (int)output[pos];
  -if (ret < 0)
  +if (ret < 0) {
   ret += 256;
  +}
   ret = ret << 8;
   if ((in

Re: [maintenance branch] FOP servlet doubled

[Jeremias Maerki]

Yes, dump that directory. That's redundancy. We just have to make sure,
that the documentation points the right way, too.

On 21.11.2002 20:41:21 Oleg Tkachenko wrote:
> FOP sample servlets are now at contrib/servlet directory and look fine, 
> but docs/examples/embedding still contains kind of partial copy - java 
> sources and old buggy fop.war. Lets remove docs/examples/embedding 
> directory altogether or at least this second fop.war?


Jeremias Maerki


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

RE: Background information about using unicode characters

[Victor Mote]

Markus (Schaeffler?) wrote:

> like the whole codepage in which the charater is in? Or which
> information are
> exactly embedded into the pdf file? Can I rely on the assumption that the
> pdf file with the embedded font will be displayed correctly
> independingly on
> the
> operating system and the available fonts on which ever computer
> the pdf file
> is trying to be viewed?

AFAIK, the entire font is embedded in the PDF. On o/s independence, yes,
that is the whole theory behind PDF. There are occasional differences
between PDF viewers that might be though of as platform-related, but in
general, PDF is intended to be platform- and device-independent, and in
practice seems to work pretty well.

> Is it possible to create a PDF file with FOP which just describes a
> character by its unicode representation and the corresponding
> glyph to display the
> character is loaded from one of the available fonts from the
> computer where the
> pdf file is viewed? That would be an interesting an valueable feature
> instead of embedding the font file.

Yes, simply don't embed the file. The risk is that if the font is not on the
other system or is different, it may not look as intended.

BTW, you will get faster and better responses to questions like this on the
fop-user list, or, better yet, on a PDF list.

Victor Mote


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

RE: Alt-Design status: XML handling

[Victor Mote]

Oleg Tkachenko wrote:

> I think we should separate fo tree itself from the process of its
> building. fo
> tree structure is required and I agree with Keiron - it's not a
> DOM, it's just
> tree representation and I cherish the idea to make it an
> effectively small
> structure like saxon's internal tree. But any interim buffers should be
> avoided as much as it's possible (well, Piter's buffer seems not
> to be a burden).

This is probably a philosophical difference. It seems to me that the area
tree is built on the foundation of the fo tree, and that if we only get a
brief glimpse of the fo tree as it goes by, not only does our foundation
disappear, but we end up putting all of that weight into the superstructure,
which tends to make the whole thing collapse.

> > To conclude, if I were designing this system from scratch,
> based on what I
> > know right now, I would:
> > 1. Use DOM for both the fo tree & the area tree.
> Bad idea, I believe. DOM is heaviweight versatile representation of xml
> document (recall entities, pi's etc nodes), while we need effective and
> lightweight structure to hold fo/area tree information. DOM has a lot of
> synchronization stuff, while our trees are almost read-only actually.
> Ahh stop, probably you didn't mean w3c DOM?

You and Keiron are right -- this is a classic example of using an
implementation where an interface would be much better. When I say DOM, what
I should say is "some randomly-accessible view of the entire tree."
Certainly, if there is a lighter-weight alternative than DOM that works for
the task at hand, that is better.

Victor Mote


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

DO NOT REPLY [Bug 11902] - fopDriver.getResults().getPageCount() returns wrong page count

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

fopDriver.getResults().getPageCount() returns wrong page count

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 20:27 ---
Fixed already in cvs.

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

RE: Alt-Design status: XML handling

[Victor Mote]

Keiron Liddle wrote:

> On Thu, 2002-11-21 at 12:43, Victor Mote wrote:
> > To conclude, if I were designing this system from scratch,
> based on what I
> > know right now, I would:
> > 1. Use DOM for both the fo tree & the area tree.
>
> I don't know whether I would call it a DOM but the area tree is an
> independant data structure that contains all the information necessary
> to render the document.
>
>
> > 2. Write them to disk when necessary, hiding all of this from the layout
> > managers.
>
> This has already been done for the area tree. I use the
> CachedRenderPagesModel all the time. If it cannot render the page
> immediately then it saves it to disk. The layout managers only know
> about adding areas to a page and then adding the page to the area tree.
> For rendering it can dispose of the page once rendered, for awt viewer
> it could save all pages to disk and load when necessary.
>
> As described here (written a long time ago and needs updating):
> http://xml.apache.org/fop/design/areas.html

OK, I just went back & reread it. There is still something I don't
understand & I'll get to that in a minute. First, let me say that perhaps
the better way for me to learn this would be to follow it in a debugger. I'm
not too lazy to do that, and if /these issues/ are working pretty well right
now, then that is probably what I should be doing -- just say the word.

Here is what (after reading the doc & considering your comments) my thick
head doesn't yet grasp -- when we say the page is "cached", I understood
that to mean that it is immutably laid out, but that it can't be rendered
yet because some previous page cannot be finally laid out yet. What I am
trying to address is the situation, like the auto table layout, where
something I see while trying to lay out page 5000 changes pages 150-4999 as
well. I have to now push some rows or lines from 150 to 151, which triggers
pushing some lines from 151 to 152, etc. So the first question is whether
the cached pages are changeable or unchangeable. If changeable, then we
should be able to deal with arbitrarily long documents and (assuming some
reasonable amount of basic memory) not worry about running out of memory --
constrained only by disk space.

The second question that I am trying to grasp is, if the cached pages are
changeable, then how do we know enough to change those 4850 pages properly
without having our fo tree at hand unless we duplicate the information from
the fo tree in the area tree.

> I don't see why you would need all the fo tree available, each page
> sequence is independant for the flow and often each page can be finished
> before the next page.

You are correct for the current use-case. I have jumped a bit past that into
trying to make room for other use-cases that might require the fo to be
changed and serialized (the WYSIWIG). Setting that issue aside for the
moment, let me rephrase the question, because this is really the huge big
issue that makes me uneasy with SAX. Don't we need random access to the fo
tree for the current page sequence?
  * If so, then, using SAX, don't we have to duplicate that same
information in the area tree to be able to handle rebuilding
4850 pages?
  * If not, then, in a big-picture way, how do we go about
rebuilding 4850 pages?

> > 3. Use an event-based layout mechanism so that the fo tree
> doesn't even have
> > to be there to get layout work done.
>
> Depends exactly what you mean but I think that is the general idea, care
> to implement it.

OK, I see where I was not clear. In my mind, if there is no fo tree to tie
the pieces of the area tree to, you basically have to build one. This is why
I brought up Word & FrameMaker -- their object models keep the organization
of the document (analagous to our fo tree) intact. My theory is that we
eventually hurt ourselves by trying to avoid this. The difference is that
they have to serialize that organization, and we don't, at least for our
current use case. However, perhaps because I am still confused about our
general strategy for dealing with the ripple-effect of downstream changes,
their model seems to be a good one. I am envisioning an area tree that
contains no text at all, but whose objects merely point to nodes & offsets &
sizes in the fo tree. So, for example Line object l contains an array of
LineSegment objects, one of whose contents comes from an FOText node,
starting at offset 16, size 22. Not only is my text there, but so is most of
my font and formatting information. What I have is two different views of
the same data -- one that is more structural and the other the specific
layout. I have no problem (in our current use-case) with throwing away
page-sequences from the fo tree and area tree to free up memory as we go.

> Does or could
> > the new design give us the ability to (with say, a configuration option)
> > choose between Layout Philosophy A and B? By this I mean 2 (or
> more) layout
> > packages coexisting in the same code base, and s

DO NOT REPLY [Bug 14419] - Imlplement SourceResolver, Image Resolver

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

Imlplement SourceResolver, Image Resolver

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 20:09 ---
*** Bug 9880 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 9880] - URL-Authentication in org.apache.fop.image

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

URL-Authentication in org.apache.fop.image

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 20:09 ---


*** This bug has been marked as a duplicate of 14419 ***

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

DO NOT REPLY [Bug 4695] - Fop v0.20.1: docs/examples/embedding/web.xml is invalid

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

Fop v0.20.1: docs/examples/embedding/web.xml is invalid

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 19:45 ---
This web.xml is obsolete. New (and valid) one is now at contrib/servlet/conf.

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

[maintenance branch] FOP servlet doubled

[Oleg Tkachenko]

Hello!

FOP sample servlets are now at contrib/servlet directory and look fine, 
but docs/examples/embedding still contains kind of partial copy - java 
sources and old buggy fop.war. Lets remove docs/examples/embedding 
directory altogether or at least this second fop.war?

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


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

blank screen in browser

[Zahigian, Mike]

I am using FOP embedded in a Servlet.  Users trigger the servlet by clicking
a button on a web page.  The servlet then takes the response and performs a
transformation and renders to pdf.  The browser pops up a new window and
displays the pdf output.  1% or so of my user population cannot get the pdf
to display in the browser window that pops up (or any other browser window).
These users can open pdf files that exist on their local machine.  When
these users click the print button on my web page, the new browser window
pops up, but the contents are blank.  Any idea what is going on?

Mike Z.

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

DO NOT REPLY [Bug 11614] - DocBook programlistings are garbled in PDF, etc

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

DocBook programlistings are garbled in PDF, etc





--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 17:32 ---
I know; see the bottom of the one report I linked:
http://www.pinkjuice.com/temp/fop/fop.txt
I either made a mistake, or there was/is a problem with using it on Windows.

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

DO NOT REPLY [Bug 11614] - DocBook programlistings are garbled in PDF, etc

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

DocBook programlistings are garbled in PDF, etc

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 17:27 ---
Well, you need jimi library to work with png images, see
http://xml.apache.org/fop/relnotes.html. And for the other stuff new docbook-xsl
seems to a remedy.

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

DO NOT REPLY [Bug 14319] - Three problems in custom font metrics-file and embed-file value

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

Three problems in custom font metrics-file and embed-file value

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 17:04 ---
*** Bug 11838 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 11838] - Error when use a user configuartion font file in embedded FOP

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

Error when use a user configuartion font file in embedded FOP

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 17:04 ---


*** This bug has been marked as a duplicate of 14319 ***

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

DO NOT REPLY [Bug 14319] - Three problems in custom font metrics-file and embed-file value

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

Three problems in custom font metrics-file and embed-file value

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 16:54 ---
*** Bug 10287 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 10287] - fop 0.20.4RC is unable to run with Aelfred xml parser

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

fop 0.20.4RC is unable to run with Aelfred xml parser

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 16:54 ---


*** This bug has been marked as a duplicate of 14319 ***

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

RE: Style guide (2nd update)

[Rhett Aultman]

It's my understanding that, for certain object types, the compiler can use "final" 
designation as a flag for further optimizations and so it actually might be a wise 
idea to do.  If nothing else, I remember reading an interview with James Gosling on 
"object mutability", a compiler optimization whereby a final object can be decomposed 
into certain constituents (since it will never be altered).

Personally, I just don't use final designations in the way it's shown because it 
doesn't occur to me that it's important. ;)

-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 11:42 AM
To: [EMAIL PROTECTED]
Subject: Re: Style guide (2nd update)


On Thursday 21 November 2002 17:31, Oleg Tkachenko wrote:
>. . .
>   final String myString = (String)myListIterator.next();
>. . .
> How do you think, is this final specifier only a style oriented or it have
> some performance benefit also?

I don't know about performance, but I use it all the time anyway as it makes 
intentions clearer and can save the day by preventing someone from messing up 
with the variable value.

-Bertrand

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


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

Re: Style guide (2nd update)

[Bertrand Delacretaz]

On Thursday 21 November 2002 17:31, Oleg Tkachenko wrote:
>. . .
>   final String myString = (String)myListIterator.next();
>. . .
> How do you think, is this final specifier only a style oriented or it have
> some performance benefit also?

I don't know about performance, but I use it all the time anyway as it makes 
intentions clearer and can save the day by preventing someone from messing up 
with the variable value.

-Bertrand

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

Re: Style guide (2nd update)

[Bertrand Delacretaz]

On Thursday 21 November 2002 17:16, Jeremias Maerki wrote:
>. . .
> The MUST part is very small and establishes some hard rules. I'll try to
> do the final layout in XML in a way that takes this into consideration.

ok, cool!

>. . .
> By the way, due to common desire I added a few lines on exception
> handling and a few other items that I found were agreed upon in recent
> discussion.

I added note 4 to propose a different/additional way of saying that 
exceptions are important.

I'd put this stuff about exceptions as a subsection in the MUSTS, 
this so much more important than brace placement ;-)

-Bertrand

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

Re: Style guide (2nd update)

[Oleg Tkachenko]

Hello!

btw, I have a q about avalon's pattern:
while( myListIterator.hasNext() )
 {
 final String myString = (String)myListIterator.next();
 }
How do you think, is this final specifier only a style oriented or it have 
some performance benefit also?

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


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

Re: Style guide (2nd update)

[Jeremias Maerki]

On 20.11.2002 18:05:33 Bertrand Delacretaz wrote:
> I voted -1 on most TBD stuff, braces and spaces are not really important IMHO 
> and I think it's good that the style guide stays as small as possible.

Also my opinion, though I think some good advice and best practices are
not bad. We've had discussions about certain points every now and then.
That's why I've split the Java conventions into a MUST and a SHOULD part.
The MUST part is very small and establishes some hard rules. I'll try to
do the final layout in XML in a way that takes this into consideration.

By the way, due to common desire I added a few lines on exception
handling and a few other items that I found were agreed upon in recent
discussion. You can still put -1s where you don't like something I've
done. As soon as Jörg is back (because he started the discussion in
August) I'd like to hold a formal voting process for accepting the style
guide.  When all points are resolved I'll transform the Wiki page to XML.


Jeremias Maerki


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

Opinion poll: Additional utility jars

[Jeremias Maerki]

I'm stumbling over code blocks every now and then that could/should be
reused or even used from a common library. Examples of that are stream
copying code, little/big endian conversions etc. This is mostly little
stuff but these things wouldn't need to be in our codebase. Sometimes
there's code around that could simply be written much more cleanly. I've
recently changed FontFileReader which had a very strange way of loading
a file using buffers. I've added a copyStream method which could easily
replaced by code from Commons IO, for example. Well, ok, I've introduced
a bug when I did that, but after fixing the bug the code is now a lot
clearer. Also, gradually introducing more of Avalon in the redesign will
lead to additional jars that we will need.

So, what I want to have opinions for is the following:

How could we handle the usage of additional libraries such as Jakarta Commons
packages or stuff from Avalon Excalibur?

Right now, we have avalon-framework.jar in our lib directory. I still
remember the somewhat negative feedback from users when we introduced
that one (!) new jar file as a dependency. Ok, we've also had LogKit,
but we were able to make that one optional.

Excalibur is a collection of small packages which all provide little
jars, one or more jar per package/sub-sub-subproject. Of course, there's
also a big one, but that would mean that you'd obviously have to use a
big jar from which you may well be using less than 20%. Same for Jakarta
Commons.

So what comes to my mind is two things:

1. Provide a big fop-complete.jar which contains among the fop classes all
the utility packages with an Apache home (Commons, Avalon stuff). That's
for easy use and involves repackaging of the utility jars during build.

2. Provide the same fop.jar as before but we'll have some more jars in
out lib directory over time. This obviously means that the classpath
will get some longer.

IMO both has to be done, especially to service those who don't like a
lot of jars in their classpath.

I'm looking forward to your comments and ideas.

Jeremias Maerki


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

RE: Getting breaks: revisited

[Keiron Liddle]

On Thu, 2002-11-21 at 16:03, Rhett Aultman wrote:
> When you say "in the design," do you mean that this is expected behavior as it is 
>now or as it should be at some point in the future?

That's the point of the original message, currently it doesn't do it
quite right. I am looking to adjust it to do this when there is a good
concept of how so that it will do the right thing sometime in the
future.




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

RE: Getting breaks: revisited

[Rhett Aultman]

Responses below.

-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 9:11 AM
To: FOP
Subject: RE: Getting breaks: revisited


On Thu, 2002-11-21 at 14:20, Rhett Aultman wrote:

>No, in the design the best break cannot be before the block, there is no
break before everything on the page.<

When you say "in the design," do you mean that this is expected behavior as it is now 
or as it should be at some point in the future?

>>It doesn't matter how many constraints there are, there will always be a
best break on the page that will place some contents on the page. The
next page will therefore have less to layout and will also place some
contents on its page, therefore an infinite loop is impossible.
<<

I hear what you're saying, and this should ideally seem correct, but if this is the 
way that things are now, I think that what is happening and what is ideally happening 
are out of touch with one another.

>>
Now to extend that to a more general situation. It will need to find
every break in the page sequence and compare the constraints that are
broken. Then attempt to adjust those breaks so fewer constraints are
broken.
<<

I believe this is not far from what was being suggested ala the concept of a "layout 
plan".  This is also not far from what I was describing earlier when I talked about 
first gathering up all of the information about various constraints and page breaks 
and then applying decisions about what is to be done.  The name of the game is 
spotting the issues before they're run into.

>>
Why do you think that it cannot be extended to handle this.
<<

I think that a system that has full knowledge of proposed breaks and constraints and 
can make and enforce decisions about when and how to pick and choose should he able 
to.  It hasn't seemed like you've been interested in following that route.

>>
The question to me is how to organise this in a good way that does not
mean using lots of memory and processing at many levels while still
being able to handle the tricky parts.
<<

Yes, but I don't think we should dwell on that for too long.  Getting something that 
handles the tricky parts is more important in my mind than worrying about 
optimization.  In my experience, optimization solutions become obvious once the 
implementation is found to work.



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


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

Re: fo validation issue

[Peter B. West]

Oleg Tkachenko wrote:

Peter B. West wrote:


I like pull parsing model in general, but how do you manage with not 
such strict content model as fo:root have, e.g. fo:block with 
(#PCDATA|%inline;|%block;)* ?




How about:




FoXMLEvent ev = expectStartElement
(FObjectSets.normalPcdataBlockInlineSet,
   XMLEvent.RETAIN_W_SPACE);



Looks not bad, but what about future extensions? Does it mean we will 
have to change this code every time new extension element or property is 
defined?


Oleg,

That depends.  If it is just a matter of extra elements, they can go 
into FObjectSets.normalPcdataBlockInlineSet, or one of the sets that 
comprise it.  In some cases, new sets and new access functions will have 
to be defined, but they will be modelled on existing ones.

Extension elements, as such, have an unpredictable semantic component 
anyway.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


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

Re: Alt-Design status: XML handling

[Peter B. West]

Oleg,

...

Oleg Tkachenko wrote:

Peter B. West wrote:


taking a very isolated path.  My motivation can be summed up in the 
slogan SAX SUX.  I couldn't understand why anyone would persist with 
it for any complex tasks, e.g. FOP.

Actually I cannot say I fully agree with this, because I don't see 
nothing complex in SAX processing model. And being xslt fan I'm 
obviously push-model fan.

...

significant difference makes XmlReader much easier to use for most 
Microsoft developers that are used to working with firehose 
(forward-only/read-only) cursors in ADO.


Well, lets consider pull model pros and contras:
+ easy to use by developer
+ benefits by kind of structural validation
+ more?


Why is it easier for developers to use?  Is it because the API is less 
complex or more easily understood?  Not really.  As you point out, the 
SAX API is not all that complex.  The problem is that the processing 
model of SUX is completely inverted.  You may have come to like writing 
XSLT that way.  You may be working with very general grammars, and have 
no other choice.  That doesn't make the inverted, inside-out model any 
more natural for the expression of processes and algorithms.  "Easier 
for developers to use" means an easier vocabulary for the expression and 
solution of programming models and problems; it means easier to 
document, easier to read and understand, easier to maintain and extend 
(in the sense of adding functionality).


- it glues processing to a particular xml structure, what is not so bad 
for vocabularies with well-defined and stable content model. The 
question is whether xsl-fo is a such kind of a vocabulary? I think it 
doesn't. As a matter of fact xsl-fo even inexpressible in dtd or schema, 
besides of possibility of extensions.

I think that a W3C Recommendation qualifies as a well-defined and stable 
vocabulary.  Hmm.  Well, you know what I mean.  It changes only 
infrequently, the changes are well-defined, and are going to involve 
changes, possibly major, to many parts of the code base anyway.  It 
certainly cannot be described as a dynamic vocabulary.


- is there performance penalty? I used to think that easy to use stuff 
always costs something.

Of course, as I have mentioned recently.  And as I also said, the cost 
of parsing relative to the intensive downstream element processing of 
FOP is small.  Obviously, you would look at optimising that as much as 
possible.

- more?


Note also that the structure of the code does its own validation.  It 
generates the simple-page-master subtree according to the content model

(region-body,region-before?,region-after?,region-start?,region-end?)

That's good, but it's not full-fledged validation unfortunately. To many 
"own validation" is bad I believe. If we need validation it must be done 
by specialized validation module and validation should not be scattered 
throughout the whole code.

Much of the validation of FOP has to be self-validation anyway, because 
so many of the constraints are context-dependent.  The whole question is 
context-dependent.  If you are engaged in the peephole processing of SUX 
you may be obliged to use external validation.  With top-down processing 
you have more choice, because your context is travelling with you.

Don't get me wrong here.  I'm not saying that external validation is 
wrong, merely that with a pull model, the need is reduced.  There may 
still be a strong case for it, but not as strong as with SUX.

And final question - what's wrong with SAX besides of possible complexity?


Isn't that enough?

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


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

RE: Getting breaks: revisited

[Keiron Liddle]

On Thu, 2002-11-21 at 14:20, Rhett Aultman wrote:
> IIRC, in my "8778 experiment", the break being offered was never null.  The best 
>break is always being offered, but the best break is at the beginning of the 
>offending block.  Either way, this resolves only the most trivial of the examples 
>without paying attention to the greater issue, which is that such layout issues are 
>rooted in constraints that conflict.  Is your intention to wait for such cases to 
>come in and just write special-case code for each and every one of them at the time?

No, in the design the best break cannot be before the block, there is no
break before everything on the page.

It doesn't matter how many constraints there are, there will always be a
best break on the page that will place some contents on the page. The
next page will therefore have less to layout and will also place some
contents on its page, therefore an infinite loop is impossible.

Now to find the best break. This could simply be done within the context
of the current page. Best break is:
- at least first available break
- of a lower keep constraint
- closer to the optimum page bpd

Now to extend that to a more general situation. It will need to find
every break in the page sequence and compare the constraints that are
broken. Then attempt to adjust those breaks so fewer constraints are
broken.

So how will this be done. The PageLayoutManager can collect all "best"
breaks as they are created. Then look at the constraints and available
moving room. I can't define any specifics because I would need to think
about it more. But I am certain there would be some sort of formula that
could aid in this process. Like: this page has optimum spacing and
breaks no constraints - therefore it can only be adjust between min and
max spacing. This page break is less than the min and the next page
breaks within an always keep so it should attempt to break the keep on
the first page and get closer to opt distance while having a normal
break on the next page.

Of course a force page break is definite so it could segment parts of
the flow, do the layout and add the pages.

Why do you think that it cannot be extended to handle this.

The question to me is how to organise this in a good way that does not
mean using lots of memory and processing at many levels while still
being able to handle the tricky parts.




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

Re: rendering SVG Graphic exported from staroffice 6

[Carsten Karkola]

The polygons come from staroffice 6.0 export to svg, so I have to live with 
them.
Are there some planes to build a new release, containing the right 
implementation in cvs?

Regards, Carsten


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

Re: Alt-Design status: XML handling

[Oleg Tkachenko]

Victor Mote wrote:


The issue with SAX as I see it, is that because it is one-way, and our
processing is not (I think the standard calls it "non-linear"), we
presumably have to essentially build our own DOM-ish (random access) things
in order to get the job done.

I think we should separate fo tree itself from the process of its building. fo 
tree structure is required and I agree with Keiron - it's not a DOM, it's just 
tree representation and I cherish the idea to make it an effectively small 
structure like saxon's internal tree. But any interim buffers should be 
avoided as much as it's possible (well, Piter's buffer seems not to be a burden).

To conclude, if I were designing this system from scratch, based on what I
know right now, I would:
1. Use DOM for both the fo tree & the area tree.

Bad idea, I believe. DOM is heaviweight versatile representation of xml 
document (recall entities, pi's etc nodes), while we need effective and 
lightweight structure to hold fo/area tree information. DOM has a lot of 
synchronization stuff, while our trees are almost read-only actually.
Ahh stop, probably you didn't mean w3c DOM?

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


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

Background information about using unicode characters

[m . schaeffler]

Hi,

I'm using fop 0.20.4 with jdk 1.4 and would like to get some background
information about how fop embedds unicode character from a true type font which
is not one of the 14 PDF Standard Fonts. I used "Arial Unicode Ms.ttf" to
embed some asien characters into an pdf document. Based on the information from
the fop homepage I assume that only the needed character, its encoding and the
glyph is embedded into the pdf file to enable the Acrobat Reader to render
the character correctly.  Is that correct, or are more information embedded
like the whole codepage in which the charater is in? Or which information are
exactly embedded into the pdf file? Can I rely on the assumption that the
pdf file with the embedded font will be displayed correctly independingly on
the
operating system and the available fonts on which ever computer the pdf file
is trying to be viewed?

Is it possible to create a PDF file with FOP which just describes a
character by its unicode representation and the corresponding glyph to display the
character is loaded from one of the available fonts from the computer where the
pdf file is viewed? That would be an interesting an valueable feature
instead of embedding the font file.

Thanks a lot for any information to clarify understanding!

Markus



-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!


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

Re: Help! About font problem.

[Oleg Tkachenko]

Yueshu Jesse wrote:

In order to resolve the display "..." problem, I embed a truetype 
font by setting up userconfig.xml and call new Option in program. So, 
the PDF file created by FOP can show the foreign words correctly. But at 
this time, there are some unbreak text block displaying out of the body 
region. Somebody help me please.
Without seeing an example I understand nothing from your explanation. Provide 
a small fo snippet, which illustrates your problem. And post it to fop-user 
list, please.

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


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

RE: Getting breaks: revisited

[Rhett Aultman]

Responses below.

-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 3:08 AM
To: FOP
Subject: RE: Getting breaks: revisited


Hi Rhett,

>>
On Wed, 2002-11-20 at 16:44, Rhett Aultman wrote:
> I may be green, but I did spot some of this a couple weeks ago, and it went mostly 
>unnoticed.  While writing this email, I downloaded another CVS snapshot and the 
>super-simple test document from bug #8778, which is probably the simplest of all the 
>i-loop cases, and ran it again...it's the same thing I saw when I last brought this 
>up.

Give me a chance, it is by no means finished and to suggest that if it
doesn't do it properly now it never will is going a bit far.
<<

I'm not suggesting that.  I am, however, attempting to explore potential solutions.  
I'm asking you what you intend to do about it, since you have insisted that the 
various ideas offered are either bad or unnecessary.

>>
Currently it does not handle the situation where it cannot find any
normal break in a page, so if the page is small it will get an infinite
loop.
I have never said it will handle anything you throw at it. I am talking
about design anyway.
The design will handle that situation.
<<

I'm talking about design, too.  This entire thread is about design.  I'm citing 
examples because they elucidate a general, design-related issue.  To be frank, saying 
"the design will handle this" is much like saying "the proof is left as an example for 
the reader."  I'm attempting to explore *how* such a design would from a general 
position.  This is a highly relevant topic.  Victor, Peter, and I have all offered 
ideas of ways to resolve such matters, and you too seem to have more musings on it.  
I'd enjoy hearing them.  Do you have a general solution for discarding constraints 
that get in the way of layout?

>>
Easy: there is currently no best break (ie. it is null) therefore we
still need to find a break. So the best break will be after the block.
It will place that on the page and finish document.
If there are keeps it should probably go further until it can be sure it
will find the best breaks for all things kept together.
<<

IIRC, in my "8778 experiment", the break being offered was never null.  The best break 
is always being offered, but the best break is at the beginning of the offending 
block.  Either way, this resolves only the most trivial of the examples without paying 
attention to the greater issue, which is that such layout issues are rooted in 
constraints that conflict.  Is your intention to wait for such cases to come in and 
just write special-case code for each and every one of them at the time?




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


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

Re: fo validation issue

[Oleg Tkachenko]

Peter B. West wrote:


I like pull parsing model in general, but how do you manage with not 
such strict content model as fo:root have, e.g. fo:block with 
(#PCDATA|%inline;|%block;)* ?


How about:




FoXMLEvent ev = expectStartElement
(FObjectSets.normalPcdataBlockInlineSet,
   XMLEvent.RETAIN_W_SPACE);


Looks not bad, but what about future extensions? Does it mean we will have to 
change this code every time new extension element or property is defined?

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


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

Re: Alt-Design status: XML handling

[Oleg Tkachenko]

Peter B. West wrote:


taking a very isolated path.  My motivation can be summed up in the 
slogan SAX SUX.  I couldn't understand why anyone would persist with it 
for any complex tasks, e.g. FOP.
Actually I cannot say I fully agree with this, because I don't see nothing 
complex in SAX processing model. And being xslt fan I'm obviously push-model fan.

...
significant difference makes XmlReader much easier to use for most 
Microsoft developers that are used to working with firehose 
(forward-only/read-only) cursors in ADO.

Well, lets consider pull model pros and contras:
+ easy to use by developer
+ benefits by kind of structural validation
+ more?

- it glues processing to a particular xml structure, what is not so bad for 
vocabularies with well-defined and stable content model. The question is 
whether xsl-fo is a such kind of a vocabulary? I think it doesn't. As a matter 
of fact xsl-fo even inexpressible in dtd or schema, besides of possibility of 
extensions.
- is there performance penalty? I used to think that easy to use stuff always 
costs something.
- more?

Note also that the structure of the code does its own validation.  It 
generates the simple-page-master subtree according to the content model

(region-body,region-before?,region-after?,region-start?,region-end?)
That's good, but it's not full-fledged validation unfortunately. To many "own 
validation" is bad I believe. If we need validation it must be done by 
specialized validation module and validation should not be scattered 
throughout the whole code.

And final question - what's wrong with SAX besides of possible complexity?

--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


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

DO NOT REPLY [Bug 7241] - keep-with-previous, keep-with-next only working on the first page break

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

keep-with-previous, keep-with-next only working on the first page break

[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|0.20.3  |0.20.4

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

DO NOT REPLY [Bug 7241] - keep-with-previous, keep-with-next only working on the first page break

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

keep-with-previous, keep-with-next only working on the first page break





--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 12:55 ---
Created an attachment (id=3909)
Testcase (Version 0.20.4)

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

RE: Alt-Design status: XML handling

[Keiron Liddle]

On Thu, 2002-11-21 at 12:43, Victor Mote wrote:
> To conclude, if I were designing this system from scratch, based on what I
> know right now, I would:
> 1. Use DOM for both the fo tree & the area tree.

I don't know whether I would call it a DOM but the area tree is an
independant data structure that contains all the information necessary
to render the document.


> 2. Write them to disk when necessary, hiding all of this from the layout
> managers.

This has already been done for the area tree. I use the
CachedRenderPagesModel all the time. If it cannot render the page
immediately then it saves it to disk. The layout managers only know
about adding areas to a page and then adding the page to the area tree.
For rendering it can dispose of the page once rendered, for awt viewer
it could save all pages to disk and load when necessary.

As described here (written a long time ago and needs updating):
http://xml.apache.org/fop/design/areas.html

I don't see why you would need all the fo tree available, each page
sequence is independant for the flow and often each page can be finished
before the next page.

> 3. Use an event-based layout mechanism so that the fo tree doesn't even have
> to be there to get layout work done.

Depends exactly what you mean but I think that is the general idea, care
to implement it.

> I am sure I can be talked out of this by someone smarter, but I wanted to
> lay out the whole line of reasoning. My apologies to Peter and anyone else
> who may have been working on these points before. I am just now getting
> around to them.
> 
> After further consideration, my use of "event-based" above may be too
> strong. Probably what I mean is more along the lines of API-based. In a
> WYSIWIG environment, the event would probably trigger an API action, but
> that action could be invoked another way as well. I am too tired to rewrite
> it -- I hope you know what I mean.
> 
> This final thought is really a question which was briefly addressed during
> our recent weekend clarification about the role of the maintenance branch,
> and which I wish to apply specifically to the above thoughts. Does or could
> the new design give us the ability to (with say, a configuration option)
> choose between Layout Philosophy A and B? By this I mean 2 (or more) layout
> packages coexisting in the same code base, and sharing common resources that
> can be selected (configurable perhaps). If so, then we can play with these
> ideas at our leisure, compare them in various ways, transition between them
> if necessary, and maybe even keep both to be used in various circumstances.
> I think someone (Jeremias perhaps) had indicated that something along these
> lines would be possible, but that may have been at a lower level than what I
> am discussing here.

This should be quite simple to do.
There would be a basic interface set for the layout managers when being
created by the fo tree. We could possible have a common one for inline
objects.
The actual layout implementation could then be changed.

Again, this will need to be implemented.


> I don't mean to rock the boat. I guess I am kind of like a three-year-old
> who asks "why" and "why not" all of the time to the annoyance of all around
> him -- I am still trying to learn the basics. Thanks for your patience.

I keep getting the feeling that everyone is saying the current design is
wrong and here is a better idea, which turns out to be the same as the
current design.

When will people start doing it?




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

RE: Alt-Design status: XML handling

[Victor Mote]

Peter B. West wrote:

> 
...
> Echoing sentiments recently expressed in this publication, Clark said
> that SAX, though efficient, was very hard to use, and that DOM had
> obvious limitations due to the requirement that the document being
> processed be in memory. He suggested that what was needed was a standard
> "pull API," one that efficiently allowed random access to XML documents.

First, thanks for the update on your work -- I understand what you are doing
a little better. Second, the statement above about random access almost
jumped out at me, because I had exactly the same thought earlier today while
contemplating a thread on the XSL-FO list which discussed processing of long
documents and memory constraints related to them. The closest thing to a
perfect document processing system that I have come across is FrameMaker,
which seems to be able to handle pretty large documents with a pretty small
footprint. I don't know for sure, but it seems to me that the "area tree"
(if you will) is written to disk, and pages can be efficiently jumped to in
an arbitrary manner. The WYSIWIG editor is essentially a viewport on the
portion of the document in memory, which is itself a subset of the disk
document. As you edit the document, I presume that events are sent to
something akin to a layout manager, which has to do something with them.
Now, in our case, we need to not only have random access to the area tree,
but also to the fo tree.

What follows is my feeble attempt to reconcile some of these issues.

The issue with SAX as I see it, is that because it is one-way, and our
processing is not (I think the standard calls it "non-linear"), we
presumably have to essentially build our own DOM-ish (random access) things
in order to get the job done. I wonder if we don't end up reinventing the
wheel in frustration with that approach. From a cleanliness of design
standpoint at least, it seems much more straightforward to instead use a
DOM-based approach and write chunks of the two DOMs to disk where necessary.
I haven't thought through whether java.io.RandomAccessFile or a regular
database or some other alternative would be the way to go. The LMs can be
totally protected from all of this by abstracting both the FO and Area
Documents -- in other words, they work with abstract nodes on trees and
don't care what was required to make them available.

Oddly enough, once I have the stability of the DOMs to work from (perhaps
this is more felt than real), an event-based approach seems much more
natural -- like imitating a word processor. In fact, if done properly,
another project could conceivably use FOP as the layout engine for a WYSIWIG
editor. Actually I have been trying to quantify & grasp two processing
models that come to mind: 1) the word-processing model, an event-based
model, and 2) an 18th-century typesetter manually laying out pages, which is
much more of a look-ahead, measure-it-to-see-how-it-fits-before-placing-it
model.

These two models roughly correspond to the two processing models I mentioned
the other day ("I am text, place me somewhere" vs. "I am a page with room,
place something on me"). The second model requires the 2-pass approach. The
first fits either a push or a pull approach (since we can manufacture events
if we need to), the second is definitely pull. When I wrote about those two
models, I was frankly leaning heavily toward the 2nd approach, but I think I
am changing my mind. To explain why, I need to have you forget for a moment
about our SAX-based input (I'll come back to that). Forget also about
performance for a moment, and picture the typesetter setting type one
character at a time, with no thought of what the next character or image
is -- in other words, setting type just like a user sitting at Microsoft
Word does. If the typesetter comes to a concept that messes his previous
work up, he has to yank a line of type out, or perhaps an entire page out,
and replace them. However, (and this is the key point), he eventually will
get the job done. In other words, when abstracted this way, the only benefit
to a look-ahead /should be/ performance. Consider our auto table layout
problem. If on the 350th page of the table, I find an item that requires me
to change the width of the columns, which in turns changes the layout of all
350 pages, yes, I am going to burn up a few cycles to accomplish that, but I
/should/ be able to get it done.

So far all I have done is loosely reconciled these two processing models.
The next thing I want to do is to try to compare these two models with FOP's
layout  process. If I like the event-based model, then maybe I ought to like
FOP's approach. Let me go first to my 18th-century typesetter. Each time he
has to tear out a line or page of type, he can go back to his manuscript
(his FO document, if you will) to rebuild them. Similarly in a word
processor, I presume that Microsoft Word must have some concept that the 2
lines at the top of page 84 are in the same paragraph

cvs commit: xml-fop/src/org/apache/fop/fo/flow FoFootnoteBody.java

[pbwest]

pbwest  2002/11/21 02:55:48

  Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoFootnoteBody.java
  Log:
  Adjust for RCS errors.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoFootnoteBody.java
  
  Index: FoFootnoteBody.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoFootnoteBody.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/flow FoFloat.java

[pbwest]

pbwest  2002/11/21 02:53:08

  Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoFloat.java
  Log:
  Adjust for RSC errors.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoFloat.java
  
  Index: FoFloat.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoFloat.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/flow FoBlock.java

[pbwest]

pbwest  2002/11/21 02:49:11

  Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoBlock.java
  Log:
  Adjust for RCS errors.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.8   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoBlock.java
  
  Index: FoBlock.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoBlock.java,v
  retrieving revision 1.1.2.7
  retrieving revision 1.1.2.8
  diff -u -r1.1.2.7 -r1.1.2.8
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/flow FoBlockContainer.java

[pbwest]

pbwest  2002/11/21 02:45:08

  Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoBlockContainer.java
  Log:
  Adjust for RCS errors.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.8   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoBlockContainer.java
  
  Index: FoBlockContainer.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoBlockContainer.java,v
  retrieving revision 1.1.2.7
  retrieving revision 1.1.2.8
  diff -u -r1.1.2.7 -r1.1.2.8
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/flow FoBidiOverride.java

[pbwest]

pbwest  2002/11/21 02:34:37

  Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoBidiOverride.java
  Log:
  Adjusting for RCS errors.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.8   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoBidiOverride.java
  
  Index: FoBidiOverride.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoBidiOverride.java,v
  retrieving revision 1.1.2.7
  retrieving revision 1.1.2.8
  diff -u -r1.1.2.7 -r1.1.2.8
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/flow FoBasicLink.java

[pbwest]

pbwest  2002/11/21 02:29:59

  Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoBasicLink.java
  Log:
  Adjusting for rcs errors.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.8   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoBasicLink.java
  
  Index: FoBasicLink.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoBasicLink.java,v
  retrieving revision 1.1.2.7
  retrieving revision 1.1.2.8
  diff -u -r1.1.2.7 -r1.1.2.8
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/flow FoBasicLink.java

[pbwest]

pbwest  2002/11/21 02:01:47

  Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoBasicLink.java
  Log:
  Subtree processing.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.7   +2 -2  xml-fop/src/org/apache/fop/fo/flow/Attic/FoBasicLink.java
  
  Index: FoBasicLink.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoBasicLink.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  
  
  

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

Help! About font problem.

[Yueshu Jesse]

In order to resolve the display "..." problem, I embed a truetype font 
by setting up userconfig.xml and call new Option in program. So, the PDF 
file created by FOP can show the foreign words correctly. But at this time, 
there are some unbreak text block displaying out of the body region. 
Somebody help me please.

Regards
Jesse.

_
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus


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

Re: Alt-Design status: XML handling

[Nicola Ken Barozzi]

Peter B. West wrote:
[...]


STATUS:

The XML pull buffering has been working for some considerable time.  I 
have simply been extending the get/expect methods on top of the simpler 
methods as I have found a requirement for them in building the FO tree.

In cases where the DTD is well known and well structured, XML pull is 
much easier to use than SAX.

For example, one can write a XSL styleshees with templates or with many 
. SAX is similar to tomplates, XML pull is similar to .

Having worked so much with SAX stuff, I can say that in many cases SAX 
is effectively a PITA, as DOM is for some, and as XML pull is too for some.

If the code proves to be easier to understand and write, it will be 
easier to fix and maintain, so this option should IMHO taken in strong 
consideration.

My 2c

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


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

DO NOT REPLY [Bug 7400] - Formatting fo:page-number-citation

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

Formatting fo:page-number-citation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-21 08:39 ---
Fixed in cvs, now it displays 01.

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

cvs commit: xml-fop/src/org/apache/fop/fo/properties BorderStyle.java

[pbwest]

pbwest  2002/11/21 00:23:13

  Modified:src/org/apache/fop/fo/properties Tag: FOP_0-20-0_Alt-Design
BorderStyle.java
  Log:
  Extend BorderCommonStyle.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.4   +2 -2  xml-fop/src/org/apache/fop/fo/properties/Attic/BorderStyle.java
  
  Index: BorderStyle.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/properties/Attic/BorderStyle.java,v
  retrieving revision 1.1.2.3
  retrieving revision 1.1.2.4
  diff -u -r1.1.2.3 -r1.1.2.4
  --- BorderStyle.java  31 Oct 2002 01:52:08 -  1.1.2.3
  +++ BorderStyle.java  21 Nov 2002 08:23:13 -  1.1.2.4
  @@ -9,12 +9,12 @@
   import org.apache.fop.fo.PropNames;
   import org.apache.fop.fo.ShorthandPropSets;
   import org.apache.fop.fo.FONode;
  -import org.apache.fop.fo.properties.Property;
  +import org.apache.fop.fo.properties.BorderCommonStyle;
   
   import java.util.Map;
   import java.util.Iterator;
   
  -public class BorderStyle extends Property  {
  +public class BorderStyle extends BorderCommonStyle  {
   public static final int dataTypes = SHORTHAND;
   public static final int traitMapping = SHORTHAND_MAP;
   public static final int initialValueType = NOTYPE_IT;
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/properties Property.java

[pbwest]

pbwest  2002/11/21 00:22:16

  Modified:src/org/apache/fop/fo/properties Tag: FOP_0-20-0_Alt-Design
Property.java
  Log:
  Added INTEGER and ENUM to refineParsing().
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.6   +12 -3 xml-fop/src/org/apache/fop/fo/properties/Attic/Property.java
  
  Index: Property.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/properties/Attic/Property.java,v
  retrieving revision 1.1.2.5
  retrieving revision 1.1.2.6
  diff -u -r1.1.2.5 -r1.1.2.6
  --- Property.java 13 Nov 2002 03:48:32 -  1.1.2.5
  +++ Property.java 21 Nov 2002 08:22:16 -  1.1.2.6
  @@ -376,6 +376,11 @@
   return value;
   throw new PropertyException
   ("Numeric value invalid  for " + propName);
  +case PropertyValue.INTEGER:
  +if ((dataTypes & NUMBER) != 0)
  +return value;
  +throw new PropertyException
  +("IntegerType value invalid for " + propName);
   case PropertyValue.NCNAME:
   String ncname = ((NCName)value).getNCName();
   // Can by any of
  @@ -396,6 +401,10 @@
   (foNode, property, ncname)).getMappedNumValue();
   throw new PropertyException
   ("NCName value invalid  for " + propName);
  +case PropertyValue.ENUM:
  +if ((dataTypes & ENUM) != 0) return value;
  +throw new PropertyException
  +( "Enumerated value invalid for " + propName);
   case PropertyValue.LITERAL:
   // Can be LITERAL or CHARACTER_T
   if ((dataTypes & (LITERAL | CHARACTER_T)) != 0) return value;
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/pagination PageSequenceMaster.java

[pbwest]

pbwest  2002/11/21 00:14:42

  Modified:src/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design
PageSequenceMaster.java
  Log:
  Add constructor to generate PageSequenceMaster from FoSimplePageMaster.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.4.2.5   +46 -26xml-fop/src/org/apache/fop/fo/pagination/PageSequenceMaster.java
  
  Index: PageSequenceMaster.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/org/apache/fop/fo/pagination/PageSequenceMaster.java,v
  retrieving revision 1.4.2.4
  retrieving revision 1.4.2.5
  diff -u -r1.4.2.4 -r1.4.2.5
  --- PageSequenceMaster.java   30 Oct 2002 12:58:59 -  1.4.2.4
  +++ PageSequenceMaster.java   21 Nov 2002 08:14:42 -  1.4.2.5
  @@ -38,8 +38,13 @@
   .FoRepeatablePageMasterAlternatives.FoConditionalPageMasterReference;
   
   /**
  - * Encodes an fo:page-sequence-master and associated
  - * conditions.
  + * Encodes an fo:page-sequence-master and associated
  + * conditions.  All page-sequence-master specifications are converted
  + * into repeatable-page-master-alternatives.
  + * For a simple-page-master, a PageSequenceMaster object is
  + * created which shares a name with its target simple-page-master.
  + * This procedure results in a single common structure and manner of access
  + * for all page masters.
*/
   public class PageSequenceMaster {
   
  @@ -55,15 +60,36 @@
   private ArrayList masters = new ArrayList(1);
   
   /**
  - * @param masterName - the name of this master.
  + * Create a PageSequenceMaster from an
  + * FoSimplePageMaster.
  + * @param simplePM - the FoSimplePageMaster from which this
  + * PageSequenceMaster is derived.
  + */
  +public PageSequenceMaster(FoSimplePageMaster simplePM)
  +throws PropertyException, FOPException
  +{
  +PageMasterAlternatives masterAlt;
  +masterName = simplePM.getMasterName();
  +masterAlt = new PageMasterAlternatives(1, NO_LIMIT);
  +// Create and add a single default PageCondition
  +masterAlt.addCondition
  +(masterAlt.new PageCondition(simplePM,
  +   BlankOrNotBlank.ANY,
  +   OddOrEven.ANY,
  +   PagePosition.ANY));
  +masters.add(masterAlt);
  +}
  +
  +/**
  + * Create a PageSequenceMaster from an
  + * FoPageSequenceMaster.
* @param pageSeq - the FoPageSequenceMaster from which this
* PageSequenceMaster is derived.
* @param simplePageMasters - a HashMap of
* FoSimplePageMasters indexed by master-name.
*/
   public PageSequenceMaster
  -(String masterName, FoPageSequenceMaster pageSeq,
  -HashMap simplePageMasters)
  +(FoPageSequenceMaster pageSeq, HashMap simplePageMasters)
   throws PropertyException, FOPException
   {
   String masterRef;
  @@ -73,23 +99,7 @@
   int enumValue;
   PropertyValue pv;
   Numeric npv;
  -this.masterName = masterName;
  -// Convert the simple-page-masters into page-sequence-masters
  -Iterator names = simplePageMasters.keySet().iterator();
  -while (names.hasNext()) {
  -String master = (String)(names.next());
  -simplePM =
  -(FoSimplePageMaster)(simplePageMasters.get(master));
  -// Create a PageMasterAlternatives
  -masterAlt = new PageMasterAlternatives(1, NO_LIMIT);
  -// Create and add a single default PageCondition
  -masterAlt.addCondition
  -(masterAlt.new PageCondition(simplePM,
  -   BlankOrNotBlank.ANY,
  -   OddOrEven.ANY,
  -   PagePosition.ANY));
  -masters.add(masterAlt);
  -}
  +masterName = pageSeq.getMasterName();
   // Process the sequence of masters.
   int numChildren = pageSeq.numChildren();
   for (int child = 0; child < numChildren; child++) {
  @@ -213,6 +223,16 @@
+ masterReference.type);
   }
   }
  +}
  +
  +/**
  + * Get the master-name of this PageSequenceMaster.  This is the
  + * name by which fo:page-sequences will reference the master
  + * through their master-reference property.
  + * @return the name.
  + */
  +public String getMasterName() {
  +return masterName;
   }
   
   /**
  
  
  

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

cvs commit: xml-fop/src/org/apache/fop/fo/pagination FoLayoutMasterSet.java

[pbwest]

pbwest  2002/11/21 00:11:50

  Modified:src/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design
FoLayoutMasterSet.java
  Log:
  Add processing of simplepage-masters into PageSequenceMasters.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.16  +22 -13
xml-fop/src/org/apache/fop/fo/pagination/Attic/FoLayoutMasterSet.java
  
  Index: FoLayoutMasterSet.java
  ===
  RCS file: 
/home/cvs/xml-fop/src/org/apache/fop/fo/pagination/Attic/FoLayoutMasterSet.java,v
  retrieving revision 1.1.2.15
  retrieving revision 1.1.2.16
  diff -u -r1.1.2.15 -r1.1.2.16
  --- FoLayoutMasterSet.java13 Nov 2002 04:15:19 -  1.1.2.15
  +++ FoLayoutMasterSet.java21 Nov 2002 08:11:50 -  1.1.2.16
  @@ -1,6 +1,6 @@
   package org.apache.fop.fo.pagination;
   
  -import java.util.Set;
  +import java.util.Collection;
   import java.util.HashMap;
   import java.util.LinkedList;
   import java.util.Iterator;
  @@ -150,6 +150,7 @@
   ("simple-page-master master-name clash in "
+ "simplePageMasters: " + masterName);
   simplePageMasters.put(masterName, simple);
  +System.out.println("simple-page-master ok");
   } else if (foType == FObjectNames.PAGE_SEQUENCE_MASTER) {
   //System.out.println("Found page-sequence-master");
   try {
  @@ -169,6 +170,7 @@
   ("page-sequence-master master-name clash in "
+ "simplePageMasters: " + masterName);
   pageMasters.put(masterName, foPageSeq);
  +System.out.println("page-sequence-master ok");
   } else
   throw new FOPException
   ("Aargh! expectStartElement(events, list)");
  @@ -185,25 +187,32 @@
   catch (TreeException e) {
   throw new FOPException(e);
   }
  -if (pageMasters.size() == 0)
  +if (pageMasters.size() == 0 && simplePageMasters.size() == 0)
   throw new FOPException
   ("No page masters defined in layout-master-set.");
   // Create the master set structures.
  -// Scan the page-sequence-masters
   // N.B. Processing of the page-sequence-masters must be deferred until
   // now because contained master-references may be to
   // simple-page-masters which follow the page-sequence-master in the
   // input tree.
  -Set pageSeqSet = pageMasters.keySet();
  -Iterator pageSeqNames = pageSeqSet.iterator();
  -while (pageSeqNames.hasNext()) {
  -masterName = (String)(pageSeqNames.next());
  +// Scan the simple-page-masters
  +Collection set = simplePageMasters.values();
  +Iterator values = set.iterator();
  +while (values.hasNext()) {
  +// Create a new PageSequenceMaster object - NOT an foPageSeqM
  +PageSequenceMaster pageSeq = new PageSequenceMaster
  +((FoSimplePageMaster)(values.next()));
  +pageSequenceMasters.put(pageSeq.getMasterName(), pageSeq);
  +}
  +// Scan the page-sequence-masters
  +set = pageMasters.values();
  +values = set.iterator();
  +while (values.hasNext()) {
   // Get the FoPageSequenceMaster
  -foPageSeq = (FoPageSequenceMaster)(pageMasters.get(masterName));
   // Create a new PageSequenceMaster object - NOT an foPageSeqM
   PageSequenceMaster pageSeq = new PageSequenceMaster
  -(masterName, foPageSeq, simplePageMasters);
  -pageSequenceMasters.put(masterName, pageSeq);
  +((FoPageSequenceMaster)(values.next()), simplePageMasters);
  +pageSequenceMasters.put(pageSeq.getMasterName(), pageSeq);
   }
   }
   
  
  
  

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

RE: Getting breaks: revisited

[Keiron Liddle]

Hi Rhett,


On Wed, 2002-11-20 at 16:44, Rhett Aultman wrote:
> I may be green, but I did spot some of this a couple weeks ago, and it went mostly 
>unnoticed.  While writing this email, I downloaded another CVS snapshot and the 
>super-simple test document from bug #8778, which is probably the simplest of all the 
>i-loop cases, and ran it again...it's the same thing I saw when I last brought this 
>up.

Give me a chance, it is by no means finished and to suggest that if it
doesn't do it properly now it never will is going a bit far.

Currently it does not handle the situation where it cannot find any
normal break in a page, so if the page is small it will get an infinite
loop.
I have never said it will handle anything you throw at it. I am talking
about design anyway.
The design will handle that situation.

Easy: there is currently no best break (ie. it is null) therefore we
still need to find a break. So the best break will be after the block.
It will place that on the page and finish document.
If there are keeps it should probably go further until it can be sure it
will find the best breaks for all things kept together.





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