Arved Sandstrom wrote:
I actually helped push for this last year - the notion of separate layout
managers. I was strongly influenced by the mess that FOP code had become at
the time, and really thought that layout should be taken out of the FOs
themselves; that the FO's, in a sense, were (or shou
On Mon, 2002-12-09 at 01:00, Arved Sandstrom wrote:
> I actually helped push for this last year - the notion of separate layout
> managers. I was strongly influenced by the mess that FOP code had become at
> the time, and really thought that layout should be taken out of the FOs
> themselves; that
Hi Joerg,
These are the issues that you have mentioned before.
It is still essentially only attacking two methods (and supporting
classes).
If you have a better design, then do it.
On Sun, 2002-12-08 at 00:16, J.Pietschmann wrote:
> deep inheritance hierarchies. There is only so much someone can
keiron 2002/12/09 00:45:16
Modified:src/documentation/content/xdocs news.xml status.xml
src/documentation/content/xdocs/design/alt.design book.xml
classes-overview.xml
Added: src/documentation/content/xdocs/design/alt.design
Hi Oleg,
I think writing direction would be a good addition.
I am hoping to bring back all the renderers and this is one issue that
need to be considered. ie. how it is handled in the area tree and how
renderers deal with it, sorting out width/height vs. ipd/bpd
On Sun, 2002-12-08 at 18:30, Oleg
On Fri, 2002-12-06 at 15:43, Rhett Aultman wrote:
> We have a Wiki that seems to have been a good way of quickly throwing up ideas for
>style guidelines and voting on them. Why don't we do the same thing here? We could
>throw up our ideas, try to sort them into "lofty, long term" stuff and "imm
keiron 2002/12/09 02:52:27
Modified:docs/xml-docs/data logo.svg track.svg
Log:
updated
Revision ChangesPath
1.3 +11 -11xml-fop/docs/xml-docs/data/logo.svg
Index: logo.svg
===
RCS file: /ho
keiron 2002/12/09 03:18:58
Modified:src/org/apache/fop/render/pdf PDFXMLHandler.java
Log:
use more decimal places for scaling
Revision ChangesPath
1.12 +5 -5 xml-fop/src/org/apache/fop/render/pdf/PDFXMLHandler.java
Index: PDFXMLHandler.java
=
keiron 2002/12/09 03:22:35
Modified:src/org/apache/fop/apps LayoutHandler.java
Log:
added some comments and changed debugging a bit
Revision ChangesPath
1.8 +63 -20xml-fop/src/org/apache/fop/apps/LayoutHandler.java
Index: LayoutHandler.java
=
J.Pietschmann wrote:
Victor Mote wrote:
Just to be clear, I should point out that there is not a layout that is
impossible to perform.
There are layouts for which it is very hard to decide what
to do. Consider the following:
http://www.w3.org/1999/XSL/Format";>
Keiron Liddle wrote:
I still believe that it is useful to have the layout managers separate
from the fo tree. There are a number of reasons that come to mind. It is
possible to independantly change layout managers. Certain fo's aren't
directly in the same hierarchy: markers, undefined table colu
Hi all,
I've (finally) updated the build process to the new Forrest docs
and I'm ready now for doing the Release Candidate.
If this is ok for everybody I'll do it later today.
Christian
-
To unsubscribe, e-mail: [EMAIL PROTECT
IvanLatysh wrote:
Hi.
I am experience problem when I am trying to get output from the FOP as png.
Images are not shown in the result png.
Could someone help me with it.
First of all you need to tell us which FOP version you are using.
If it's 0.20.4 you need to download Jimi from SUN at:
http
Oleg Tkachenko wrote:
Christian Geisert wrote:
I just noticed bsf.jar in the lib directory and IIRC it was needed by
xalan1. As we switched to xalan2 some time ago is it ok for everyone
if I remove bsf.jar?
btw, isn't bsf.jar used by xalan2 to process extensions?
Yes it's needed for extensi
vmote 2002/12/09 09:26:10
Modified:src/documentation/content/xdocs compliance.xml
Log:
fixes from review of W3C standard, Implemented doc, and Limitations doc
Revision ChangesPath
1.5 +29 -9 xml-fop/src/documentation/content/xdocs/compliance.xml
Index: co
vmote 2002/12/09 10:23:13
Modified:src/documentation/content/xdocs faq.xml
Log:
Add FAQ for FO validation, and refer other FAQs to it.
Revision ChangesPath
1.4 +9 -2 xml-fop/src/documentation/content/xdocs/faq.xml
Index: faq.xml
===
vmote 2002/12/09 11:37:44
Modified:src/documentation/content/xdocs faq.xml
Log:
Expanded FAQs related to PDF post-processing.
Revision ChangesPath
1.5 +25 -14xml-fop/src/documentation/content/xdocs/faq.xml
Index: faq.xml
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]]
> Sent: December 9, 2002 8:56 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Redesign issues
>
>
> Keiron Liddle wrote:
> >
> >
> > I still believe that it is useful to have the layout managers separate
> > from the fo tree. T
Peter B. West wrote:
...the intention of the spec would
be realised by laying out 0 of the repeatable-p-m-refs "thin", out of
the available range of 0-100, then laying out 1 of the "thick" r-p-m-refs.
Interesting and useful interpretation. The problem is, how to
implement this?
J.Pietschmann
Keiron Liddle wrote:
These are the issues that you have mentioned before.
It is still essentially only attacking two methods (and supporting
classes).
Unfortunately, these are the core methods, essential for understanding
the whole approach.
If you have a better design, then do it.
I put a det
Response below.
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 09, 2002 3:00 PM
To: [EMAIL PROTECTED]
Subject: Re: Redesign issues
>>
Keiron Liddle wrote:
> These are the issues that you have mentioned before.
> It is still essentially only attack
Howdy,
FYI, I had a problem running FOP on my Mac OS X system. Here's the error I got:
[webmaestro-mac:Users/Shared/fop-0.20.4] clay% ./fop.sh -d -xml
"/Users/clay/Desktop/HuiBro/test_MIWC.xml" -xsl
"/Users/clay/Desktop/HuiBro/xml_med7_MIWC.fo" -awt
Exception in thread "main" java.lang.NoClassDe
Clay Leeds wrote:
> The files were ZIP'd, and when they were unZIP'd using Stuffit Expander,
> the avalon JAR file's long filename was changed from:
>
>avalon-framework-cvs-20020315.jar
>
> to:
>
>avalon-framework-cvs-20020315.j
>
> Adding "ar" at the end of that filename, resolved the pro
It is possible the latest StuffIt Expanders work properly for filenames longer than 31
chars but it is a known problem. OS X can use much longer filenames. I include the
following when I put up archives:
MacOSX Note: Don't use Stuffit to expand the archive. Use the following shell command
ins
On Monday, December 9, 2002, at 11:54 PM, Victor Mote wrote:
Clay Leeds wrote:
The files were ZIP'd, and when they were unZIP'd using Stuffit
Expander,
the avalon JAR file's long filename was changed from:
avalon-framework-cvs-20020315.jar
to:
avalon-framework-cvs-20020315.j
Adding "
Stephen & Victor,
At 02:54 PM 12/9/2002, you wrote:
Clay Leeds wrote:
> The files were ZIP'd, and when they were unZIP'd using Stuffit Expander,
> the avalon JAR file's long filename was changed from:
>
>avalon-framework-cvs-20020315.jar
>
> to:
>
>avalon-framework-cvs-20020315.j
>
> Add
pbwest 2002/12/09 15:41:00
Removed: docs/design/alt.design AbsolutePosition.dia PropNames.dia
PropertyConsts.dia Properties.dia VerticalAlign.dia
Log:
No longer required.
-
To unsubscribe, e
Peter B. West wrote:
Keiron Liddle wrote:
On Fri, 2002-12-06 at 03:47, Peter B. West wrote:
If anyone else want to have a look I would be interested in the
results. I am particularly interested in memory usage, which, prima
facie, looks good. 9 megs total memory usage for 51 pages of FO tr
Keiron and Nicola Ken (and anyone else who is interested):
I have the process of building the fop web site mostly scripted at
/home/vmote/script/build-fop-website.bsh. I have a couple of
problems/questions, which I will interject into the src/documentation/README
doc contents below:
> The current
Clay Leeds wrote:
> This is fine, but I think it would be better to state something like:
>
> MacOSX Note: Use the following shell command to extract FOP under
> Mac OS X:
>
>tar -xzf .tar.gz
>
> If you use Stuffit to expand the archive, the following filename:
>
>fop-0.20.4\lib\avalon-fra
30 matches
Mail list logo
