RE: 0.20.5 release

[Ricardo Amador]

Hi,

Sorry to drop in... Just ignore me if you don't see any relevance.
In any case, don't bother answering me.

Considering that tables are currently the only mean to control
pagination, all my documents have a tendency to include lots of tables
(and they all start with a TOC). I believe I'm not alone. I would say
that any improvement in the memory usage associated with tables, IMHO,
is kind of critical.

BTW, there are currently 8 proposed patches in Bugzilla. Most of them
look to me quite simple and inoquous, and 4 of them are marked as
Enhamcements for version 0.20.5 (there is also an older one for version
0.20.3). It would be nice if one of you guys could take a look at those
patches and consider them before issuing the final 0.20.5 release.

Congratulations to you all on an excellent job, you are doing,
Ricardo Amador

-Original Message-
From: Christian Geisert [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 17, 2003 6:16 PM
To: [EMAIL PROTECTED]
Subject: 0.20.5 release


Ok,

RC3a seems to be rather stable and the changes since then look
non-critical to me. What about doing the release now (read: next days)
(and maybe 0.20.5a later if we get more hyphenation patterns back)

Or should we make the changes proposed by Jörg (improved memory usage
with tables - see 
http://marc.theaimsgroup.com/?l=fop-dev&m=105399053227758 ) which would
require another release candidate.

Comments please!

Christian





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

Re: Eclipse Ant SerializeHyphPattern failure

[Peter B. West]

Jeremias,

Done.  The hyphenation works now.  What's the story with the 
documentation targets now that we are using forrest?  Can they be removed?

Peter

Jeremias Maerki wrote:
Hmm, I've given up running Ant under Eclipse. Gave me too much of a
headache and it works well for me outside of Eclipse.
But I think the trick is to use "${basedir}" instead of "." in build.xml
because Eclipse has to set the base directory so everything is ok. I
have done some other changes locally that I cannot commit, yet, because
I'm blocked on an issue. So I can't commit my build.xml. Can you do it,
please?
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTE] Nomination of Glen Mazza as committer

[Glen Mazza]

Jeremias,

Please forward off the following:

Thanks,
Glen

Full Name: Glen Mazza
Preferred Userid: gmazza
Forwarding email address: [EMAIL PROTECTED]
"Karma":  just xml-fop

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Can do.
> 
> Here's the new account request form that we need to
> fill:
> New account request form:
> 
>  To: [EMAIL PROTECTED]
>  Cc: pmc@.apache.org,
> [EMAIL PROTECTED]
>  Subject: Apache account request
> 
>  Full name:...
>  Preferred userid: ...
>  Forwarding email address: ...
> 
>  Requested karma:  [/]
> ...
> 
> [Vote: link to mail archive for
> PMC bookkeeping]
> 
> 
> On 18.06.2003 10:21:42 Christian Geisert wrote:
> > Clearly enough +1 and no -1, congratulations Glen!
> > 
> > According to http://www.apache.org/dev/pmc.html
> the account
> > request should be handled by the PMC - so Jeremias
> or Peter
> > would you please take care of this?
> 
> 
> Jeremias Maerki
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, email:
> [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

RE: 0.20.5 release

[Thomas Sporbeck]

I would agree to Ricardo. We're using tables for inventory lists
containing about 500 pages. The memory situation in that reports is
really critical and we cannot force the users to set filters.
On the other hand: to us it doesn't matter if this enhancement comes
with 0.20.5 or with a later version (0.20.5a ?), which has of course to
be decided by the developers and will possibly delay refactoring.

Thomas Sporbeck


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

Re: [RTF] Jfor integration

[Bertrand Delacretaz]

Hi Victor,

If you're going to work on the RTFHandler I'd be happy to commit the 
relevant jfor sources (the RTF library I assume) to the FOP codebase 
with appropriate package name changes.

As Jeremias mentions, it might be better if I do it myself so that the 
legal stuff is clear.
I should be able to do it between today and tomorrow.

The idea of using jfor in binary form at first was to avoid having to 
maintain two RTF libraries - but if you're going for it, then the time 
might be right to actually move the code here.

.. Some of the source files contain non-ASCII characters (see
main/JForVersionInfo.java, line 67, for example), but are encoded as 
ASCII
(instead of UTF-8), so the IDE was choking...
Are .java files meant to be encoded in UTF-8? I didn't know that.

...dropping in the Apache license (looks like no problem),
no problem indeed

and some
style issues
Do you mean code writing style like brace positions and stuff, or 
deeper code structure issues?

-Bertrand

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

Re: [VOTE] Nomination of Glen Mazza as committer

[Jeremias Maerki]

Glen,

the request is away. An important thing for you to do is to sign and
submit the Contributor's Agreement. You can find it here:
http://incubator.apache.org/drafts/newcommitters.html along with
important additional information.

As soon as your account is created you will need to set up the SSH
tunnel for CVS access. If you have trouble, just yell!

Welcome aboard!

Jeremias Maerki


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

RE: [RTF] Jfor integration

[Victor Mote]

Bertrand Delacretaz wrote:

> If you're going to work on the RTFHandler I'd be happy to commit the
> relevant jfor sources (the RTF library I assume) to the FOP codebase
> with appropriate package name changes.

Yes, I think the RTF libs are the only parts that are needed. I don't want
to mislead anyone into thinking I'm making a big commitment here -- it will
probably be a little here and a little there.

> As Jeremias mentions, it might be better if I do it myself so that the
> legal stuff is clear.
> I should be able to do it between today and tomorrow.
>
> The idea of using jfor in binary form at first was to avoid having to
> maintain two RTF libraries - but if you're going for it, then the time
> might be right to actually move the code here.

Again, "go for it" is too strong. However, I think integrating the libraries
is a necessary prerequisite for any real progress.

> > .. Some of the source files contain non-ASCII characters (see
> > main/JForVersionInfo.java, line 67, for example), but are encoded as
> > ASCII
> > (instead of UTF-8), so the IDE was choking...
>
> Are .java files meant to be encoded in UTF-8? I didn't know that.

Java source is Unicode, and I don't think the encoding would matter, but
UTF-8 makes the most sense as most of the source is ASCII. And it could be
that most tools don't care, but I know that JBuilder does.

> > ...dropping in the Apache license (looks like no problem),
>
> no problem indeed
>
> > and some
> > style issues
>
> Do you mean code writing style like brace positions and stuff, or
> deeper code structure issues?

I'm talking about the superficial stuff, $Log$ being the most obvious, and
there may be some that checkstyle doesn't like.

As far as the code structure, what I saw was clean and easily
understandable. The only real trouble I had was finding ATTR_ constants, and
I may very well be using the wrong ones (but they work). I had the RTF
standard in hand as I was working through it, so I was able to
reverse-engineer some of it by looking at the strings that the jfor
constants were using. So I might try to document or otherwise clarify some
of that stuff in the code. On the paragraph shading that I was messing with,
I tried dropping the RTF codes directly in, and something downstream
(probably in the actual document creating) seemed to be filtering out or
ignoring them, which is why I was going to try to follow the code through
that process in the debugger. It may be that some of that is documented in
that downstream location. So, if there is some doc on the RTF libs,
especially a mapping of what attributes are used with each RTF object, and
which of the overloaded methods to use with each, that would be extremely
useful. It seems like the wiki said to look at how the conversion tools used
them, but that didn't seem to help much.

Does it make sense in the long run for the jfor libs to be a separate
project? It seems like it should have wider appeal than just for FOP,
although FOP is probably a good home for it for now.

Victor Mote


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

DO NOT REPLY [Bug 20923] New: - Render PCL controls using XSL template

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

Render PCL controls using XSL template

   Summary: Render PCL controls using XSL template
   Product: Fop
   Version: all
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have to use PCL commands in my PDF and PS outputs to control printer trays. 
Last 2 pages of my output should print from Tray2 and rest of the doucment 
should print from Tray1.

The following are my PCL Command suggested by my printer vendor.

To select Tray1 - &l8H
To select Tray2 - &l1H

The above control sequence is working file from an ordinary text file. I am 
able to select print trays and print accordingly.

I have the following sample xsl template where I have these escape sequences


  
  &l1HThis should print From Tray 2
  
  &l8HThis should print From Tray 1
  


When I implement this, I am getting all my controls literally printing from the 
default tray. 

I am seriously thinking, whether the implementation of Escape sequence is 
correct or not. 

Any thoughts?..

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

DO NOT REPLY [Bug 20923] - Render PCL controls using XSL template

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

Render PCL controls using XSL template

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|Other   |Medium

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

RE: startup refactoring

[Victor Mote]

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 of
> the functions available to the supervising octopus
> running the show)

I am not sure what Jeremias meant, but yes, the API needs to at least
indirectly control all of the major decisions. 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. More likely, it would be set in a
constructor. Here is  some simplified sample startup code:

session = new Session;
document = session.addDocument(inputFile);
document.addRenderType(RENDER_PDF, LAYOUT_SIMPLE, outputFile1);
  document.addRenderType(RENDER_POSTSCRIPT, LAYOUT_SIMPLE, outputFile2);
document.addRenderType(RENDER_PDF, LAYOUT_CLASSIC, outputFile3);
document.addRenderType(RENDER_PRINT);
document.process()
   -OR-
session.process()  // if you want session to manage a queue of documents

>From a big-picture control standpoint:
Document = FOTree
RenderContext = AreaTree
RenderType = Renderer

The document.addRenderType() also builds any RenderContext objects that are
needed, three in this example (the first two can share the same AreaTree,
each of the others requires a different one). When document.process() is
run, it looks at the RenderContext objects to determine whether an FO Tree
needs to be built In this case it does (and yes, it should be in a different
package). It can then loop through the RenderContext objects to see what if
any layout work needs to be done, and build an Area Tree based on the output
type and the selected LayoutStrategy. Each RenderContext object will then
loop through the RenderTypes which are attached to it to fire up Renderers.
So in the example above, the same AreaTree will be used to spit out the
first two RenderTypes before trying to build the AreaTree needed for the
"CLASSIC" layout.

Of course, there are a number of configuration options available as well,
all of which can be attached to the appopriate object by a servlet
programmer. The actual using of those options is in other objects (and
indeed, should be in other packages), but the /control/ mechanism can live
in these four classes.

(I have left eager/patient processing out of this example, but control
should be returned to the Document object at the end of each PageSequence to
see if eager processing needs to fire off some layout and rendering work
before continuing with parsing. I am not entirely sure whether eager/patient
processing is totally a function of the LayoutStrategy, or whether some
LayoutStrategies can tolerate either, which would make it need to be
configurable).

> > This will automatically lead to a
> > little octopus if the
> > code is in ...fop or ...fop.api. But no problem with
> > another package.
> >
>
> For my discussion, apps=api (they're both supervising
> octopi).  (Although I'm sure your package would be
> orders-of-magnitude cleaner and simpler!)
>
> > > FOP is more a pipeline to me:
> > >
> > > APPs package (CLI, TRAX/XSLTInputHandler,
> > Avalonized
> > > API, Victor's ideas) -->
> > FOTreeBuilder/Layout/Area
> > > Tree creation --> Rendering.
> >
> > Uh, thanks for that one. It's a very nice show why
> > the current apps
> > package is a mess.
>
> I agree with you that the apps package is hideous--but
> a pipeline may cleanup nearly all of it, providing it
> enforces the rules I mentioned earlier:
>
> a.) The only access between apps/api and the rest of
> the packages is via FOTreeBuilder and its "three"
> functions.
> b.) FOP is designed such that FOTreeBuilder *can* be
> directly instantiated via a servlet (even if we don't
> allow it).
> c.) Once so instantiated, no code within apps/api
> packages can be referenced.
>
> Via these rules, look at what gets removed from apps:
> (a) structure and layout handler are gone (those are
> past the FOTreeBuilder)
> (b) AWTStarter and PrintStarter are gone (those
> processing decisions are either handled by
> FOTreeBuilder or something that it delegates to.)
> (c) App class has *no* knowledge of renderers, element
> mappings, area trees, structure handlers.
> (d) Business logic is kept with each object, and not
> shared in multiple places.
>
> > > IMO FOTreeBuilder should just expose three
> > functions
> > > (perhaps another one for logging):
> >
> > It's best to talk about
> > lifestyle primarily and
> > leave the lifecycle (instantiation, logging,
> > configuration,
> > initialization) to a different discussion. Helps
> > keeping the focus, I
> > believe.
>
> Excellent!  We can leave that distraction out of the
> discussion.  (Although they, in additi

Re: startup refactoring

[J.Pietschmann]

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 that renderers may need a lot of renderer specific
confiuguration data. Take for example PDF encryption. I don't
think it is a good idea to always pass this in some generic
way through the Driver (or whatever the replacement) to the
renderer.
The other problem is the output. There are renderers writing to
a byte stream, there is the AWT and the print renderer which don't
write to a stream like object at all, there may be renderers like
an SVG renderer which write a SAX event stream. Again, I don't
think the output should always be passed through the driver.
It seems quite natural to solve these problems by using separate
renderer objects
  processor = new FOProcessor()
  // configure processor
  renderer = new PDFRenderer(output);
  // configure renderer
  processor.setRenderer(renderer);
If there is no complicated configuration (use all defaults)
you can still write with another constructor
  processor = new FOProcessor();
  processor.format(input,new PDFRenderer(output));
which should be easy enough to servlet programmers.
Note that TrAX uses a similar pattern, with Source and Result
abstracting a variety of input and output mechanisms to the
XSLT processor.
[big snip]
Discussing the API may be fun, but IMO fixing bugs like the
broken text justification should get some attention too. The
best API is useless if the code inside doesn't work.
J.Pietschmann



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

DO NOT REPLY [Bug 20923] - Render PCL controls using XSL template

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

Render PCL controls using XSL template

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-06-19 20:40 ---
Printer control commands cannot be passed through regular content in XSLFO,
almost by definition. Apart from this, your understanding how printer
controls look like is seriously wrong, as well as your understanding about
printer tray selection mechanisms in PDF and PostScript.
There are some possiblities to postprocess FOP output to achieve printer
tray selection, but this is non-trivial stuff.
Please don't use bugzilla to ask questions, there is a fop-user list for
this purpose.

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

RE: startup refactoring

[Glen Mazza]

[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 appears to be Cocoon's department, not ours. 


We're at a level below that, very similar to Xalan:

Xalan input: xml document, xslt stylesheet
Xalan output: document

FOP input:  xml (xsl-fo namespace) document, render
type
FOP output: document

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, perhaps this is best left with Cocoon.

Glen



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

RE: startup refactoring

[Glen Mazza]

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 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 appears to be Cocoon's department, not
> ours. 
> 
> 
> We're at a level below that, very similar to Xalan:
> 
> Xalan input: xml document, xslt stylesheet
> Xalan output: document
> 
> FOP input:  xml (xsl-fo namespace) document, render
> type
> FOP output: document
> 
> 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, perhaps this is best left with Cocoon.
> 
> Glen
> 
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, email:
> [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

Eclipse checkstyle

[Peter B. West]

Jeremias, Joerg and other Eclipse users,

I'm trying to apply Checkstyle 3.1.0 to fop-head via Eclipse 2.1, and am 
having a few problems.  I cannot import the checkstyle.cfg file, so I 
have constructed a new one.  I seem to have been much too restrictive in 
what I have tried, and am now working my way through deleting or 
detuning rules.

I have since that paragraph was written received some info from David 
Schneider on the Eclipse-cs-developer list.  It seems the checkstyle.cfg 
we have in fop-head is pre-version 3.  Version 3.1.0 does not support 
the check for a header file, which is why it does not appear in the 
Preferences Checkstyle UI, or linked into the relavant integrated 
documentation.  That will not be available until at least 3.2.

I will commit a 3.1.0 style config, and those of you who haave followed 
the style discussion more closely might like to modify it.  I suspect 
there are more options in the new version.

I am on a steep learning curves with Checkstyle and the conventions, 
which I am planning to apply to alt.design before going any further. 
That learning curve is probably another reason to cast an eye over the 
config I create.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Eclipse Ant SerializeHyphPattern failure

[Jeremias Maerki]

I think so. Please remove them.

On 19.06.2003 11:27:15 Peter B. West wrote:
> Done.  The hyphenation works now.  What's the story with the 
> documentation targets now that we are using forrest?  Can they be removed?



Jeremias Maerki


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

Re: Eclipse checkstyle

[Jeremias Maerki]

Oh, I didn't realize that David has a new version of his excellent
plug-in. He said he would drop me a note when the new version for
checkstyle 3.x is out. Hmm. I'm downloading right now.

Can you upload what you have already?

On 20.06.2003 08:14:21 Peter B. West wrote:
> Jeremias, Joerg and other Eclipse users,
> 
> I'm trying to apply Checkstyle 3.1.0 to fop-head via Eclipse 2.1, and am 
> having a few problems.  I cannot import the checkstyle.cfg file, so I 
> have constructed a new one.  I seem to have been much too restrictive in 
> what I have tried, and am now working my way through deleting or 
> detuning rules.
> 
> I have since that paragraph was written received some info from David 
> Schneider on the Eclipse-cs-developer list.  It seems the checkstyle.cfg 
> we have in fop-head is pre-version 3.  Version 3.1.0 does not support 
> the check for a header file, which is why it does not appear in the 
> Preferences Checkstyle UI, or linked into the relavant integrated 
> documentation.  That will not be available until at least 3.2.
> 
> I will commit a 3.1.0 style config, and those of you who haave followed 
> the style discussion more closely might like to modify it.  I suspect 
> there are more options in the new version.
> 
> I am on a steep learning curves with Checkstyle and the conventions, 
> which I am planning to apply to alt.design before going any further. 
> That learning curve is probably another reason to cast an eye over the 
> config I create.


Jeremias Maerki


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