Re: Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems

ourself to decide whether knowing TeX's implementation is useful. It is a best-fit algorithm. There is no look-ahead. For example, TeX is not able to balance two facing pages (or two columns on a page, which for TeX is the same). I guess that a dissertation like that cited above contains much more information than implemented in TeX. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Skype-conference on page-breaking?

but I would prefer after 19.00 hrs CET. There is no way I can do this at the office. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

as TableHeader does. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: page-breaking strategies and performance

which receives the Knuth elements and invokes the appropriate algorithm goes with it. Such a setup should not only enable multiple page breaking strategies, but also help us implement a simple strategy to start with, and gradually evolve it to a higher level of sophistication. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: page-breaking strategies and performance

ut I've got to > do it anyway. Since I don't want to work with a series of patches like > you guys did earlier, I'd like to create a branch to do that on as soon > as we've agreed on a strategy. Any objections to that? That is a good idea. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Skype-conference on page-breaking?

Skype > radar already. I do not have a broadband connection, and therefore no Skype or other VoIP. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

If a person is solving one problem, he cannot solve all related problems at the same time. Such problems can be tackled at another time, and perhaps by another team member. So, please, do not say that a solution is not everything, but take the opportunity and tackle the problem that remains. Or,

Re: Markers added to the wrong page

y in certain circumstances while on the other side no area is > generated (empty block with only markers). > > You can easily see these bogus areas when you output to the area tree > renderer or in build/test-results/layoutengine when running the Ant > build. > > I'll continue investigating but would appreciate any ideas you might > have. > > Jeremias Maerki > -- Simon Pepping home page: http://www.leverkruid.nl

testcases

Jeremias, Note that you can use the ancestor axis: xpath="//text[. = 'line1']/ancestor::pageViewport/@nr" instead of xpath="//text[. = 'line1']/../../../../../../../../../@nr" Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Problems with layoutengine test files

timeException: Expected XPath expression to evaluate to 'line-through', but got 'li' (XPath: //flow/block[3]/lineArea/inlineparent[1]/text) Regards, Simon > On 06.02.2005 13:54:54 Simon Pepping wrote: > > Hi Jeremias, > > > > I have errors with

Re: Markers added to the wrong page

ed (empty block with only markers). > > You can easily see these bogus areas when you output to the area tree > renderer or in build/test-results/layoutengine when running the Ant > build. > > I'll continue investigating but would appreciate any ideas you might > have. > > Jeremias Maerki > -- Simon Pepping home page: http://www.leverkruid.nl

Problems with layoutengine test files

test files. I think you should modify all cases where you test on the content of a text area. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: commit to fop

t about rtf-rendering? is peter herweg still active on it? > i'm open, so please give me some hints on where i could start Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop build.xml

ml,v > > retrieving revision 1.112 > > retrieving revision 1.113 > > diff -u -r1.112 -r1.113 > > --- build.xml 6 Jan 2005 19:20:37 - 1.112 > > +++ build.xml 12 Jan 2005 19:50:36 - 1.113 > > @@ -696,6 +696,7 @@ > >

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination/bookmarks Bookmark.java BookmarkTitle.java BookmarkTree.java

{ ==> enums[enumValue] = new EnumProperty(enumValue, text); <=== } return enums[enumValue]; } Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java

On Tue, Jan 11, 2005 at 09:25:50AM +0100, Jeremias Maerki wrote: > > On 10.01.2005 22:00:01 Simon Pepping wrote: > > There does not seem to be a need to add > > the inherited value later; the property maker already has done so. See > > IndentPropertyMaker.comput

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr TraitSetter.java BlockLayoutManager.java

ants.PR_START_INDENT).getLength(); > >endIndent = pList.get(Constants.PR_END_INDENT).getLength(); > > + > > + if (!pList.getFObj().generatesReferenceAreas()) { > > +inheritedStartIndent = pList.getParentPropertyList() > > +.get(Constants.PR_START_INDENT).getLength(); > > +inheritedEndIndent = pList.getParentPropertyList() > > +.get(Constants.PR_END_INDENT).getLength(); > > +} > > +} > > > > > > Jeremias Maerki > -- Simon Pepping home page: http://www.leverkruid.nl

Re: [RT] FOP RTF edition

get layout et al done are generally not attracted > to the mundane tasks that a FOP RTF would require. I believe that releasing is a good thing as soon as we have a usable product. But it is true that I am not very attracted to such a task at the moment. Whether instead I am thinking deeply i

Re: fo.InlineLevel -- make abstract?

eason why you made it instantiable--or > > was this just an oversight? (Actually, anyone know > > why we're not making FObj and FObjMixed abstract as > > well? I might be missing something here...) > > > > Jeremias Maerki > -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/datatypes LengthBase.java

FO). If I remember correctly, the parentFO is only used if the attribute value is 'inherit'. Otherwise it converts the attribute value into a property value object. See my description in http://www.leverkruid.nl/FOP/html/ch09s02.html. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/datatypes LengthBase.java

nce to the FO to which the property using this LengthBase belongs. But I would not know how to replace the method PropertyList.getInherited(). Perhpaps Finn wants to take a look at this? Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Tweaking the FO class hierarchy

ng possibilities? I'm not planning on reworking the > whole thing, just to improve what I stumble upon. I know nothing that speaks against that. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

(PageSequenceLayoutManager) > > > > > getLayoutManagerMaker().makeLayoutManager(pageSequence); > > +} catch (FOPException e) { > > + log.error("Failed to create a > > PageSequenceLayoutManager; no pages will be laid > > out:"); > > +log.error(e.getMessage()); > > +return; > > +} > -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

s) { > +FOText foText = (FOText) node; > +if (foText.endIndex - foText.startIndex > > 0) { > +lms.add(new > TextLayoutManager(foText)); > +} > +} > +} > -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/render/pdf PDFRenderer.java

like terms for PDF bookmarks used, minor bug in > TableLayoutManagerMaker fixed. Sorry for the regression, and thanks for spotting and fixing it. I have also taken measures to avoid the tabs. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Large files.

On Mon, Dec 13, 2004 at 02:26:40PM -0700, Victor Mote wrote: > Simon Pepping wrote: > > > The code you presented seems to be an algorithm implementing > > an iterator over a tree. Because it maintains its state, it > > can be stopped and resumed at will, provided you kee

Re: remove Runnable from PageSequenceLayoutManager?

(although the more extensive logic will still need to > be developed). Thoughts? Objections? It is true that nothing has been done to make threading a reality. I do not object to your removing the Runnable interface. Are you a fan of Extreme Programming? They seem to teach you to avoid adding fu

Re: Large files.

-- am I correct in understanding that you > are essentially flattening the tree so that inheritance must be captured > before that flattening takes place? Or are you simply making that an option > now? Do you want to traverse the FO tree, without relying on the Java stack, and drive the l

Another problem with Marker.rebind()

runs with the same FO tree from reusing markers that would pertain to the layout of an earlier run. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Retrieve-marker and removal of leading and trailing spaces

m does not recognize that fo:retrieve-marker elements may generate text. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Marker.rebind()

Hi, I have just committed a patch which fixes bug 32253. One problem remains: the text in the marker does not always have the right properties, e.g. the right size. This is probably due to the fact that Marker.rebind() does not rebind the whole subtree below a marker. Regards, Simon -- Simon

Re: [Bug 32253] - Marker bugs

h, or in a new class of Knuth Element, which LineLM would know that it should be placed on a line of its own. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: More questions on line breaking.

Plass, Breaking Paragraphs into Lines, Software---Practice and Experience 11 (1981) 1119-1184. It should be possible to find this journal in academic libraries. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Knuth linebreaking questions

pass it on to a client class, e.g. LineLM. Cf. FOUserAgent.getUserRendererConfig(). TeX's terms are pretolerance and tolerance for the two values of maxAdjustment. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Good news: Jeremias has been elected as an ASF member!

this is well deserved, given all the > energy that Jeremias has been pouring tirelessly in FOP, Batik, the XML > federation and probably many things here that I don't know about. Congratulations, Jeremias, and thank you for your efforts. Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Knuth linebreaking questions

. If the line of class i leading to breakpoint b does not have an amount of demerits best.getDemerits(i) which is less than the minimum demerits of all four classes (there is one best line of each class leading to breakpoint b), best.getMinDemerits(), plus incompatibleFitnessDemerit, it can never be

Re: [Bug 32253] - Marker bugs

eakPoss method, and return the BPs for the lines in the block. InlineLM's getNextKnuthElements would return KnuthElements and BPs. How can these return types be mixed? LineLM's getNextBreakPoss would collect the returned KnuthElements in paragraphs, and determine the BPs in it. It would store the BPs received from its children unmodified. The inner block would create its own areas, with proper alignment, borders, margins, indents, etc. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: [Bug 32253] - Marker bugs

none in your example) and a large B. The layout you describe can be achieved using an inline-container, I believe. > If this was the intention, then the proposed 'handing off the BlockLM to the > ancestor BlockLM' wouldn't work... :-( There may well be several ways in which the user can specify a certain layout. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: [Bug 32253] - Marker bugs

be the most important one > to solve. Indeed. Something like ICLM is needed, which creates an inline area containing the block areas. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: [Bug 32253] - Marker bugs

On Wed, Nov 17, 2004 at 02:25:02PM +0100, Luca Furini wrote: > Simon Pepping wrote: > > > Marker extends FObjMixed, which adds InlineStackingLM. This is a > > problem. In the new model there should be a strict separation between > > LMs implementing InlineLevel

Re: [Bug 32253] - Marker bugs

ragraph layout algorithm like Knuth's. Sorry for the inconvenience in the mean time. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: [Bug 32253] - Marker bugs

otherwise getNextBreakPoss would be invoked. Apparently I am wrong, and this warrants more study than a quick solution. I do not have time to investigate this in more depth during this week. The same for the block-inline-block error. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Absent markers throw a ClassCastException in LineLM

t there is a strict separation between block and inline area generating LMs. For RetrieveMarkerLM that separation is not so clear. I think it has to implement InlineLevelLM, otherwise it cannot act as a child of LineLM, at the penalty that you noticed. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: commenting the Knuth code/centering issue

) I'd like to hear your opinions before > committing them. These comments are fine. Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: remove LayoutManager.initialize()?

initialization actions which for some reason cannot be done in the constructor. I have no idea which actions that could be. If you can move all required actions for a new LM object into the constructor, I have no objection to the removal of this method. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/documentation/content/xdocs/dev book.xml

see if I can come up with > some other solution, although my guess is that any workaround will > preclude it from having the same look & feel as the rest of the FOP web > site. A shame; I thought book.xml was the right name for this file. Renamed to DnI.xml. Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/documentation/content/xdocs/dev book.xml

.xml > > Log: > > removed all book.xml files (except DnI) > > Web Maestro Clay > -- > Clay Leeds - <[EMAIL PROTECTED]> > Webmaster/Developer - Medata, Inc. - <http://www.medata.com/> > PGP Public Key: <https://mail.medata.com/pgp/cleeds.asc> > -- Simon Pepping home page: http://www.leverkruid.nl

Re: commenting the Knuth code/centering issue

> I spend on FOP I should start looking a little more at > the scientific aspects of this work.)] I have it. The chapter on the line breaking algorithm is very enlightening. Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Form Extension

in English. > > > Before you post on fop-user perhaps you/we should transfer it to a more > 'permanent' server (since your e-mail will be in the FOP archives in > perpetuity). I'm thinking that a good to place for this extension is on > the 'Objects For Format

Re: DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

Luca, I will try to look at your patch later this week. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: → in DnI documentation

validate during the /forrest/ run (unless I replace → with > → or →). Once the document and the stylesheets have been written, nothing is very docbook specific. Only correct absolute paths or good catalogs matter at that stage. Nevertheless, docbook is a very complex DTD that uses the whole DTD machinery. I am glad it works. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: → in DnI documentation

> > Thanks! > > Web Maestro Clay > -- > Clay Leeds - <[EMAIL PROTECTED]> > Webmaster/Developer - Medata, Inc. - <http://www.medata.com/> > PGP Public Key: <https://mail.medata.com/pgp/cleeds.asc> > -- Simon Pepping home page: http://www.leverkruid.nl

Re: Meta info [was: Printing from multiple trays with FOP generated output]

nt, but the RenderX > > method seems better because nondevelopers can use it > > as well. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: How much work is left before we can release HEAD?

ve logging. Good tests would be more satisfactory. Unfortunately, I do not yet know anything about unit testing, so I cannot write such tests. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/documentation/content/xdocs/design layout.xml

ut the issue. Note that justification has only been implemented for the PDF renderer. It may be easily implemented by other renderers who can do the actual justification themselves, given the required dimensions. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: XML Graphics: board concerns

Thanks for following this up. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo CharIterator.java FOText.java OneCharIterator.java RecursiveCharIterator.java AbstractCharIterator.java

Don't you believe in the separation of Interface and abstract implementing superclass? If AbstractCharIterator adds nothing to the interface, it is better to remove this abstract superclass. It does implement a few methods, though. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

[VOTE] Luca Furini for Committer

p;short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Reuse+same+sort+as+last+time -- Simon Pepping home page: http://www.leverkruid.nl

Re: Project offo distributes hyphenation pattern files for FOP

to get the idea explained and this license statement accepted was lengthy. I took care to state each license carefully in the covering page http://sourceforge.net/offo/hyphenation.html. For a large part thanks to Jeremias earlier work. Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Project offo distributes hyphenation pattern files for FOP

to make it less dependent on one person. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java

as mentioned in the java documentation. I do not find it an attractive idea. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: BreakPoss class

that that is not explained; the text behaves as if that is the only version of FOP. I will change that some time. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: foray integration

project as parallel efforts to realize a valuable open source formatting objects processor. As I said earlier, I wish to spend my time on the layout system in the trunk, which leaves me no time to port FORay's code back into FOP. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: remove layout package?

ke to drop the layout package and make > hyphenation a top-level package (i.e., > org.apache.fop.hyphenation). Comments? I have no problem with your proposal. Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: [Bug29124] - New line breaking algorithm

On Fri, Sep 03, 2004 at 10:23:27AM +0200, Luca Furini wrote: > > Simon Pepping wrote: > > > You mention that you have not implemented the Knuth algorithm for > > ContentLM. Would it be difficult to do that? > > No, I have almost done. > I think I will be able to

Re: Handling of text-align="justify" when nesting blocks

en if it's not the last line of the block ("block" as in > "fo:block"). It sounds like you are right. This would apply to a displayed formula in a paragraph. Nobody would want a layout in which the last line before the display is justified, so there seems to be a problem here. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: [Bug 29124] - New line breaking algorithm

strange effects like this are possible today. Can you > see what the output would look like in such a scenario with the current > code? The current code breaks the paragraphs into lines. It makes short lines. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: validateChildNode prevents extensions.

OP, with or without extensive > validation of the extended content model, but at least > *without* having to rewrite and replace core FO classes. My thoughts are along the same lines that Jörg has argued. I think we should do option 2. vCN() should be written such that it allows

Re: [Bug 29124] - New line breaking algorithm

he older version of the code, I get inconsistent code. When I apply it to the newer version, I get errors by the patch program. Can you try to generate a new patch? Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Setting up the output format

have been working in. Are you going to write this down more in extenso? Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Setting up the output format

eds just a little bit of > that file--a few FO's or a few properties, etc. > > But it has not been a problem to me, I work on the > code rather heavily. Neither have Finn, Simon or > Chris mentioned this--and by virtue of working in > Layout and FOTree, they would presumably come across > this problem much more often. -- Simon Pepping home page: http://www.leverkruid.nl

Re: [Bug 29124] - New line breaking algorithm

is can be done for a space property. Something similar happens for length properties, which can have the default value "auto". I think "normal" should be a keyword. Apparently, the actual value can only be calculated at layout time, when the font is known. Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: [Bug 29124] - New line breaking algorithm

gt; the original files, so finding lots of difference due to recent cvs commits. Perhaps you cannot include new files, because as an anonymous CVS user you cannot add files (cvs add). Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: [Bug 29124] - New line breaking algorithm

last line. In the TeXbook, p. 99, Knuth describes it as 'the special trick that allows the final line of a paragraph to be shorter than the others'. Setting \parfillskip to 0 removes this ability. Usually \parfillskip has infinite stretchability. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

some > of us need fewer moving parts to be productive! ;) > Please review the thread again to understand my > concerns here. I prefer Finn's proposal, as it promises to make a cleaner separation between the FO and layout modules. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

[Bug 29124] - New line breaking algorithm

rious to see how you negotiated all the descendant LMs. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

with its two passes, getNextBreakPoss and addAreas, over the LM tree. I believe it must be made simpler to allow a decent Java programmer to add code to the layout system. It is an aspect I want to pay attention to, but I will take it slowly and cautiously. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Switch from AddLMVisitor to FObj.addLayoutManager()

t; > code are irrelevant to the > > end user. I tend to agree with this point, and see > > no benefit in removing tbe > > AddLMVisitor stuff. So I have to vote -0 as well. > > > > Chris > > > > > > -- Simon Pepping home page: http://www.leverkruid.nl

Re: Committing documentation

On Wed, Jul 28, 2004 at 01:24:22PM -0700, Clay Leeds wrote: > On Jul 28, 2004, at 11:51 AM, Simon Pepping wrote: > >On Sun, Jul 25, 2004 at 12:51:56PM -0700, Clay Leeds wrote: > >>As I understand it, you're primarily doing documentation that is more > >>developer an

