New: AFP Renderer / Batch Assembler for FOP
For details see: see http://mypage.bluewin.ch/huanderegg Topics of general interest: - use of Jeremias Maerki's extension sample: for PDF bookmarks, JavaScripts, barcodes? - Java Image I/O - decoupling the renderer Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: bsf.jar
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? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13586] - fop will not work on linux alpha because jre is broken (workarround included)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13586. 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=13586 fop will not work on linux alpha because jre is broken (workarround included) --- Additional Comments From [EMAIL PROTECTED] 2002-12-07 18:43 --- Stefan, can you please verify that using Float.MAX_VALUE will be ok under jre-1.3.1 for linux-alpha? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15144] - Transform fails when using source file on with valid windows network urls
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15144. 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=15144 Transform fails when using source file on with valid windows network urls --- Additional Comments From [EMAIL PROTECTED] 2002-12-07 20:01 --- Is your \\lucy\projectc\reckit stuff mapped to ftp server? Anyway I don't think it's our bug, apparently it looks like xml parsing problem (btw, are you sure test1.htm is well-formed xml?) Matthew, can you apply xml2pdf.xsl to your //lucy/projectc/reckit/output/test1.htm without FOP? Run xalan processor from a command line, see [1] how to do it. [1] http://xml.apache.org/xalan-j/commandline.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/foschema fop.xsd
vmote 2002/12/07 12:31:30 Modified:docs/foschema Tag: 1.1.0 fop.xsd Log: . Revision ChangesPath No revision No revision 1.1.0.1 +0 -0 xml-fop/docs/foschema/fop.xsd Index: fop.xsd === RCS file: /home/cvs/xml-fop/docs/foschema/fop.xsd,v retrieving revision 1.1 retrieving revision 1.1.0.1 diff -u -r1.1 -r1.1.0.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15144] - Transform fails when using source file on with valid windows network urls
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15144. 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=15144 Transform fails when using source file on with valid windows network urls [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-07 21:59 --- The network library appear to resolve a network-path (see RFC 2396) to an ftp: URL, which of course fails. Try to use an absolute file URL file://lucy/projectc/reckit/output/test1.htm Either way, this is a problem with the JRE, not with FOP itself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Keiron Liddle wrote:
As far as I am concerned it is largely irrelevant whether the particular
layout design is 100% correct.
There will never be a design which is 100% correct. However, some designs
are easier to comprehend than others. The HEAD design has a few stumbling
blocks for beginners.
Let's start with LMiter. The class name is not only badly abbreviated,
it is also misleading if spelled out a LayoutManagerIterator. Commonly,
iterators are named after the collection the are iterating, not after
the data they expect to be in the collection. The main problem is that
the collection with said LayoutManagers is purely virtual and never
exists as an object, which makes it very hard to grasp where the
layout managers come from. This severly disrupts tracking the control
flow. Furthermore, just looking at the LMiter source it appears to be
horrible, for once because of the creation with a base iterator, and
secondly the because of the preLoadNext() which is not called in next().
This indicates that some interesting things happen outside of the LMiter
class and a that encapsulation is violated. Also, from the implementation
of LMiter it is *still* not clear what's iterated here. Suggestion: either
implement a LayoutManagerList and an associated LayoutManagerListIterator
and make them self contained and transparently caching, or move the state
keeping and access into the LayoutManager itself.
There is also the BreakPosPossIterator which also doesn't iterate over a
tangible collection. In fact if you see
public void addAreas(PositionIterator parentIter, ...
there is no way to say what the heck is iterated here. Furthermore, this
iterator violates common Java iterator patterns, in particular
while ((childLM = breakPosIter.getNextChildLM()) != null) {
childLM.addAreas(breakPosIter, lc);
should better be
while (breakPosIter.hasNext()) {
childLM = breakPosIter.next().getChildLM();
childLM.addAreas(breakPosIter, lc);
}
Also, such an iterator is often created by something which is not the
collection iterated over but with constraints which represent a
subcollection of the collection iterated over:
PositionIterator breakPosIter =
new BreakPossPosIter(blockBreaks, iStartPos,
lfp.getLeafPos() + 1);
This makes it even harder to keep track where the iterator actually points
and what this means.
A third point, uncanny in itself but still minor overall is the distinction
between positions and break possiblities. This implies that either positions
are used for something else beside break possibilities, or break possibilities
can be something else than positions. But most of the source implies that
neither will ever be the case. Unfortunately, while examining a layout manager
implementation, the users sees first that a collection with break possiblities
is created, and then there is a loop over positions which adds areas. It would
be easier to understand if the same abstraction, break possibility, was used
in both parts of the code. One of the possiblities is to unify break
possiblities and positions, another would be to use break possibilities only
and retrieve positions from them as needed.
Now the biggest issue: the layout managers itself. At the first glance it is
not obvious why they should be first class objects at all, in particular as
a cursory examination of the code shows a one-to-one correspondence to FOs
both for classes and instances. Well, layout managers abstract the layout
*process*, however, the deep layout manager class hierarchy is mainly designed
around code reuse, which makes it really hard to understand. There is a reason
that design rules recommend against overuse of inheritance for code reuse and
deep inheritance hierarchies. There is only so much someone can hold in the
brain. Nevertheless, this is something I don't know how to fix on the cheap.
HTH
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: AFP Renderer / Batch Assembler for FOP
This is really a great add on to FOP. Particularly for people who want to print in the mainframe environment with the AFP printers. Thanks a lot Anderegg. -Rajendran - Original Message - From: J.U. Anderegg [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, December 07, 2002 10:05 AM Subject: New: AFP Renderer / Batch Assembler for FOP For details see: see http://mypage.bluewin.ch/huanderegg Topics of general interest: - use of Jeremias Maerki's extension sample: for PDF bookmarks, JavaScripts, barcodes? - Java Image I/O - decoupling the renderer Hansuli Anderegg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
