Victor Mote wrote:
J.Pietschmann wrote:
Could you outline your API ideas on the Wiki?
Sure (give me a couple of days). Again, my point is not to push for a
particular API or framework, but only to show that the control
concepts (PDF
encryption was the example given IIRC) can be added to
Bertrand Delacretaz wrote
The whole point of the StructureHandler interface is to be able to
reuse FOP's frontend for structure-based renderers.
The impact of StructureHandler on the standard FOP output formats
(PDF mostly) is minor, but it allows the FOP pipeline to branch
cleanly, after
Le Lundi, 23 juin 2003, à 10:35 Europe/Zurich, J.U. Anderegg a écrit :
...
How do you plan to handle RTF styles?
In jfor we defined an extension to XSL-FO (the jfor-style attribute)
to control RTF styles.
Another way would be to recognize sets of attribute values in the input
XSL-FO and map
Bertrand Delacretaz wrote:
...
How do you plan to handle RTF styles?
In jfor we defined an extension to XSL-FO (the jfor-style attribute)
to control RTF styles.
I think some form of extension is needed as (AFAIK) the concept of
styles does not exist in XSL-FO, as it is meant for printed
Le Lundi, 23 juin 2003, à 12:08 Europe/Zurich, J.U. Anderegg a écrit :
Bertrand Delacretaz wrote:
...In jfor we defined an extension to XSL-FO (the jfor-style
attribute)
to control RTF styles
(1) This is not a FOP extension, but rather a fundamental change of the
XSL-FO language, which does
Nice idea, but there's a problem. The xsl namespace gets filtered out by
the XSLT engine, or IOW expanded to the FO attributes before they reach
FOP. FOP never sees anything with the xsl: prefix.
On 23.06.2003 18:51:45 Clay Leeds wrote:
Forgive my intrusion, and perhaps this is not related, or
On 6/23/2003 10:19 AM, Jeremias Maerki wrote:
Nice idea, but there's a problem. The xsl namespace gets filtered out by
the XSLT engine, or IOW expanded to the FO attributes before they reach
FOP. FOP never sees anything with the xsl: prefix.
Does this mean that just about every fo:block in the
On 23.06.2003 19:33:23 Clay Leeds wrote:
On 6/23/2003 10:19 AM, Jeremias Maerki wrote:
Nice idea, but there's a problem. The xsl namespace gets filtered out by
the XSLT engine, or IOW expanded to the FO attributes before they reach
FOP. FOP never sees anything with the xsl: prefix.
Does
Jeremias Maerki wrote:
Speaking of which, how does the file created by '-at' differ from the
file generated by running xalan.bat?
That's the Area Tree XML: The layouted pages serialized to a proprietary
XML format. It's only interesting for debugging purposes (in layout
engine development).
And
Peter B. West wrote:
Bertrand is probably in the best position to comment wrt RTF. Is anyone
familiar with MIF. Does it simply define page structures and flows?
I'm roughly familiar with MIF - did some rough HTML to MIF conversion
years ago.
Basically MIF is structured text that is
Victor Mote wrote:
If you can convince me that it is not possible for layout and rendering to
be refactored into distinct tasks or services, then my interest in FOP
diminishes to zero, and I'll stop making so much noise. I don't see why that
should be true.
Layout and rendering can be factored
J.Pietschmann wrote:
Victor Mote wrote:
If you can convince me that it is not possible for layout and
rendering to
be refactored into distinct tasks or services, then my interest in FOP
diminishes to zero, and I'll stop making so much noise. I don't
see why that
should be true.
--- Arnd Beißner [EMAIL PROTECTED] wrote:
Q
If you need a clear differentiation between the
renderer types, you might take this one: do I need to
know the size of a glyph in a certain font/size to
produce the output? If yes, the appropriate renderer
goes into FOP, if not, it goes into a separate
--- Victor Mote [EMAIL PROTECTED] wrote:
(At the risk of getting esoteric, if the
Document object knows that none of the output
options requested support SVG, it
could tell the FOTree builder to ignore that
namespace and save the memory.
That's one helluva smart document you're planning
Glen Mazza wrote:
So the XSL-FO spec--which FOP is trying to implement
for as many output types as possible--is not relevant
for those output types which don't need to know glyph
size? By putting it into a separate tool, that is
what you may be implying.
In a way, that's true. You need
--- Arnd Beißner [EMAIL PROTECTED] wrote:
Glen Mazza wrote:
So the XSL-FO spec--which FOP is trying to
implement
for as many output types as possible--is not
relevant
for those output types which don't need to know
glyph
size? By putting it into a separate tool, that is
what you
Glen Mazza wrote:
We don't do HTML at all (Xalan's department)-- HTML is
browser dependent. HTML is not an output format.
I know, the purpose was to illustrate my point, since
everyone is familiar with HTML, but perhaps not with
MIF or RTF. If you think it makes sense for FOP to
output RTF,
Arnd Beissner wrote:
determined a formatting-time if you can't hand over the
Correction, this typo can be misleading:
determined at formatting-time if you can't hand over the
--
Cappelino Informationstechnologie GmbH
Arnd Beißner
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL
Glen Mazza wrote:
--- Victor Mote [EMAIL PROTECTED] wrote:
(At the risk of getting esoteric, if the
Document object knows that none of the output
options requested support SVG, it
could tell the FOTree builder to ignore that
namespace and save the memory.
That's one helluva smart
Le Dimanche, 22 juin 2003, à 21:15 Europe/Zurich, Arnd Beißner a écrit :
...Before we're getting too philosophical, let me say
that we're now talking two different issues:
1. Is it possible to develop a conforming XSL:FO
implementation that produces RTF or MIF or similar
ouput?
Probably not,
Glen Mazza wrote:
Are you sure? Please read
http://marc.theaimsgroup.com/?l=fop-devm=105455951226310w=2
(Peter, Jeremias' writing)--they appear to indicate
that the area tree is dependent upon the specific
renderer being used, because of the fonts.
Answer 1: I interpreted these comments to
J.Pietschmann wrote:
Could you outline your API ideas on the Wiki?
Sure (give me a couple of days). Again, my point is not to push for a
particular API or framework, but only to show that the control concepts (PDF
encryption was the example given IIRC) can be added to the appropriate
classes as
--- Victor Mote [EMAIL PROTECTED] wrote:
http://marc.theaimsgroup.com/?l=fop-devm=105270887501490w=2
I don't think that is the link you wanted -- it
doesn't seem to be relevant
here.
That was the link--Keiron's writing appeared to
indicate that the area tree needs to be
created/processed
Victor Mote wrote:
J.Pietschmann wrote
...
If you can convince me that it is not possible for layout and rendering to
be refactored into distinct tasks or services, then my interest in FOP
diminishes to zero, and I'll stop making so much noise. I don't see why that
should be true.
Victor,
Without
Jeremias Maerki wrote:
On 20.06.2003 21:23:50 Glen Mazza wrote:
If it does, it determines *which* type
of area tree to create (Structure or MIF or the other
one)--based again on the render_type. The business
logic for this would be in FOTreeBuilder.
But no area tree is generated when a
--- Victor Mote [EMAIL PROTECTED] wrote:
AreaTree
is not
renderer-specific, but RenderContext specific. So,
for example, the same
AreaTree can be used to generate PostScript and PDF
output.
Are you sure? Please read
http://marc.theaimsgroup.com/?l=fop-devm=105455951226310w=2
(Peter,
On 20.06.2003 20:58:58 Glen Mazza wrote:
--- Victor Mote [EMAIL PROTECTED] wrote:
AreaTree
is not
renderer-specific, but RenderContext specific. So,
for example, the same
AreaTree can be used to generate PostScript and PDF
output.
Are you sure? Please read
Previous email was sent before I was done red face/,
please ignore for this one:
--- Victor Mote [EMAIL PROTECTED] wrote:
AreaTree
is not
renderer-specific, but RenderContext specific. So,
for example, the same
AreaTree can be used to generate PostScript and PDF
output.
Are you sure?
On 20.06.2003 21:23:50 Glen Mazza wrote:
(1) Doc/Dri/whatever feed the FOTreeBuilder the xslfo
and the render_type, calls Run()
(2) Based on the render_type FOTreeBuilder either
creates an area tree of its choosing, or doesn't
(AWT/Print).
Even with AWT/Print an Area Tree is generated.
Victor Mote wrote:
I don't understand. The setOutputType() would be in the RenderType class,
which is one of the four classes that Driver would be split into. So there
might also be, for example, a setEncryptionKey() method to handle this. The
whole point of creating the three extra classes is to
Glen Mazza wrote:
foTree = foTreeBuilder.createFOTree();
areaTree = areaTree.createAreaTree(foTree);
Check old FOP versions, like 0.19 or so...
You are correct--this is *very* elegant--problem is,
from Keiron's writing, we just can't separate the
FOTree from the area tree because of an
On 20.06.2003 21:34:28 J.Pietschmann wrote:
Could you outline your API ideas on the Wiki?
Yes, please. I'm also in the process of writing down my ideas. That way
it will be much easier to relate everyone's ideas to each other. At the
moment I wish we could all sit together and figure it out by
On 20.06.2003 21:38:02 Glen Mazza wrote:
This seems to be another layer of indirection--quite
useful still--but might the area tree *still* be
renderer-dependent? (The involved renderers can be
asked--It still has to know which renderers to ask,
right? It may very well get different
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
Even with AWT/Print an Area Tree is generated.
But no area tree is generated when a
StructureHandler (RTF/MIF) is
active.
Yes, I got confused between the two sets of weird
render types: those that handle their processing with
their own
Glen Mazza wrote:
Well, the public API has to have
some way to control
the whole show.
You don't mean that literally--e.g.., a servlet
programmer does not need useThisRenderer() and
attachAreaTree() functions in a public API. (i.e.,
the public (embedded) API would be a strict subset
Victor Mote wrote:
In my vision of the API, the
servlet programmer would not need useThisRenderer(), but would need
something like setOutputType(OUTPUT_PDF), which would ultimately cause the
correct renderer to be selected.
This has already been discussed up and down. There is still the
problem
victor quote
[Responding to Jeremias here] Or, better yet IMO, into
a RenderType
object
that is a child or grandchild of the Document, so that
there can be
multiple
RenderTypes for the same Document.
/victor quote
I can understand enhancements for logging and
threading, but multiple
Errr...this came across as harsher-sounding than I
would have liked.
If the API has some convenient ways for the user to
specify multiple output types for a single xsl-fo
stream, that should be fine.
Glen
--- Glen Mazza [EMAIL PROTECTED] wrote:
victor quote
[Responding to Jeremias here] Or,
On 17.06.2003 21:28:29 Glen Mazza wrote:
Instinctively, I wouldn't trust any code in the
package root of org.apache.fop -- we wouldn't have a
very modularized design that way (knowing FOP's
current coding style, the main FOP API would then be
accessing objects all through the packages,
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
On 17.06.2003 21:28:29 Glen Mazza wrote:
Instinctively, I wouldn't trust any code in the
package root of org.apache.fop -- we wouldn't have
a
very modularized design that way (knowing FOP's
current coding style, the main FOP API would then
On 17.06.2003 01:38:14 Victor Mote wrote:
I did a dry run of the startup refactoring (Session, Document, etc.) work
yesterday this morning, and am satisfied that the concepts work.
Here are some comments:
1. I am going to start committing changes, hopefully this evening. Much of
the work
Jeremias Maerki wrote:
I'm a bit concerned that you call this startup refactoring where it's
really API redesign in the end, I think. And that's an important topic
where I would have expected you to ask for a go for it before starting
on this. Generally, JustDoIt (tm) is a good thing but this
On 17.06.2003 17:10:19 Victor Mote wrote:
Jeremias Maerki wrote:
I'm a bit concerned that you call this startup refactoring where it's
really API redesign in the end, I think. And that's an important topic
where I would have expected you to ask for a go for it before starting
on this.
Victor Mote wrote:
My humble apologies. What is the easiest way to roll it back? Is there an
automated way?
I rolled them back manually, and have committed the change. All should be
back as it was before, except the affected files are two revisions higher.
Victor Mote
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
I'm a bit unhappy that you placed/left Session in
the apps package. I
would like to see the apps package deprecated as a
whole over time. I
would like a cli package that only contains the
stuff needed for the
command line and I'd like to have
Jeremias Maerki wrote:
I'm a bit unhappy that you placed/left Session in the apps package. I
would like to see the apps package deprecated as a whole over time. I
would like a cli package that only contains the stuff needed for the
command line and I'd like to have (wish, not a
Victor Mote wrote:
I'm not opposed to Avalon, but I might be if I understood it.
Well, the good message about Avalon is that it can make
development for much easier.
The bad news is that if too much of Avalon is exposed in the
APIs intended for common usage, it will drive many potential
embedders
Jeremias Maerki wrote:
main FOP api in the org.apache.fop package.
org.apache.fop.api package?
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
J.Pietschmann wrote:
Well, static data often interferes badly with multithreading.
We can use it in the CLI, but in the core which is intended to be
possibly embedded in multithreaded long running server environments
should it is best to avoid them. Even if you can arrange to
synchronize
No problem with that.
On 17.06.2003 23:03:22 J.Pietschmann wrote:
Jeremias Maerki wrote:
main FOP api in the org.apache.fop package.
org.apache.fop.api package?
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL
--- Victor Mote [EMAIL PROTECTED] wrote:
1. I am going to start committing changes, hopefully
this evening. Much of
the work is refactoring, but there are some
substance changes as well,
specifically to allow multiple output options,
multiple documents, etc. I
have therefore decided to
51 matches
Mail list logo
