Re: RE: help!!!

Hi : At the first,thinks for your help! Now I am looking for fopdot(write with C#),but I can't get LogKit.NET at http://www.pinetree-tech.com/projects/fog07.html. Can you help me? Thinks a lot! >On the contrary, that's how bosses are. Don't even get

RE: FOP memory usage

> -Original Message- > From: Peter B. West [mailto:[EMAIL PROTECTED]] > Sent: August 14, 2002 11:24 PM > To: [EMAIL PROTECTED] > Subject: Re: FOP memory usage > > Joerg, Keiron, et al, > > This is why I have harped on the theme of lookahead. The layout design > simply must accommodate it,

Re: Property handling

J.Pietschmann wrote: > Peter B. West wrote: > >> More less than more, I should think. Parsing is inherently "generic". >> E.g., I assume that you would use the same tokenizer and first-level >> parser. > > > At the tokenizer level, sure. However, the spec provides for > a wildly varying spec

Re: FOP memory usage

Joerg, Keiron, et al, This is why I have harped on the theme of lookahead. The layout design simply must accommodate it, and must be able to preserve as much information as possible from the initial layout attempts to minimise the work of subsequent attempts. I have, as I have said before, m

Re: Style issues.

pietsch, Style judgements are a very personal matter. Personal tastes follow. J.Pietschmann wrote: > 1. I'd appreciate if indentation uses spaces instead of >tabs. And because I can avoid using tabs, I expect >everyone else avoiding tabs too. This is pretty much a necessity because of

DO NOT REPLY [Bug 11709] New: - NullPointerException from PDFXObject.output()

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_b

Re: just a thought

Oleg Tkachenko wrote: >> Writing a custom iterator for the children >> list would solve this... > > I agree with you, but this one seems to be simple and would benefit by > decoupling fo tree internal structure and its usage. Usual design > pattern could be used - hierarcy of custom iterators:

Re: Property handling

Peter B. West wrote: > There is a gotcha. 'font-size' > within a marker subtree has no parent at the time of XML parsing. The > same goes for everything else within the marker subtree. All resolution > in the marker subtree must be deferred until the subtree is "re-parented". I should have

Style issues.

Hello all, I just took a more extended look at CVS HEAD. There are some style issues which caught my eye. 1. I'd appreciate if indentation uses spaces instead of tabs. And because I can avoid using tabs, I expect everyone else avoiding tabs too. 2. I'd really, really appreciate if assignme

Re: FOP memory usage

Keiron Liddle wrote: > As far as I know there is never a case where a finished page should be > redone. Once a page is complete that is it. > Those problems should be solved during the layout of a page only and not > considering furture pages. Well, if widows="2" and you've laid out a block and d

Re: Tasks - layout

Keiron Liddle wrote: > - Add static areas to page > The static areas will need to be handled in a similar way to the flow > except the bpd is unlimited and it will need to reset and repeat for > each page. I looked at it. Is static content supposed to be handled by a FlowLayoutManager too? It s

Re: Property handling

Peter B. West wrote: > More less than more, I should think. Parsing is inherently "generic". > E.g., I assume that you would use the same tokenizer and first-level > parser. At the tokenizer level, sure. However, the spec provides for a wildly varying spectrum of grammars, there are aritmetic

RE: OpenType support

Jeremias: > Any news on OpenType support? ... it's a low priority thing. I haven't done much with it yet. I thought it important for me to learn my way around FOP before trying to start any coding. After starting that, I decided that the javadocs could really use some work, especially at the hig

cvs commit: xml-fop/src/org/apache/fop/layoutmgr LeafNodeLayoutManager.java

keiron 2002/08/14 07:46:41 Modified:src/org/apache/fop/layoutmgr LeafNodeLayoutManager.java Log: fixed reset, only does it when restarting leaf node Revision ChangesPath 1.9 +5 -2 xml-fop/src/org/apache/fop/layoutmgr/LeafNodeLayoutManager.java Index: Lea

cvs commit: xml-fop/src/org/apache/fop/fo FOTreeBuilder.java

keiron 2002/08/14 07:25:18 Modified:src/org/apache/fop/fo FOTreeBuilder.java Log: made messages more sensible Revision ChangesPath 1.40 +3 -3 xml-fop/src/org/apache/fop/fo/FOTreeBuilder.java Index: FOTreeBuilder.java

cvs commit: xml-fop status.xml

keiron 2002/08/14 06:45:45 Modified:lib batik.jar src/org/apache/fop/svg PDFTextPainter.java SVGUserAgent.java .status.xml Log: Updated batik with change to TextPainter interface and UserAgent. Improved PDFTextPainter to handle more type

Re: [GUMP] Build Failure - xml-fop

On Wed, 2002-08-14 at 13:14, Jeremias Maerki wrote: > Looks like the Batik guys have changed the TextPainter interface without > thinking about dependencies on other projects. Keiron, shall we make the > changes to conform to their new interface or should they reconsider this > change? Give me a

Re: FOP components (was: Re: Avalon integration: First batch of changes,Logging)

J.Pietschmann wrote: > - If the FO objects are primarily data holders, why > have them at all, instead of using a standard DOM? I believe standard DOM implementations are obviously too synchronized to provide thread-safe access, while fo tree is built sequentially and is read-only after its b

Re: just a thought

J.Pietschmann wrote: > appropriate cast. Unfortunately, in the maintenance branch > the children vector is protected and directly accessed in a > lot of places, putting the test+cast code and the handling > of the one-child-only special case everywhere seemed to be > too much work. Writing a cus

Re: [GUMP] Build Failure - xml-fop

Looks like the Batik guys have changed the TextPainter interface without thinking about dependencies on other projects. Keiron, shall we make the changes to conform to their new interface or should they reconsider this change? This is the link to TextPainter in Batik's CVS: http://cvs.apache.org/

[GUMP] Build Failure - xml-fop

This email is autogenerated from the output from: Buildfile: build.xml Caught exception (org.apache.tools.ant.BuildException) w

OpenType support

Hi Victor Any news on OpenType support? I haven't done a lot of thinking about my upcoming proposal on centralized font support. Well, I have to admit that it's a low priority thing. I'll start it when I'm going to dive deeper into the Avalon things. But that shouldn't stop you from working on Op

Re: FOP components (was: Re: Avalon integration: First batch of changes, Logging)

On 13.08.2002 23:15:39 J.Pietschmann wrote: > Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > The FO objects are primarily just data holder, so it doesn't make > > sense to make them too heavy-weight. They need to be as light-weighted > > as possible to save memory. Most of the logic is transfe

automatic width adjustment

Hi,I am looking for an XSL FO engine which- supports automatic width adjustment for columns (no need to declare thewidth in advance). anyhelp??Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs