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 a
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
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.
>
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 inte
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 j
On 6/23/2003 3:08 AM, J.U. Anderegg wrote:
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-F
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
> 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 f
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 th
> 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
> cle
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, XSL-FO
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 hel
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 PROTE
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 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 i
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
--- 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 plann
--- Arnd Beißner <[EMAIL PROTECTED]> wrote:
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 t
Peter B. West wrote:
> 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
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 t
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 in
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 annot
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 Structur
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,
Withou
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> >
>
http://marc.theaimsgroup.com/?l=fop-dev&m=105270887501490&w=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
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
Glen Mazza wrote:
> Are you sure? Please read
> http://marc.theaimsgroup.com/?l=fop-dev&m=105455951226310&w=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 comme
--- 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
th
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
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
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 unacceptabl
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> >
>
http://marc.theaimsgroup.com/?l=fop-dev&m=105455951226310&w=2
> > (Peter, Jeremias' writing)--they appear to
> indicate
> > that the area tree is dependent upon the specific
> > renderer being used, because of the fonts.
>
> Today, that is so. M
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 m
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 generate
Previous email was sent before I was done ,
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? Pleas
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
> htt
On 18.06.2003 22:36:12 Glen Mazza wrote:
> > The FO
> > tree
> > builder is (to me) a service that simply accepts a
> > SAX stream and builds
> > the FO tree.
>
> IMHO FOTreeBuilder is an object (C++/Java), not a
> service (C).
I'm talking about Avalon-style services. These are components that
--- 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-dev&m=105455951226310&w=2
(Pe
Glen Mazza wrote:
> Given that our Area tree is renderer-specific, and
> since the area tree creation is tightly bound to fo
> tree creation--I think any internal implementation we
> would have of multiple rendering types would just
> involve running FOP once for each rendering type. If
> so, per
J.Pietschmann wrote:
> 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 discuss
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:
>
>
> [Responding to Jeremias here] Or, better
[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.
I can understand enhancements for logging and
threading, but multiple RenderTypes for the same
Document a
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 tha
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 stric
--- 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
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,
>
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 PROT
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
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]
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 a
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, n
--- 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
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
-
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
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 b
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
--- 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 deci
57 matches
Mail list logo