Re: Building site with forrest

elease a new version). More > recently, I've had some success, but I'm currently working with the > forrest-dev list to get them resolved--and we've made progress[1] & > [1a]. I appreciate that that is not an easy problem to solve. > (More comments inline) >

Re: Committing documentation

is. Does this mandate a specific directory to commit the files into? Or shall I create a directory in src/documentation/content/xdocs? Or in src/documentation/content/? Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: (Copyright question) Re: Committing documentation

yright > > license to use, > > execute, prepare derivative works of, and > > distribute (internally > > and externally, in object code and, if included > > in your > > Contributions, source code form) your > > Contributions. Except for the > > rights granted to the Foundation in this > > paragraph, You reserve all > > right, title and interest in and to your > > Contributions. > > > > > > Christian > > > -- Simon Pepping home page: http://www.leverkruid.nl

Committing documentation

I am preparing my documentation for check-in into the repository. What would be a suitable place. A directory in src/documentation/content/xdocs? Would that be in the way of the forrest build of the web site? Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: fox validation

x27;s about 30 or so > validateChildNodes() left to be written--many of them > quite complex. Feel free to help out if you'd like! > > Glen > > --- "J.Pietschmann" <[EMAIL PROTECTED]> wrote: > > Simon Pepping wrote: > > > The code in Root sh

Building site with forrest

, or am I doing something wrong? Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

fox validation

. Even if it is true, it creates compatibility problems. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: SAXParserFactory vs. TransformerFactory (was: Re: cvs commit: ....)

javax.xml.transform. People with no experience in embedding transformations may find a SAXParser example easier to apply. That was my own situation until this thread. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

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

It is good to enable our own CLI and embedding apps to first construct the user agent with all desired features and then create a driver with it. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/examples/embedding/java/embedding ExampleFO2PDF.java

porarily in the example and committed it before > returning to the Transformer version. This way, we > have a working example should we ever need to document > this style (perhaps on a web page, so users are at > least aware of it) in the future. > > Glen > -- Simon Pepping home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/examples/embedding/java/embedding ExampleFO2PDF.java

n factory.newSAXParser().getXMLReader(); Why is having a transformer object in between better? Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Combined the AreaTree and FOTreeHandler (was: Re: cvs commit: etc.)

es help in comprehension. Communication may be a means of separating parts of an app from each other. And often it is worth the extra lines of code. Simon -- Simon Pepping home page: http://www.leverkruid.nl

Combined the AreaTree and FOTreeHandler (was: Re: cvs commit: etc.)

new episode of area tree building. Now the area tree activates itself, based on an event in the FO tree. I believe this change violates the separation between the FO tree and the area tree. I think that separation is a good idea and should be maintained. Regards, Simon -- Simon Pep

Re: adding fonts to fop applet

On Fri, Jul 09, 2004 at 03:05:11PM -0700, Glen Mazza wrote: > Thanks, Simon. Its good that we have people of your > skill on our team. Thanks for the compliment. Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: [PROPOSAL] API Changes

PI much as it is, in view of the fact that we do not yet have a final view on it. However we do it, we will go through two phases: implement the new layout, and implement a new API, and there will be a time between the two. I think moving to JAXP now is desirable, for all the reasons one follows a standard API. Note that the Xalan and other people call the javax.xml.transform part TrAX. AFAIK, javax.xml.parsers is also in JAXP. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Still need DOM Tree processing?

proach a report-generation task. I guess we should > keep it in then. I support that decision. It is one more entry point for apps. Of course they can fire off their own SAX events, but if they have a DOM tree and FOP does it for them, that is nice. Regards, Simon -- Simon Peppi

Re: Documentation finished

t; other former/current committers. That is not a problem. I never publish anything without a copyright holder. If it goes to FOP CVS and other contributions are merged, then the copyright holder is just changed, like with source code. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Java text geometry

hink there are Batik members here too? Perhaps > one of you could drop them a line... ExTeX, isn't that the name devised for NTS, but never used? Who are using that now? Is there development in that area? Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Documentation finished

. regarding FO trees and Layout system. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Re: Documentation finished

x27; in addition to the Title. I will see if I can customize the DocBook style sheets to do that. There are a few other things that may benefit from customization. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

Documentation finished

er of Docbook 4.2 XML files. Could this be part of the wiki? Or could it be in CVS? Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl

  1   2   >