Re: Bug 14290 strokeSVGText=false causes space characters to berendered incorrectly
Hi Karen, Welcome back. Well if it works it looks good to me but I'm no font expert. Could that also be applied to trunk? Be careful the style police might get onto you. Keiron. On Tue, 2002-11-19 at 23:38, Karen Lease wrote: Hi all (and especially Jeremias or other font experts), This bug seems to be due to the way we generate the 'loca' table in the embedded font subsets (CID fonts). In fact, it has offsets to the correct glyph descriptions, but the offsets are not in ascending order. Since it seems that the length of the glyph description is found by subtracting the offset to the glyph from the offset for the next glyph in the loca table, this does not work. For Acrobat, as long as there actually _is_ a glyph description, it seems to work anyway. However for space characters, there is no glyph. Acrobat thinks there is because of the offset, so it draws the glyph that _is_ stored at the offset. This only shows up with SVG text because it has embedded spaces. The spaces in normal text are generally turned into explicit offsets and not drawn as such. The attached diff fixes the bug; though there are perhaps more elegant ways to do it. Does anyone see anything wrong with this idea? If not, I'll commit asap. In fact, using this fix, xpdf now also works with embedded fonts, whereas before it produced garbage. Regards, Karen Lease (Lately very overworked) Senior Software Developer SPX Valley Forge Paris/Munich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Sample FO Documents
Hi Eliot, I presume there is a large number of large and complicated samples that would be a bit too much. They could be placed in bugzilla if not appropriate for cvs. We could then grab them and use when suitable. The idea of course is to work through and fix the limitations in FOP. Keiron. On Tue, 2002-11-19 at 15:53, W. Eliot Kimber wrote: As I mentioned in another forum, I have a fairly comprehensive set of samples, both contrived and realistic, that are available to any implemmentors. I'd be happy to provide these to the FOP team--just let me know who to send them to or where to upload them. These have been developed both as demos of using FO to do multi-language composition of technical manuals and as samples in service of a new FO course we're developing. The downside for FOP is that these examples were developed initially using XSL Formatter, which is the most feature complete implementation. That means that the samples and demos have not been tailored to work w/in FOP's current limitations. Cheers, Eliot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Xerces 2.2.1
It works with Xerces 2.2.1. I'll close all the bugs (Xalan FOP) marked as Invalid. Thanks, Bernard -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: 20 November, 2002 0:38 To: [EMAIL PROTECTED] Subject: Re: Xerces 2.2.1 Bernard, Ah, memory! Wonderful thing when it works. I must remember to read Proust again. I wanted to talk to you about this. I haven't yet followed up on your fix to this, so I am not sure how you handle it, but wouldn't the variable and the process be better as startDocumentAlreadySeen? Then you can skip the whole STARTDOCUMENT handler if the variable is true. Have you tried the original code with 2.2.1? Peter Bernard D'Have wrote: It's me. It is bug 14539 in Bugzilla. It's just that in you have a comment before the root element, the SAX startDocument is called two times. - This mail was sent through webmail.wanadoo.be - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
On Tue, 2002-11-19 at 16:57, Rhett Aultman wrote: I'm not sure how writing the thing to make two passes is more loop prone than making one pass, especially if each pass performs a different function. For example, what if the first pass was designed only to gather information about the proposed layout options and the second pass was the actual process of layout, getting the opportunity to make its decisions from on high with total knowlege? I can't really see what you could find out on a first pass that does not do some sort of layout. I suppose it is a question of what exactly we mean. Currently it sort of does more than one pass, but only the first pass reads the fo and sorts out most of the layout. When it is reset then it will reflow the inlines, lines and blocks. An idea I am thinking of is reseting based on change of page or ipd. So that it is possible to only reflow what is needed, the rest we a simply re-reading the current breaks and making a break decision from that. Yes, and I think that the system works pretty well for a lot of situations. I'm not suggesting that it get chucked to the weeds. A question this begs, though, is that is this design going to take us the whole way through? In your own email here you bring up two cases where a LM's decisions have to be dependant upon more than just its own children. Well it is hard to say really. But I will say that it is important to continue to publicly demonstrate progress. I am sure the current design has the potential to do more than the current simplistic situation, to me it is a question of how to do it cleanly. Also, this may seem like an issue only to me, but I our next layout system must be free of infinite loops. It is essential that enterprise users know their Tomcat or jBoss servers are not going to have to be restarted if some guy makes a screwup in his Servlet or MBean and accidentally triggers a special case in FOP that leads to a layout loop. A process for recognizing when a constraint must be lifted in order to ensure the document processes is necessary, and I think it was Victor (though maybe Peter...) who pointed out that such a process leads to another problem- if you lift a constraint in one place, you have effects on the layout of the entire document, too. In order to handle this problem, the entire layout system needs the ability to not only spot the issue but to select the best resolution for it and then layout according to that decision. I hate infinite loops just as much as the everyone else. I think that it is currently far less prone to the problem and I intend to continue to ensure it won't happen. I've spent a lot of mental energy over the last several days trying to come up with a solution, and the only one I've come up with thus far involves creating a tree of alternative layout choices. For an ideal document, there really isn't a tree. For less-than-ideal ones, there would be a branch of the tree at every place a violation occurs, and there decisions would branch off with possibilities of how to resolve the problem. If a decision creates even more woes, its branch would get deeper and deeper. Finding the ideal set of choices to make in resolving an issue then becomes a matter of simply finding the shortest branch in a tree. This is, in many ways, in parallel with the LayoutPlan approach previously mentioned. But, to do this, they layout system needs to start out with a certain base set of knowlege about the layout of the document, and to me this implies that multiple passes are needed. Maybe only one final layout pass is needed, and the current, tree-based layout mechanism would probably be a shoe in there. Once the high-level decisions are made, it should be easy for the present layout mechanism to follow them. Whatever the shape this takes, I still see a need for some forms of redesign of the current layout system, if for no reason other than I don't think that tweaks and special cases are enough to prevent the layout managers from getting caught in endless loops. As I've said before, I feel like I'm just spouting hoohah, so take this with a grain of salt, but I think more mechanisms are needed in the layout system than what's being offered are necessary, and I'd rather have a slow and complex but loop-free and complete LM than a fast and simple but loop-prone and incomplete one. The best thing I can say is: understand the issues and start doing it. I'm not saying that we shouldn't indeed make a complete tree of the document and decide the best breaks. I just don't think that enforcing that situation is a good idea when we could layout the first page when there is a force page break or no keeps. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
Hi Karen Well, I don't call myself a font expert, yet, though I'm working hard to get to Tore's level. I haven't had much contact with TrueType fonts, so I'm probably not the right person to answer your proposal but I think if it works it's ok. On 19.11.2002 23:38:21 Karen Lease wrote: Hi all (and especially Jeremias or other font experts), This bug seems to be due to the way we generate the 'loca' table in the embedded font subsets (CID fonts). In fact, it has offsets to the correct glyph descriptions, but the offsets are not in ascending order. Since it seems that the length of the glyph description is found by subtracting the offset to the glyph from the offset for the next glyph in the loca table, this does not work. For Acrobat, as long as there actually _is_ a glyph description, it seems to work anyway. However for space characters, there is no glyph. Acrobat thinks there is because of the offset, so it draws the glyph that _is_ stored at the offset. This only shows up with SVG text because it has embedded spaces. The spaces in normal text are generally turned into explicit offsets and not drawn as such. The attached diff fixes the bug; though there are perhaps more elegant ways to do it. Does anyone see anything wrong with this idea? If not, I'll commit asap. Please do. We can always change again if it doesn't work out. The only other idea that's coming to my mind is to enhance the TextPainter so it doesn't paint spaces but also just advanced the current position. But that only complicates the code there and I don't know if it's worth it. In fact, using this fix, xpdf now also works with embedded fonts, whereas before it produced garbage. I'd like to point out that IMO it's important to separate TrueType and Type 1 support where embedded fonts are concerned. I'm pretty sure I have identified a problem with embedded Type 1 fonts that leads to errors on certain PDF and PostScript RIP engines. I don't know about xpdf. I intend to fix that very soon now. Regards, Karen Lease (Lately very overworked) Senior Software Developer SPX Valley Forge Paris/Munich Have you already signed up for the germany-based committers meeting? :-) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14702] New: - [PATCH] new developer font doc
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=14702. 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=14702 [PATCH] new developer font doc Summary: [PATCH] new developer font doc Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] There are two attached files: 1. a new xdocs/dev/fonts.xml file to store some useful links and information about font work. This is a distillation of some of the email threads on this topic. The implementation section is mostly my own vision of where to go, and is certainly open for debate/discussion. 2. a small patch to the xdocs/dev/book.xml file to recognize this new document. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14702] - [PATCH] new developer font doc
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=14702. 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=14702 [PATCH] new developer font doc --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 09:19 --- Created an attachment (id=3899) new xdocs/dev/fonts.xml file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14702] - [PATCH] new developer font doc
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=14702. 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=14702 [PATCH] new developer font doc --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 09:20 --- Created an attachment (id=3900) patch file to acknowledge new fonts.xml document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[VOTE] Victor as committer
Hi Developers, I propose we have a vote for Victor to become a committer. Plenty of eagerness shown already and I am sure he will do lots more for the project. Here's my vote: +1 Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation cocoon.diff
keiron 2002/11/20 01:24:07
Modified:src/documentation cocoon.diff
Log:
set creator as cocoon
Revision ChangesPath
1.2 +7 -6 xml-fop/src/documentation/cocoon.diff
Index: cocoon.diff
===
RCS file: /home/cvs/xml-fop/src/documentation/cocoon.diff,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- cocoon.diff 12 Nov 2002 09:12:36 - 1.1
+++ cocoon.diff 20 Nov 2002 09:24:07 - 1.2
@@ -4,7 +4,7 @@
retrieving revision 1.3
diff -u -r1.3 FOPSerializer.java
--- src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java 23 Sep
2002 03:30:44 - 1.3
-+++ src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java 8 Nov
2002 12:06:40 -
src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java 20 Nov
2002 07:53:48 -
@@ -62,18 +62,28 @@
import org.apache.cocoon.components.url.URLFactory;
import org.apache.cocoon.util.ClassUtils;
@@ -113,10 +113,11 @@
// Get the mime type.
this.mimetype = conf.getAttribute(mime-type);
-@@ -232,6 +207,21 @@
+@@ -232,6 +207,22 @@
+ no renderer was specified in the sitemap configuration.
);
}
++this.renderer.setCreator(Cocoon);
+
+userAgent = new FOUserAgent();
+userAgent.enableLogging(this.logger);
@@ -135,7 +136,7 @@
}
/**
-@@ -241,27 +231,40 @@
+@@ -241,27 +232,40 @@
return mimetype;
}
@@ -192,7 +193,7 @@
this.driver.setOutputStream(out);
setContentHandler(this.driver.getContentHandler());
}
-@@ -295,8 +298,7 @@
+@@ -295,8 +299,7 @@
*/
public void recycle() {
super.recycle();
@@ -202,7 +203,7 @@
}
/**
-@@ -306,3 +308,4 @@
+@@ -306,3 +309,4 @@
return this.setContentLength;
}
}
@@ -213,7 +214,7 @@
retrieving revision 1.24
diff -u -r1.24 AbstractProcessingPipeline.java
--- src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java
11 Oct 2002 08:36:30 - 1.24
-+++ src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java
8 Nov 2002 12:06:40 -
src/java/org/apache/cocoon/components/pipeline/AbstractProcessingPipeline.java
20 Nov 2002 07:53:48 -
@@ -62,6 +62,7 @@
import org.apache.cocoon.ConnectionResetException;
import org.apache.cocoon.ProcessingException;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14702] - [PATCH] new developer font doc
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=14702. 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=14702 [PATCH] new developer font doc --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 09:26 --- Created an attachment (id=3901) resubmitting fonts.xml wrapped in a tar file due to problems opening XML files in IE -- extract in src/documentation/content directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Victor as committer
I fully agree: +1 On 20.11.2002 10:23:11 Keiron Liddle wrote: Hi Developers, I propose we have a vote for Victor to become a committer. Plenty of eagerness shown already and I am sure he will do lots more for the project. Here's my vote: +1 Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] changes to bugs.xml doc
Keiron Liddle wrote: I'm not really sure what is the source of the problem. A few of the patches had hunks failing and some worked with fuzz offsets. One error meesage I got was that it couldn't find the character on line 9, so I went to line 9 and found the character, of course it was really looking for . Well, that was probably my bad for not using the universal diff format (I need to start doing these at 2pm instead of 2am). The behavior I saw a few minutes ago makes me think that IE may be getting confused by the fact that these patches are for XML files, and that it is treating them as such instead of as plain old text files. Maybe archiving the patch might work better. I'll try to remember to do that. Anyway there are better ways of solving this problem. I do not understand. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs/dev fonts.xml book.xml
keiron 2002/11/20 01:55:49 Modified:src/documentation/content/xdocs/dev book.xml Added: src/documentation/content/xdocs/dev fonts.xml Log: new dev fonts.xml file to store some useful links and information about font work Submitted By: Victor Mote [EMAIL PROTECTED] Revision ChangesPath 1.6 +1 -0 xml-fop/src/documentation/content/xdocs/dev/book.xml Index: book.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/dev/book.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- book.xml 19 Nov 2002 07:57:29 - 1.5 +++ book.xml 20 Nov 2002 09:55:49 - 1.6 @@ -21,6 +21,7 @@ /menu menu label=Extras menu-item label=SVG href=svg.html/ + menu-item label=Fonts href=fonts.html/ /menu menu label=Developers menu-item label=Design href=../design/index.html/ 1.1 xml-fop/src/documentation/content/xdocs/dev/fonts.xml Index: fonts.xml === ?xml version=1.0 standalone=no? !-- $Id: fonts.xml,v 1.1 2002/11/20 09:55:49 keiron Exp $ -- !DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.1//EN http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd; document header titleFonts (Developer Information)/title /header body section titleGoals/title ul lirefactor existing font logic for better clarity and to reduce duplication/li liparse registered font metric information on-the-fly (to make sure most up-to-date parsing is used??)/li liresolve whether the FontBBox, StemV, and ItalicAngle font metric information is important or not -- if so, parse the .pfb file to extract it when building the FOP xml metric file/li lihandle fonts registered at the operating system (through AWT)/li liadd support for parsing OpenType fonts/li /ul /section section titleIssues/title ul liWhy are we using our own font metric parsing and registration system, instead of the AWT system provided as part of Java? ul liAnswer 1: Many of our customers use FOP in a so-called headless server environment -- that is, the operating system is operating in character mode, with no concept of a graphical environment. We need some mechanism of allowing these environments to get font information./li liAnswer 2: At some level, we don't yet fully trust AWT to handle fonts correctly. There are still unresolved discrepancies between the two systems./li /ul /li /ul /section section titleImplementation/title pThere are two main font functions needed within FOP:/p ul liprovision of a font object to be used in layout/li liembedding of a font file in output (such as PDF)/li /ul pFor the first of these, we will implement something along the lines of a Facade Structural Pattern to hide the differences between the various font types and font sources from the rest of the system. Public classes will consist of TypeFaceFamily, TypeFace, and Font. (TypeFace roughly corresponds to the contents of a normal font file, while Font is a general typeface implemented at a specific point size, and perhaps with other specific parameters). When another part of FOP requests a font object, existing font objects will be checked first, and an appropriate one returned if possible. If not, the Font logic should resolve the TypeFace and TypeFaceFamily if possible, create a Font object, and return it./p /section section titleResources/title section titleType 1 Fonts/title ul lilink href=http://partners.adobe.com/asn/developer/pdfs/tn/T1_SPEC.PDF;Adobe Type 1 Font Format/link/li liAccording to the Adobe web site, the documentation for the font metrics files (.pfm = printer font metrics) is written and controlled by Microsoft, since it is actually a workaround to allow Type 1 fonts to be used on a GUI screen in Windows. However, the document does not appear to be on the Microsoft web site. The best resource for this information is link href=http://partners.adobe.com/asn/developer/pdfs/tn/5178.PFM.pdf;Adobe Technical Note #5178/link: Building PFM Files for Postscript-Language CJK Fonts/li liFOP does not currently use the Adobe Font Metrics file, but the specification can be found in link href=http://partners.adobe.com/asn/developer/pdfs/tn/5004.AFM_Spec.pdf;Adobe Technical Note #5004/link: Adobe Font Metrics File Format Specification/li lilink
Re: [VOTE] Victor as committer
Keiron Liddle wrote: I propose we have a vote for Victor to become a committer. Plenty of eagerness shown already and I am sure he will do lots more for the project. Here's my vote: +1 +1 -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
XML area tree question
Hello, in this thread (http://marc.theaimsgroup.com/?l=fop-userm=103227363003594w=2) I asked whether you could use FOP extensions to get the pagination back into the source XML document. Back then I had also thought about parsing the area tree debugging output to achieve this. It seems like an ugly hack (maybe writing an element id into the header of each page) but it could work. Now my question is: Will this XML representation be continued in future FOP versions? Will it remain unchanged? (at least no major modifications) Kind regards! -- Matthias Brunner [EMAIL PROTECTED] PGP FP 7862 32B3 3B75 292A F76F 5042 8587 21AB 5B89 D501 Check out http://blumenstrasse.vol.at/~mb/gpgkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML area tree question
On Wed, 2002-11-20 at 11:03, Matthias Brunner wrote: Hello, in this thread (http://marc.theaimsgroup.com/?l=fop-userm=103227363003594w=2) I asked whether you could use FOP extensions to get the pagination back into the source XML document. Back then I had also thought about parsing the area tree debugging output to achieve this. It seems like an ugly hack (maybe writing an element id into the header of each page) but it could work. Now my question is: Will this XML representation be continued in future FOP versions? Will it remain unchanged? (at least no major modifications) The XML representation has already changed in cvs. It is a major change due to a major change with the area tree. The xml is a sort of a representation of the area tree that is normally handled by the renderers. So it is likely to continue but has been changed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14702] - [PATCH] new developer font doc
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=14702. 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=14702 [PATCH] new developer font doc [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 10:28 --- Committed to cvs, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML area tree question
On Wednesday 20 November 2002 11:26, Keiron Liddle wrote: The XML representation has already changed in cvs. It is a major change due to a major change with the area tree. The xml is a sort of a representation of the area tree that is normally handled by the renderers. Do these changes depend on changes of the W3C standard? Or are they completely programme-internal? With without major changes I mean that there should be still a Page element, a LineArea element and a WordArea element. Not anything more specific. -- Matthias Brunner [EMAIL PROTECTED] PGP FP 7862 32B3 3B75 292A F76F 5042 8587 21AB 5B89 D501 Check out http://blumenstrasse.vol.at/~mb/gpgkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML area tree question
On Wed, 2002-11-20 at 11:33, Matthias Brunner wrote: On Wednesday 20 November 2002 11:26, Keiron Liddle wrote: The XML representation has already changed in cvs. It is a major change due to a major change with the area tree. The xml is a sort of a representation of the area tree that is normally handled by the renderers. Do these changes depend on changes of the W3C standard? Or are they completely programme-internal? Completely internal. Actually the new structure is much closer to the area tree described in the spec. With without major changes I mean that there should be still a Page element, a LineArea element and a WordArea element. Not anything more specific. Those sort of things will still exist. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Sample FO Documents
At 14:53 19/11/02, W. Eliot Kimber wrote: As I mentioned in another forum, I have a fairly comprehensive set of samples, both contrived and realistic, that are available to any implemmentors. I'd be happy to provide these to the FOP team-- If no one else has the time then I will take these and try to incorporate them into a subdirectory of docs/examples I am not a committer - but supposedly look after the FAQ http://www.OWAL.co.uk/cgi-bin/fopfaq.cgi (I don't personally have lots of time as I am doing publicity for myself in London looking for XML publishing work - but this sounds so important to help with the uptake of FOP that I'll make the time). I don't really want to change the samples if they use XSL:FO features not implemented by FOP, but I may move them into a separate not yet implemented directory. Are the XSL:FO files self documenting? do they say in the generated pdf what should appear? Alex McLintock Openweb Analysts Ltd, London. Software For Complex Websites http://www.OWAL.co.uk/ Open Source Software Companies please register here http://www.OWAL.co.uk/oss_support/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Victor as committer
On Wednesday 20 November 2002 10:23, Keiron Liddle wrote: Plenty of eagerness shown already and I am sure he will do lots more for the project. Yes, agreed, here's my +1 -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Sample FO Documents
W. Eliot Kimber wrote: As I mentioned in another forum, I have a fairly comprehensive set of samples, both contrived and realistic, that are available to any implemmentors. I'd be happy to provide these to the FOP team--just let me know who to send them to or where to upload them. I believe the best place is ISOGEN site itself (afair you said there is a plan to make them publicly accessible there). Having such samples is extremely important, but as we all understand FOP is just not ready for them yet. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Victor as committer
+1. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: November 20, 2002 5:23 AM To: FOP Subject: [VOTE] Victor as committer Hi Developers, I propose we have a vote for Victor to become a committer. Plenty of eagerness shown already and I am sure he will do lots more for the project. Here's my vote: +1 Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Victor as committer
Keiron Liddle wrote: Hi Developers, I propose we have a vote for Victor to become a committer. +1 Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Sample FO Documents
Oleg Tkachenko wrote: W. Eliot Kimber wrote: As I mentioned in another forum, I have a fairly comprehensive set of samples, both contrived and realistic, that are available to any implemmentors. I'd be happy to provide these to the FOP team--just let me know who to send them to or where to upload them. I believe the best place is ISOGEN site itself (afair you said there is a plan to make them publicly accessible there). Having such samples is extremely important, but as we all understand FOP is just not ready for them yet. Oleg, Eliot, I think this is probably a good idea. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7241] - keep-with-previous, keep-with-next only working on the first page break
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=7241. 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=7241 keep-with-previous, keep-with-next only working on the first page break --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 13:18 --- Provide an example please (fo document, add it as attachment). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Style guide (update)
Hi there I've finally finished the first draft for our style guide. I hope it's a good start and I got a good mix from the discussions together. Please review, change and comment. There were a lot of suggestions especially from Jörg. I've summarized most of them under common sense but feel free to expand if you feel it's necessary. http://codeconsult.ch/wiki/index.php/FopDevelopersStyleGuide Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12864] - Incorrect behaviour for multiple columns on page
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=12864. 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=12864 Incorrect behaviour for multiple columns on page --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 14:26 --- Provide an example please, I cannot reproduce the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (update)
At 09:15 AM 11/20/02, you wrote:
Please
review, change and comment.
re TBD section
1. strongy encourage m_ for instance variables, if only to eliminate
having to qualify similarly named assignments like
this.variable = variable
2. suggest s_ for statics and allow ALL_CAPS (underscores tolerated for
this usage only)
for static final (ie literals)
3. Sadly I ~don't~ like the Sun style for brace placement, but I guess I
learned in the
Fortran and PL/1 era. Guess I'm in the minority on that point ;-)
if (blahBlah){
line ;
line
} else {
line ;
line ;
}
vs
if (blahBlah)
{
line ;
line ;
}
else
{
line ;
line ;
}
4. I prefer Petzold's convention of placing a space before the terminating
semicolon (or even colon) which I believe he did for readability in
books,
and which I do for readability by my senior, crt-weary, eyes.
' Best,
-Ralph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (update)
Oh, but congratulations to all the contributors for taking this on and getting somewhere with it At 09:15 AM 11/20/02, you wrote: Hi there I've finally finished the first draft for our style guide. I hope it's a good start and I got a good mix from the discussions together. Please review, change and comment. There were a lot of suggestions especially from Jörg. I've summarized most of them under common sense but feel free to expand if you feel it's necessary. http://codeconsult.ch/wiki/index.php/FopDevelopersStyleGuide Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance In theory, there is no difference between theory and practice, but in practice there is. (Someone wrote that, but I don't know who.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Style guide (update)
Responses below. -Original Message- From: Ralph LaChance [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 9:54 AM To: [EMAIL PROTECTED] Subject: Re: Style guide (update) re TBD section 1. strongy encourage m_ for instance variables, if only to eliminate having to qualify similarly named assignments like this.variable = variable 2. suggest s_ for statics and allow ALL_CAPS (underscores tolerated for this usage only) for static final (ie literals) I think that we've talked about most of these before and decided that the prefix notation ala m_ and s_ isn't worth it. Personally, in all the lines of code I've slung thus far in my life, the issue of this.variable = variable hasn't ever come up, whereas the problem of people's prefixes reducing the ease with which I read code has. I do agree with ALL_CAPS for static finals, though. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML area tree question
Matthias Brunner wrote: Hello, in this thread (http://marc.theaimsgroup.com/?l=fop-userm=103227363003594w=2) I asked whether you could use FOP extensions to get the pagination back into the source XML document. There was some discussion of this requirement on one of the FO lists not too long ago. It's a general requirement of all FO implementations. My suggestion was to enable the arbitrary output of side files that contain whatever information the style sheet writer wants to output. XEP already provides a generalized output mechanism that goes some way toward satisfying this requirement, although I would like a more general solution that lets me put essentially arbitrary markup in the output, but with the ability to refer to artifacts of the paginated result document (page numbers, marker values, mappings of input elements to the pages they occurred on, etc.). Cheers, Eliot -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (update)
I've added your proposals to the Wiki page. I'd rather you modified the
page yourself, that's what the Wiki is for. Thanks.
Some comments from me anyway...
On 20.11.2002 15:54:13 Ralph LaChance wrote:
At 09:15 AM 11/20/02, you wrote:
Please
review, change and comment.
re TBD section
1. strongy encourage m_ for instance variables, if only to eliminate
having to qualify similarly named assignments like
this.variable = variable
I've added my vote for this to the Wiki. Could all viewers also add
their votes especially in the TBD section? That will help us identify
what is supported and what not. If you don't like any of the other
points also put your vote at the end (Example jm-1).
2. suggest s_ for statics and allow ALL_CAPS (underscores tolerated for
this usage only)
for static final (ie literals)
I'd like to avoid s_ because statics should be eliminated where possible.
We've used statics too much in the past. But I agree on the rest.
3. Sadly I ~don't~ like the Sun style for brace placement, but I guess I
learned in the
Fortran and PL/1 era. Guess I'm in the minority on that point ;-)
Mmm, yes, I think so. No support from me. :-)
if (blahBlah){
line ;
line
} else {
line ;
line ;
}
vs
if (blahBlah)
{
line ;
line ;
}
else
{
line ;
line ;
}
4. I prefer Petzold's convention of placing a space before the terminating
semicolon (or even colon) which I believe he did for readability in
books,
and which I do for readability by my senior, crt-weary, eyes.
I don't like that either.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
Responses Below. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 3:38 AM To: FOP Subject: RE: Getting breaks: revisited I can't really see what you could find out on a first pass that does not do some sort of layout. I suppose it is a question of what exactly we mean. Currently it sort of does more than one pass, but only the first pass reads the fo and sorts out most of the layout. When it is reset then it will reflow the inlines, lines and blocks. Well, let's take the idea that we were starting at square one with respect to LM development. One possibly strategy would be to make a pass over all of the objects to be laid out, visiting each one and, while not laying it out, gathering information about what explicit constraints each one is under. Armed with this information, a layout system could create a plan for reconciling all constraints, even dropping constraints if they were in conflict. This is essentially the same thing as the LayoutPlan concept mentioned by other developers. The first pass isn't really a layout pass but a sort of scouting out issues relevant to the layout process. I could see how this sort of scouting ahead could help resolve even some of the issues you mentioned, such as footnotes throwing monkey wrenches in the system. Maybe this is what you mean when you say the first pass reads the fo and sorts out most of the layout, and we just have our wires crossed. An idea I am thinking of is reseting based on change of page or ipd. So that it is possible to only reflow what is needed, the rest we a simply re-reading the current breaks and making a break decision from that. The problem, as I see it, is that those breaks aren't always trustworthy. My stripped down FO document in bug #8778 had the same problem in HEAD that it does in maintenance (at least, it did a few weeks ago). A problem is in the cases where the LM offers breaks where it thinks they should best be put, but choosing the breaks in that fashion prevents the content from actually getting laid out anywhere. A few weeks ago, you expressed disbelief that this was happening, but I know what I was seeing and I know what I did to terminate the loop, and I offered to show you the experiment I'd run at my desk. Maybe things have been shored up since then, since that was weeks ago, in which case my point is moot. Well it is hard to say really. But I will say that it is important to continue to publicly demonstrate progress. I am sure the current design has the potential to do more than the current simplistic situation, to me it is a question of how to do it cleanly. Right...I'm agreeing wholeheartedly there, but I'm asking about some issues that I don't see being addressed in the layout system in HEAD. You seem very steadfast in the belief that the design for layout in HEAD, as it is, is all that we need, and so I'm curious as to how you think it will address issues like the one I'm bringing up. If it won't, then what I am proposing is that the layout system as it is in HEAD is a critical tool in a much larger process of layout and that more layout tools are needed to work with it. I hate infinite loops just as much as the everyone else. I think that it is currently far less prone to the problem and I intend to continue to ensure it won't happen. The very simple loop-causing document I put in bug #8778 seems to me to be a fundamental demonstration of how constraints in conflict create loops. A simple case like this one shows nearly identical behavior between maintenance and HEAD. Though it's much easier in HEAD to code an LM to spot the characteristic lack of progress and try to break out of the cycle, I don't see how this can be used to address the real issue- the fact that two disparite constraints contradict each other. The best thing I can say is: understand the issues and start doing it. I may be green, but I did spot some of this a couple weeks ago, and it went mostly unnoticed. While writing this email, I downloaded another CVS snapshot and the super-simple test document from bug #8778, which is probably the simplest of all the i-loop cases, and ran it again...it's the same thing I saw when I last brought this up. I'm not saying that we shouldn't indeed make a complete tree of the document and decide the best breaks. I just don't think that enforcing that situation is a good idea when we could layout the first page when there is a force page break or no keeps. Well, maybe there's a balance to be struck, but my test document on bug #8778 has no keeps and, despite the space-before being enough to nudge content into spilling off the page and triggering a break before the block, is incredibly simple, yet the LM system is skewered by the contradicting complaints. I guess what I'm asking is what thoughts you have on solving this issue in a general fashion, since I can definitely see that, if a simple
org.apache.fop.viewer.PreviewDialog
Hi all. I am using FOP with my application and for better performance I did a singleton which have an instance of the Driver, Renderer and etc. It seens working fine, each time before I run a new report I am reset the Driver. But I found problems with PreviewDialog it seems that dialog didn't release all resources and next time when I am creating it shows me a picture from the previous report. No exceptions was reported but in the log file I got: [DEBUG] Memory use is indicative; no GC was performed [DEBUG] These figures should not be used comparatively Am I doing something wrong ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: org.apache.fop.viewer.PreviewDialog
IvanLatysh wrote: Hi all. I am using FOP with my application and for better performance I did a singleton which have an instance of the Driver, Renderer and etc. It seens working fine, each time before I run a new report I am reset the Driver. But I found problems with PreviewDialog it seems that dialog didn't release all resources and next time when I am creating it shows me a picture from the previous report. No exceptions was reported but in the log file I got: [DEBUG] Memory use is indicative; no GC was performed [DEBUG] These figures should not be used comparatively Am I doing something wrong ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: org.apache.fop.viewer.PreviewDialog
IvanLatysh wrote: I am using FOP with my application and for better performance I did a singleton which have an instance of the Driver, Renderer and etc. It seens working fine, each time before I run a new report I am reset the Driver. But I found problems with PreviewDialog it seems that dialog didn't release all resources and next time when I am creating it shows me a picture from the previous report. Just curious - why you recreate the dialog? You can use 1 instance and to show/hide it by setVisible(boolean) method. But you maight be right, because PreviewDialog is not designed to be reusable and recreatable. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: org.apache.fop.viewer.PreviewDialog
Oleg Tkachenko wrote: Just curious - why you recreate the dialog? You can use 1 instance and to show/hide it by setVisible(boolean) method. But you maight be right, because PreviewDialog is not designed to be reusable and recreatable. Anyway, look at reload functionality, it solves the same problem by cleaning up renderer, internal counters, page image etc. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML area tree question
W. Eliot Kimber wrote: There was some discussion of this requirement on one of the FO lists not too long ago. It's a general requirement of all FO implementations. My suggestion was to enable the arbitrary output of side files that contain whatever information the style sheet writer wants to output. XEP already provides a generalized output mechanism that goes some way toward satisfying this requirement, although I would like a more general solution that lets me put essentially arbitrary markup in the output, but with the ability to refer to artifacts of the paginated result document (page numbers, marker values, mappings of input elements to the pages they occurred on, etc.). Yes, that sounds great. Somebody have to design spec of it :) Apart from this: may be it's time to establish exsl-fo community to define common crossformatter extensions like exslt.org does for xslt? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML area tree question
Great idea. And let's try to feed those back to the XSL:FO WG. Nikolai, are you listening in? What do you think? On 20.11.2002 17:16:13 Oleg Tkachenko wrote: Apart from this: may be it's time to establish exsl-fo community to define common crossformatter extensions like exslt.org does for xslt? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML area tree question
Oleg Tkachenko wrote: Yes, that sounds great. Somebody have to design spec of it :) Apart from this: may be it's time to establish exsl-fo community to define common crossformatter extensions like exslt.org does for xslt? Sounds like it. I hadn't done this yet because I got some conflicting responses and I've been swamped with other work. I'll submit a Sourceforge application for the project as soon as I get a chance. Cheers, E. -- W. Eliot Kimber, [EMAIL PROTECTED] Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (update)
On Wednesday 20 November 2002 15:15, Jeremias Maerki wrote: . . .I've finally finished the first draft for our style guide... Thanks! I voted -1 on most TBD stuff, braces and spaces are not really important IMHO and I think it's good that the style guide stays as small as possible. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML area tree question
Jeremias Maerki wrote: Great idea. And let's try to feed those back to the XSL:FO WG. Nikolai, are you listening in? What do you think? xsl-fo@w3 or xsl-fo@yahoo probably is a better place for such efforts as I presume not all fo-formatter developers review fop-dev list. But as for feedback - don't worry, Eliot will persuade them all to participate :) -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XML area tree question
I'm sure Nikolai listens in. :-) But you're right, of course. On 20.11.2002 18:17:41 Oleg Tkachenko wrote: Jeremias Maerki wrote: Great idea. And let's try to feed those back to the XSL:FO WG. Nikolai, are you listening in? What do you think? xsl-fo@w3 or xsl-fo@yahoo probably is a better place for such efforts as I presume not all fo-formatter developers review fop-dev list. But as for feedback - don't worry, Eliot will persuade them all to participate :) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Victor as committer
Do inactive committers get to vote? I noticed that I had been placed on the inactive list a while back (shame on me). If so... +1 Art (hope to contribute again one of these days...) -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 4:23 AM To: FOP Subject: [VOTE] Victor as committer Hi Developers, I propose we have a vote for Victor to become a committer. Plenty of eagerness shown already and I am sure he will do lots more for the project. Here's my vote: +1 Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Victor as committer
I thought everyone was allowed to use a vote to express their opinion. If I've gravely mistaken this, then I'll stop voting. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 2:03 PM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Victor as committer Do inactive committers get to vote? I noticed that I had been placed on the inactive list a while back (shame on me). If so... +1 Art (hope to contribute again one of these days...) -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 4:23 AM To: FOP Subject: [VOTE] Victor as committer Hi Developers, I propose we have a vote for Victor to become a committer. Plenty of eagerness shown already and I am sure he will do lots more for the project. Here's my vote: +1 Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Victor as committer
Hi, I joined this list recently. I don't know anything about committer. Can someone let me know about committer? Thanks, Venkat -Original Message- From: Rhett Aultman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 2:12 PM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Victor as committer I thought everyone was allowed to use a vote to express their opinion. If I've gravely mistaken this, then I'll stop voting. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 2:03 PM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Victor as committer Do inactive committers get to vote? I noticed that I had been placed on the inactive list a while back (shame on me). If so... +1 Art (hope to contribute again one of these days...) -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 4:23 AM To: FOP Subject: [VOTE] Victor as committer Hi Developers, I propose we have a vote for Victor to become a committer. Plenty of eagerness shown already and I am sure he will do lots more for the project. Here's my vote: +1 Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Victor as committer
Venkata Rao Nadella wrote: Hi, I joined this list recently. I don't know anything about committer. Can someone let me know about committer? http://incubator.apache.org/drafts/glossary.html http://jakarta.apache.org/site/roles.html -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Victor as committer
Nicola Ken Barozzi wrote: I joined this list recently. I don't know anything about committer. Can someone let me know about committer? http://incubator.apache.org/drafts/glossary.html http://jakarta.apache.org/site/roles.html One more http://www.apache.org/foundation/contributing.html -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Victor as committer
Ok, I guess that answers my question. Sorry I was too lazy to look that up on my own. So my understanding is that only committers may vote, as per: A Committer has write access to the source code repository and gains voting rights allowing them to affect the future of the subproject. Putting this with the following: At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for 6 months or more may lose their status as a Committer. Getting access back is as simple as re-requesting it on the project's Developer mailing list I assume that being inactive means that I have lost my status as a committer and hence may not vote. So, hopefully one of these days (I have no idea when) I will again be able to contribute to FOP and re-attain committer status. At the moment, I am not actively working with FOP at work, but we are still using it (actually a version from a long while back - around the last time I contributed anything). The good thing is that I have not been called in to resolve any problems with FOP, the bad thing is that this is probably largely because of the limited use case. I hope in the future to expand this, which will likely entail some contributions to FOP. Or maybe by then my efforts will not be necessary - this would also be cool, although a bit disappointing in that I was not a part of it... Art (inactive) -Original Message- From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 2:18 PM To: [EMAIL PROTECTED] Subject: Re: [VOTE] Victor as committer Venkata Rao Nadella wrote: Hi, I joined this list recently. I don't know anything about committer. Can someone let me know about committer? http://incubator.apache.org/drafts/glossary.html http://jakarta.apache.org/site/roles.html -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bug 14290 strokeSVGText=false causes space characters to be rendered incorrectly
Hi Keiron, Feels good to do a little FOP :-) It's mostly work-related right now which explains why I'm hacking around in the maintenance branch. But it's better than nothing. I think this particular patch should work in trunk too, assuming no major differences in the embedding logic. I'll look into it. -Karen Keiron Liddle wrote: Hi Karen, Welcome back. Well if it works it looks good to me but I'm no font expert. Could that also be applied to trunk? Be careful the style police might get onto you. Keiron. On Tue, 2002-11-19 at 23:38, Karen Lease wrote: Hi all (and especially Jeremias or other font experts), This bug seems to be due to the way we generate the 'loca' table in the embedded font subsets (CID fonts). In fact, it has offsets to the correct glyph descriptions, but the offsets are not in ascending order. Since it seems that the length of the glyph description is found by subtracting the offset to the glyph from the offset for the next glyph in the loca table, this does not work. For Acrobat, as long as there actually _is_ a glyph description, it seems to work anyway. However for space characters, there is no glyph. Acrobat thinks there is because of the offset, so it draws the glyph that _is_ stored at the offset. This only shows up with SVG text because it has embedded spaces. The spaces in normal text are generally turned into explicit offsets and not drawn as such. The attached diff fixes the bug; though there are perhaps more elegant ways to do it. Does anyone see anything wrong with this idea? If not, I'll commit asap. In fact, using this fix, xpdf now also works with embedded fonts, whereas before it produced garbage. Regards, Karen Lease (Lately very overworked) Senior Software Developer SPX Valley Forge Paris/Munich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14489] - [PATCH] small workaround for outputHeader called two times
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=14489. 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=14489 [PATCH] small workaround for outputHeader called two times [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 22:17 --- The bug was in Xerces which calls SAX comments() before startDocument() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Victor as committer
Realistically I should be considered inactive myself. Thanks for bringing this up, Art. I just happen to have a brutal workload at the moment and I don't see it lessening in the next 4 months, minimum. It's fun stuff - I love it - but at the end of a workday I can't stand to look at code much, and same goes for weekends. I am not disinterested in Fop and will attempt to continue providing input. I haven't stopped monitoring the lists. But until such a time as I can contribute code I should be considered inactive. Arved -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: November 20, 2002 3:43 PM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Victor as committer Ok, I guess that answers my question. Sorry I was too lazy to look that up on my own. So my understanding is that only committers may vote, as per: A Committer has write access to the source code repository and gains voting rights allowing them to affect the future of the subproject. Putting this with the following: At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for 6 months or more may lose their status as a Committer. Getting access back is as simple as re-requesting it on the project's Developer mailing list I assume that being inactive means that I have lost my status as a committer and hence may not vote. So, hopefully one of these days (I have no idea when) I will again be able to contribute to FOP and re-attain committer status. At the moment, I am not actively working with FOP at work, but we are still using it (actually a version from a long while back - around the last time I contributed anything). The good thing is that I have not been called in to resolve any problems with FOP, the bad thing is that this is probably largely because of the limited use case. I hope in the future to expand this, which will likely entail some contributions to FOP. Or maybe by then my efforts will not be necessary - this would also be cool, although a bit disappointing in that I was not a part of it... Art (inactive) -Original Message- From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 2:18 PM To: [EMAIL PROTECTED] Subject: Re: [VOTE] Victor as committer Venkata Rao Nadella wrote: Hi, I joined this list recently. I don't know anything about committer. Can someone let me know about committer? http://incubator.apache.org/drafts/glossary.html http://jakarta.apache.org/site/roles.html -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: fo validation issue
Oleg Tkachenko wrote:
I like pull parsing model in general, but how do you manage with not
such strict content model as fo:root have, e.g. fo:block with
(#PCDATA|%inline;|%block;)* ?
Oleg,
How about:
/**
* Expect that the next element will be a STARTELEMENT for one of the
* flow objects which are members of (#PCDATA|%inline;|%block;) from
* b6.2 Formatting Object Content/b, including out-of-line flow
* objects which may occur except as descendants of out-of-line
* formatting objects. White space is retained, and
* will appear as #PCDATA, i.e., as an instance of FoCharacters.
* @return the ttFoXMLEvent/tt found. If any other events are
* encountered return ttnull/tt.
*/
public FoXMLEvent expectPcdataOrInlineOrBlock()
throws FOPException, UnexpectedStartElementException
{
FoXMLEvent ev = expectStartElement
(FObjectSets.normalPcdataBlockInlineSet,
XMLEvent.RETAIN_W_SPACE);
if (ev == null)
ev = expectCharacters();
return ev;
}
/**
* Expect that the next element will be a STARTELEMENT for one of the
* flow objects which are members of (#PCDATA|%inline;|%block;) from
* b6.2 Formatting Object Content/b, excluding out-of-line flow
* objects which may not occur as descendants of out-of-line formatting
* objects. White space is retained, and
* will appear as #PCDATA, i.e, as an instance of FoCharacters.
* @return the ttFoXMLEvent/tt found. If any other events are
* encountered return ttnull/tt.
*/
public FoXMLEvent expectOutOfLinePcdataOrInlineOrBlock()
throws FOPException, UnexpectedStartElementException
{
FoXMLEvent ev = expectStartElement
(FObjectSets.outOfLinePcdataBlockInlineSet,
XMLEvent.RETAIN_W_SPACE);
if (ev == null)
ev = expectCharacters();
return ev;
}
Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
Lord, to whom shall we go?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Alt-Design status: XML handling
Fop-devs,
Here is a update on the front-end of alt-design, for those of you who
may not be aware of what I have been doing. Attached is a broad
overview diagram of the approach I have taken to XML parsing and FO tree
building. I had been somewhat apprehensive about this approach, not
because I thought it was in any way wrong, but because I seemed to be
taking a very isolated path. My motivation can be summed up in the
slogan SAX SUX. I couldn't understand why anyone would persist with it
for any complex tasks, e.g. FOP. Some months ago, I stumbled across
this article from XML.com:
http://www.xml.com/pub/a/2001/12/19/jjc.html, which includes the following:
quote
Moving on to talk about the conventional ways XML was processed in
programs, Clark protested that the current widespread APIs (SAX and DOM)
made processing XML either too hard or too error-prone. He observed that
these first generation APIs now lagged behind recent W3C
Recommendations: Namespace support was grafted on, and they are
misaligned with the XML Infoset.
Echoing sentiments recently expressed in this publication, Clark said
that SAX, though efficient, was very hard to use, and that DOM had
obvious limitations due to the requirement that the document being
processed be in memory. He suggested that what was needed was a standard
pull API, one that efficiently allowed random access to XML documents.
Clark praised the XML APIs from Microsoft's C#/.NET platform in this
regard, adding that Java could learn much from .NET: Just because it
comes from Microsoft, it's not necessarily bad.
/quote
I haven't followed up on what these APIs do, but had a quick look today.
http://www.softartisans.com/softartisans/netpaper-skonnard-best01.html
includes this:
quote
The most common streaming API used today is the Simple API for XML
(SAX). Microsoft introduced support for SAX in MSXML 3.0 but then
determined that the SAX-based programming model was too obscure and
unnecessarily difficult for the majority of their developer community.
So to provide .NET developers with a more intuitive alternative,
Microsoft introduced a new streaming API through the XmlReader class
hierarchy.
The main difference between XmlReader and SAX is that the former allows
the client to control the flow of execution by pulling the nodes from
the stream one at a time while with the latter, the processor is in
control, pushing the nodes back to the client one node at a time. This
significant difference makes XmlReader much easier to use for most
Microsoft developers that are used to working with firehose
(forward-only/read-only) cursors in ADO.
/quote
The above gives a feel for the XmlReader API, and nicely describes the
impact of the buffering I have introduced between SAX and the FO tree
builder. As the attached diagram shows, the SAX push stream is
converted to a pull stream by the simple expedient of buffering. To
the client, the buffering presents a series of get and expect methods,
which reverses the direction of control. The Fo tree builder is now in
charge of events, rather than being a SAX-slave.
(There may be some echoes here of Avalon's use of the Inversion Of
Control pattern {there's that word} but the little I have read of IoC
does not allow me to draw any conclusions.)
This change has dramatic effects on the structure and clarity of the
code, all, IMO, for the better. Take, for instance, this code from
FoSimplePageMaster.java.
public FoSimplePageMaster
(FOTree foTree, FONode parent, FoXMLEvent event)
throws TreeException, FOPException
{
super(foTree, FObjectNames.SIMPLE_PAGE_MASTER, parent, event,
FONode.LAYOUT_SET, sparsePropsMap, sparseIndices);
// Process regions here
FoXMLEvent regionEv;
if ((regionEv = xmlevents.expectStartElement
(FObjectNames.REGION_BODY,
XMLEvent.DISCARD_W_SPACE))
== null)
throw new FOPException
(No fo:region-body in simple-page-master:
+ getMasterName());
// Process region-body
regionBody = new FoRegionBody(foTree, this, regionEv);
xmlevents.getEndElement(regionEv);
// Remaining regions are optional
if ((regionEv = xmlevents.expectStartElement
(FObjectNames.REGION_BEFORE,
XMLEvent.DISCARD_W_SPACE))
!= null)
{
regionBefore = new FoRegionBefore(foTree, this, regionEv);
xmlevents.getEndElement(regionEv);
}
if ((regionEv = xmlevents.expectStartElement
(FObjectNames.REGION_AFTER,
XMLEvent.DISCARD_W_SPACE))
!= null)
{
regionAfter = new FoRegionAfter(foTree, this, regionEv);
xmlevents.getEndElement(regionEv);
}
if ((regionEv = xmlevents.expectStartElement
RE: Alt-Design status: XML handling
Peter, thanks for the update and explanation on your Alt-Design. To be honest: I like it. Reminds me very much of my first exposure to programming language processing (Compilers) nearly 30 years ago = top-down recursive-decent parsing for Pascal. I still think its the best parsing model around (beats YACC type stuff by a long way) in terms of ease of development / understanding / use. Do you have any similar simple / effective ideas for the layout part which, following the discussions on this list, the new FOP design under CVS HEAD seems to struggle most with? Manuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo FObjectSets.java
pbwest 2002/11/20 22:57:42 Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FObjectSets.java Log: Moved FOOTNOTE into inlineEntity because the spec. is so dodgy about fo:footnote. Revision ChangesPath No revision No revision 1.1.2.3 +6 -3 xml-fop/src/org/apache/fop/fo/Attic/FObjectSets.java Index: FObjectSets.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/FObjectSets.java,v retrieving revision 1.1.2.2 retrieving revision 1.1.2.3 diff -u -r1.1.2.2 -r1.1.2.3 --- FObjectSets.java 13 Nov 2002 15:15:37 - 1.1.2.2 +++ FObjectSets.java 21 Nov 2002 06:57:42 - 1.1.2.3 @@ -61,6 +61,8 @@ inline.set(FObjectNames.LEADER); inline.set(FObjectNames.BASIC_LINK); inline.set(FObjectNames.MULTI_TOGGLE); +// Moved FOOTNOTE here because it may occur in static-content +inline.set(FObjectNames.FOOTNOTE); inlineEntity = new ROBitSet(inline); } @@ -134,7 +136,8 @@ normalPcdataInline = new BitSet(); normalPcdataInline.or(inline); normalPcdataInline.set(FObjectNames.FLOAT); -normalPcdataInline.set(FObjectNames.FOOTNOTE); +// Removed FOOTNOTE because it may occur in static-content +//normalPcdataInline.set(FObjectNames.FOOTNOTE); normalPcdataInlineSet = new ROBitSet(normalPcdataInline); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo FONode.java
pbwest 2002/11/20 23:01:10 Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FONode.java Log: attrSet - stateFlags. Revision ChangesPath No revision No revision 1.19.2.26 +49 -29xml-fop/src/org/apache/fop/fo/FONode.java Index: FONode.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/FONode.java,v retrieving revision 1.19.2.25 retrieving revision 1.19.2.26 diff -u -r1.19.2.25 -r1.19.2.26 --- FONode.java 13 Nov 2002 15:12:17 - 1.19.2.25 +++ FONode.java 21 Nov 2002 07:01:09 - 1.19.2.26 @@ -55,27 +55,54 @@ /** * State flags: a bit set of states applicable during FO tree build. * N.B. States must be powers of 2. + * pbBEWARE/b At what point are these ancestry flags supposed to + * apply? If they are son-of (MC), they should only be expected to + * be applied on the children of a particular node type. I don't think + * the higher level FO nodes are making this assumption. + * pJust changed most of the higher-level flags by removing the MC_ + * prefix, which remains on some of the lower levels. Use this convention + * for now: unprefixed name (e.g. Root), is a self-or-descendent + * indicator, while MC_ prefixed names are descendents only. + * pTODO: check for consistency of application. */ public static final int - NOSTATE = 0 -// These are used to select the attribute set for the node - ,ROOT_SET = 1 - ,DECLARATIONS_SET = 2 - ,LAYOUT_SET = 4 - ,SEQ_MASTER_SET = 8 -,PAGESEQ_SET = 16 - ,FLOW_SET = 32 - ,STATIC_SET = 64 - ,TITLE_SET = 128 - ,MARKER_SET = 256 -,OUT_OF_LINE = 512 -; + NOSTATE = 0 +// These are used to select the attribute set for the node + ,ROOT = 1 + ,DECLARATIONS = 2 + ,LAYOUT = 4 + ,SEQ_MASTER = 8 +,PAGESEQ = 16 + ,FLOW = 32 + ,STATIC = 64 + ,TITLE = 128 + ,MC_MARKER = 256 + ,MC_FLOAT = 512 +,MC_FOOTNOTE = 1024 + ,MC_MULTI_CASE = 2048 + ,MC_ABSOLUTELY_POSITIONED = 4096 +; + +public static final int +ROOT_SET = ROOT + ,DECLARATIONS_SET = ROOT | DECLARATIONS + ,LAYOUT_SET = ROOT | LAYOUT + ,SEQ_MASTER_SET = LAYOUT_SET | SEQ_MASTER +,PAGESEQ_SET = ROOT | PAGESEQ + ,FLOW_SET = PAGESEQ_SET | FLOW + ,STATIC_SET = PAGESEQ_SET | STATIC + ,TITLE_SET = PAGESEQ_SET | TITLE +,MARKER_SET = FLOW_SET | MC_MARKER +; + +public static final int MC_OUT_OF_LINE = +MC_FLOAT | MC_FOOTNOTE | MC_ABSOLUTELY_POSITIONED; /** The subset of istateFlags/i that select the relevant atttribute set or the node. */ public static final int ATTRIBUTESETS = -ROOT_SET | DECLARATIONS_SET | LAYOUT_SET | SEQ_MASTER_SET | -PAGESEQ_SET | FLOW_SET | STATIC_SET | TITLE_SET | MARKER_SET; +ROOT | DECLARATIONS | LAYOUT | SEQ_MASTER | +PAGESEQ | FLOW | STATIC | TITLE | MC_MARKER; /** The buffer from which parser events are drawn. */ protected SyncedFoXmlEventsBuffer xmlevents; @@ -137,10 +164,7 @@ /** The property expression parser in the FOTree. */ protected PropertyParser exprParser; -/** The iattrSet/i argument. */ -protected int attrSet; - -/** The ttROBitSet/tt of the iattrSet/i argument. */ +/** The ttROBitSet/tt from the istateFlags/i argument. */ protected ROBitSet attrBitSet; /** The state flags passed to this node. */ @@ -182,7 +206,7 @@ * @param sparseindices - an ttint[]/tt holding the set of property * indices applicable to this node, in ascending order. * isparsePropsMap/i maps property indices to a position in this array. - * Together they paovide a sparse array facility for this node's + * Together they provide a sparse array facility for this node's * properties. */ public FONode @@ -193,20 +217,16 @@ super(foTree, parent); this.type = type; this.stateFlags = stateFlags; -attrSet = stateFlags ATTRIBUTESETS; -if ((attrSet (attrSet - 1)) != 0) -throw new PropertyException -(Invalid attribut set: + attrSet); this.sparsePropsMap = sparsePropsMap; this.sparseIndices = sparseIndices;
cvs commit: xml-fop/src/org/apache/fop/fo FONode.java
pbwest 2002/11/20 23:04:40 Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FONode.java Log: Added Id. Revision ChangesPath No revision No revision 1.19.2.27 +3 -3 xml-fop/src/org/apache/fop/fo/FONode.java Index: FONode.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/FONode.java,v retrieving revision 1.19.2.26 retrieving revision 1.19.2.27 diff -u -r1.19.2.26 -r1.19.2.27 --- FONode.java 21 Nov 2002 07:01:09 - 1.19.2.26 +++ FONode.java 21 Nov 2002 07:04:39 - 1.19.2.27 @@ -35,7 +35,7 @@ /* * FONode.java * Created: Sat Nov 10 01:39:37 2001 - * + * $Id$ * Copyright (C) 2001 The Apache Software Foundation. All rights reserved. * For details on use and redistribution please refer to the * LICENSE file included with these sources. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo FOPropertySets.java
pbwest 2002/11/20 23:06:07
Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
FOPropertySets.java
Log:
attrSet - ancestry.
Revision ChangesPath
No revision
No revision
1.1.2.9 +37 -41xml-fop/src/org/apache/fop/fo/Attic/FOPropertySets.java
Index: FOPropertySets.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/FOPropertySets.java,v
retrieving revision 1.1.2.8
retrieving revision 1.1.2.9
diff -u -r1.1.2.8 -r1.1.2.9
--- FOPropertySets.java 13 Nov 2002 04:07:39 - 1.1.2.8
+++ FOPropertySets.java 21 Nov 2002 07:06:07 - 1.1.2.9
@@ -40,54 +40,50 @@
public static final String packageNamePrefix = org.apache.fop;
-public static String getAttrSetName(int attrSet) throws FOPException {
-switch (attrSet) {
-case FONode.ROOT_SET:
-return ROOT;
-case FONode.DECLARATIONS_SET:
-return DECLARATIONS;
-case FONode.LAYOUT_SET:
-return LAYOUT;
-case FONode.SEQ_MASTER_SET:
-return SEQ_MASTER;
-case FONode.PAGESEQ_SET:
-return PAGESEQ;
-case FONode.FLOW_SET:
+public static String getAttrSetName(int ancestry) throws FOPException {
+if ((ancestry FONode.MC_MARKER) != 0)
+return MARKER;
+if ((ancestry FONode.FLOW) != 0)
return FLOW;
-case FONode.STATIC_SET:
+if ((ancestry FONode.STATIC) != 0)
return STATIC;
-case FONode.TITLE_SET:
+if ((ancestry FONode.TITLE) != 0)
return TITLE;
-case FONode.MARKER_SET:
-return MARKER;
-}
-throw new FOPException(Invalid attribute set: + attrSet);
+if ((ancestry FONode.PAGESEQ) != 0)
+return PAGESEQ;
+if ((ancestry FONode.SEQ_MASTER) != 0)
+return SEQ_MASTER;
+if ((ancestry FONode.LAYOUT) != 0)
+return LAYOUT_MASTER;
+if ((ancestry FONode.DECLARATIONS) != 0)
+return DECLARATIONS;
+if ((ancestry FONode.ROOT) != 0)
+return ROOT;
+throw new FOPException(Invalid attribute set: + ancestry);
}
-public static ROBitSet getAttrROBitSet(int attrSet)
+public static ROBitSet getAttrROBitSet(int ancestry)
throws FOPException
{
-switch (attrSet) {
-case FONode.ROOT_SET:
-return allProps;
-case FONode.DECLARATIONS_SET:
-return declarationsAll;
-case FONode.LAYOUT_SET:
-return layoutMasterSet;
-case FONode.SEQ_MASTER_SET:
-return seqMasterSet;
-case FONode.PAGESEQ_SET:
-return pageSeqSet;
-case FONode.FLOW_SET:
+if ((ancestry FONode.MC_MARKER) != 0)
+return markerAllSet;
+if ((ancestry FONode.FLOW) != 0)
return flowAllSet;
-case FONode.STATIC_SET:
+if ((ancestry FONode.STATIC) != 0)
return staticAllSet;
-case FONode.TITLE_SET:
+if ((ancestry FONode.TITLE) != 0)
return titleAllSet;
-case FONode.MARKER_SET:
-return markerAllSet;
-}
-throw new FOPException(Invalid attribute set: + attrSet);
+if ((ancestry FONode.PAGESEQ) != 0)
+return pageSeqSet;
+if ((ancestry FONode.SEQ_MASTER) != 0)
+return seqMasterSet;
+if ((ancestry FONode.LAYOUT) != 0)
+return layoutMasterSet;
+if ((ancestry FONode.DECLARATIONS) != 0)
+return declarationsAll;
+if ((ancestry FONode.ROOT) != 0)
+return allProps;
+throw new FOPException(Invalid attribute set: + ancestry);
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo FOTree.java
pbwest 2002/11/20 23:08:13 Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FOTree.java Log: Removed debugging println. Added Id. Revision ChangesPath No revision No revision 1.1.2.25 +3 -5 xml-fop/src/org/apache/fop/fo/Attic/FOTree.java Index: FOTree.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/FOTree.java,v retrieving revision 1.1.2.24 retrieving revision 1.1.2.25 diff -u -r1.1.2.24 -r1.1.2.25 --- FOTree.java 11 Nov 2002 16:54:08 - 1.1.2.24 +++ FOTree.java 21 Nov 2002 07:08:13 - 1.1.2.25 @@ -26,8 +26,7 @@ import java.lang.reflect.Method; /* - * FOTree.java - * + * $Id$ * Copyright (C) 2001 The Apache Software Foundation. All rights reserved. * For details on use and redistribution please refer to the * LICENSE file included with these sources. @@ -79,7 +78,6 @@ // Set the initial value PropertyValue prop = PropertyConsts.pconsts.getInitialValue(PropNames.FONT_SIZE); -System.out.println(font-size property: + prop); if ( ! (prop instanceof Numeric) || ! ((Numeric)prop).isLength()) throw new PropertyException(Initial font-size is not a Length); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alt-Design status: XML handling
Great work Peter!
It makes a lot of sense to use higher-level than SAX events, and thanks for
explaining this so clearly.
If you allow me a suggestion regarding the structure of the code: maybe using
some table-driven stuff instead of the many if statements in
FoSimplePageMaster would be more readable?
Something like:
class EventHandler
{
EventHandler(String regionName,boolean discardSpace,boolean required)
...
}
/** table of event handlers that must be applied, in order */
EventHandler [] handlers = {
new EventHandler(FObjectNames.REGION_BODY,true,true),
new EventHandler(FObjectNames.REGION_BEFORE,true,false)
};
...then, in FoSimplePageMaster(...) loop over handlers and let them process
the events.
I don't know if this applies in general but it might be clearer to read and
less risky to modify.
-Bertrand
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo ShorthandPropSets.java
pbwest 2002/11/20 23:10:14
Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
ShorthandPropSets.java
Log:
Moved shorthandExpansions. Fixed getSHandExpansionSet().
Revision ChangesPath
No revision
No revision
1.1.2.5 +35 -35xml-fop/src/org/apache/fop/fo/Attic/ShorthandPropSets.java
Index: ShorthandPropSets.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/ShorthandPropSets.java,v
retrieving revision 1.1.2.4
retrieving revision 1.1.2.5
diff -u -r1.1.2.4 -r1.1.2.5
--- ShorthandPropSets.java21 Oct 2002 15:47:17 - 1.1.2.4
+++ ShorthandPropSets.java21 Nov 2002 07:10:14 - 1.1.2.5
@@ -277,37 +277,6 @@
};
/**
- * Map property index to shorthand array index
- */
-private static final HashMap shorthandMap;
-static {
-shorthandMap = new HashMap(shorthands.length);
-for (int i = 0; i shorthands.length; i++) {
-shorthandMap.put
-((Object)(Ints.consts.get(shorthands[i])),
- (Object)(Ints.consts.get(i)));
-}
-}
-
-/**
- * RO Shorthand properties.
- */
-public static final ROIntArray roShorthands =
-new ROIntArray(shorthands);
-
-/**
- * A ttROBitSet/tt of the shorthand properties.
- */
-public static final ROBitSet shorthandPropSet;
-private static final BitSet shorthandpropset;
-static {
-shorthandpropset = new BitSet(PropNames.LAST_PROPERTY_INDEX + 1);
-for (int i = 0; i shorthands.length; i++)
-shorthandpropset.set(shorthands[i]);
-shorthandPropSet = new ROBitSet(shorthandpropset);
-}
-
-/**
* Array of iROIntArray/ib in same order as ishorthands/i/b
* iROIntArray/i.
* If a public view of this is required, use
@@ -341,6 +310,37 @@
};
/**
+ * Map property index to shorthand array index
+ */
+private static final HashMap shorthandMap;
+static {
+shorthandMap = new HashMap(shorthands.length);
+for (int i = 0; i shorthands.length; i++) {
+shorthandMap.put
+((Object)(Ints.consts.get(shorthands[i])),
+ (Object)(Ints.consts.get(i)));
+}
+}
+
+/**
+ * RO Shorthand properties.
+ */
+public static final ROIntArray roShorthands =
+new ROIntArray(shorthands);
+
+/**
+ * A ttROBitSet/tt of the shorthand properties.
+ */
+public static final ROBitSet shorthandPropSet;
+private static final BitSet shorthandpropset;
+static {
+shorthandpropset = new BitSet(PropNames.LAST_PROPERTY_INDEX + 1);
+for (int i = 0; i shorthands.length; i++)
+shorthandpropset.set(shorthands[i]);
+shorthandPropSet = new ROBitSet(shorthandpropset);
+}
+
+/**
* @param property ttint/tt property index
* @return ttROIntArray/tt containing the expansion list for
* this shorthand.
@@ -360,7 +360,7 @@
}
// Get the array of indices of the properties in the
// expansion of this shorthand
-return shorthandExpansions[property];
+return shorthandExpansions[sHIndex.intValue()];
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Victor as committer (votes from non-commiters)
On Wednesday 20 November 2002 20:11, Rhett Aultman wrote: I thought everyone was allowed to use a vote to express their opinion. If I've gravely mistaken this, then I'll stop voting. I *think* it is so, that everyone is welcome to express their opinion. But as a mostly inactive committer I'm not the one to decide. Indicating this when voting helps, something like: VOTE: should FOP be rewritten in Forth? -1 (from a non-committer) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Victor as committer
Hi Art and Rhett, Anyone is allowed to vote on an issue and I would encourage people to express their opinion. In general only (active) committers votes are binding but we can consider other votes. On Wed, 2002-11-20 at 20:43, [EMAIL PROTECTED] wrote: Ok, I guess that answers my question. Sorry I was too lazy to look that up on my own. So my understanding is that only committers may vote, as per: A Committer has write access to the source code repository and gains voting rights allowing them to affect the future of the subproject. Putting this with the following: At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for 6 months or more may lose their status as a Committer. Getting access back is as simple as re-requesting it on the project's Developer mailing list I assume that being inactive means that I have lost my status as a committer and hence may not vote. So, hopefully one of these days (I have no idea when) I will again be able to contribute to FOP and re-attain committer status. At the moment, I am not actively working with FOP at work, but we are still using it (actually a version from a long while back - around the last time I contributed anything). The good thing is that I have not been called in to resolve any problems with FOP, the bad thing is that this is probably largely because of the limited use case. I hope in the future to expand this, which will likely entail some contributions to FOP. Or maybe by then my efforts will not be necessary - this would also be cool, although a bit disappointing in that I was not a part of it... Well, I hope you get some time to contribute. Art (inactive) Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/flow FoBasicLink.java FoBlockContainer.java FoFloat.java FoFootnoteBody.java FoFootnote.java FoInlineContainer.java FoInline.java FoLeader.java FoListBlock.java FoListItemBody.java FoListItem.java FoListItemLabel.java FoMarker.java FoMultiCase.java FoMultiProperties.java FoMultiPropertySet.java FoMultiSwitch.java FoMultiToggle.java FoRetrieveMarker.java FoTableAndCaption.java FoTableBody.java FoTableCaption.java FoTableCell.java FoTableFooter.java FoTableHeader.java FoTable.java FoTableRow.java FoWrapper.java
pbwest 2002/11/20 23:49:34
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoBasicLink.java FoBlockContainer.java FoFloat.java
FoFootnoteBody.java FoFootnote.java
FoInlineContainer.java FoInline.java FoLeader.java
FoListBlock.java FoListItemBody.java
FoListItem.java FoListItemLabel.java FoMarker.java
FoMultiCase.java FoMultiProperties.java
FoMultiPropertySet.java FoMultiSwitch.java
FoMultiToggle.java FoRetrieveMarker.java
FoTableAndCaption.java FoTableBody.java
FoTableCaption.java FoTableCell.java
FoTableFooter.java FoTableHeader.java FoTable.java
FoTableRow.java FoWrapper.java
Log:
Added subtree processing.
Revision ChangesPath
No revision
No revision
1.1.2.6 +3 -3 xml-fop/src/org/apache/fop/fo/flow/Attic/FoBasicLink.java
Index: FoBasicLink.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoBasicLink.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
--- FoBasicLink.java 17 Nov 2002 09:50:08 - 1.1.2.5
+++ FoBasicLink.java 21 Nov 2002 07:49:33 - 1.1.2.6
@@ -130,10 +130,10 @@
ev = xmlevents.getEndElement(ev);
}
} catch(UnexpectedStartElementException e) {
+ev = xmlevents.getStartElement();
MessageHandler.logln
(Ignoring unexpected Start Element:
+ ev.getQName());
-ev = xmlevents.getStartElement();
ev = xmlevents.getEndElement(ev);
}
} while (ev != null);
1.1.2.7 +2 -2 xml-fop/src/org/apache/fop/fo/flow/Attic/FoBlockContainer.java
Index: FoBlockContainer.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoBlockContainer.java,v
retrieving revision 1.1.2.6
retrieving revision 1.1.2.7
diff -u -r1.1.2.6 -r1.1.2.7
1.1.2.6 +4 -4 xml-fop/src/org/apache/fop/fo/flow/Attic/FoFloat.java
Index: FoFloat.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoFloat.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
--- FoFloat.java 17 Nov 2002 09:50:08 - 1.1.2.5
+++ FoFloat.java 21 Nov 2002 07:49:33 - 1.1.2.6
@@ -102,7 +102,7 @@
ev = xmlevents.expectOutOfLineBlock();
if (ev == null)
throw new FOPException
-(%block; not found in fo:table-cell);
+(%block; not found in fo:float);
// Generate the flow object
FObjects.fobjects.makeFlowObject
(foTree, this, ev, stateFlags | FONode.MC_FLOAT);
@@ -123,7 +123,7 @@
} while (ev != null);
} catch(UnexpectedStartElementException e) {
throw new FOPException
-(Block not found or unexpected non-block in fo:table-cell);
+(Block not found or unexpected non-block in fo:float);
}
makeSparsePropsSet();
1.1.2.6 +2 -2 xml-fop/src/org/apache/fop/fo/flow/Attic/FoFootnoteBody.java
Index: FoFootnoteBody.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoFootnoteBody.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
1.1.2.6 +18 -4 xml-fop/src/org/apache/fop/fo/flow/Attic/FoFootnote.java
Index: FoFootnote.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoFootnote.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
--- FoFootnote.java 17 Nov 2002 09:50:08 - 1.1.2.5
+++ FoFootnote.java 21 Nov 2002 07:49:33 - 1.1.2.6
@@ -28,6 +28,17 @@
/**
* Implements the fo:footnote flow object.
+ * pFootnote is an extremely messy flow object. The only absolute
+ * prohibition seem sto be that it may not be a descendant of another
+ * fo:footnote. b6.10.3 fo:footnote/b iConstraints/i states:
+* pttIt is an error if the fo:footnote occurs as a
+ * descendant of a flow that is not assigned to a region-body, or of an
+ *
cvs commit: xml-fop/src/org/apache/fop/fo/flow FoNoFo.java
pbwest 2002/11/20 23:50:53
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoNoFo.java
Log:
Throw exception only. No extends clause.
Revision ChangesPath
No revision
No revision
1.1.2.6 +15 -14xml-fop/src/org/apache/fop/fo/flow/Attic/FoNoFo.java
Index: FoNoFo.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoNoFo.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
--- FoNoFo.java 17 Nov 2002 09:50:08 - 1.1.2.5
+++ FoNoFo.java 21 Nov 2002 07:50:53 - 1.1.2.6
@@ -28,7 +28,7 @@
/**
* Implements the fo:no-fo flow object.
*/
-public class FoNoFo extends FONode {
+public class FoNoFo {
private static final String tag = $Name$;
private static final String revision = $Revision$;
@@ -38,16 +38,17 @@
position in the isparsePropsSet/i array. See
{@link org.apache.fop.fo.FONode#sparsePropsSet FONode.sparsePropsSet}.
*/
-private static final HashMap sparsePropsMap;
+//private static final HashMap sparsePropsMap;
/** An ttint/tt array of of the applicable property indices, in
property index order. */
-private static final int[] sparseIndices;
+//private static final int[] sparseIndices;
/** The number of applicable properties. This is the size of the
isparsePropsSet/i array. */
-private static final int numProps;
+//private static final int numProps;
+/*
static {
// Collect the sets of properties that apply
BitSet propsets = new BitSet();
@@ -62,24 +63,24 @@
sparsePropsMap.put
(Ints.consts.get(PropNames.NO_PROPERTY), Ints.consts.get(0));
}
+*/
/**
+ * The non-existent flow object. If it comes to this, something
+ * has gone wrong. A use may be found for this later.
* @param foTree the FO tree being built
* @param parent the parent FONode of this node
* @param event the ttFoXMLEvent/tt that triggered the creation of
* this node
- * @param attrSet the index of the attribute set applying to the node.
+ * @param stateFlags - passed down from the parent. Includes the
+ * attribute set information.
+ * @throws FOPException, without exception.
*/
public FoNoFo
-(FOTree foTree, FONode parent, FoXMLEvent event, int attrSet)
-throws TreeException, FOPException
+(FOTree foTree, FONode parent, FoXMLEvent event, int stateFlags)
+throws FOPException
{
-super(foTree, FObjectNames.NO_FO, parent, event,
- attrSet, sparsePropsMap, sparseIndices);
-FoXMLEvent ev;
-String nowProcessing;
-
-makeSparsePropsSet();
+throw new FOPException(No such flow object as fo:no-fo.);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/flow FoPageSequence.java
pbwest 2002/11/20 23:51:51 Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design FoPageSequence.java Log: Cosmetic changes. Revision ChangesPath No revision No revision 1.1.2.4 +2 -2 xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageSequence.java Index: FoPageSequence.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageSequence.java,v retrieving revision 1.1.2.3 retrieving revision 1.1.2.4 diff -u -r1.1.2.3 -r1.1.2.4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/flow FoPcdata.java
pbwest 2002/11/20 23:53:02
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoPcdata.java
Log:
Fixed stateFlags. Added getCharacters().
Revision ChangesPath
No revision
No revision
1.1.2.4 +16 -7 xml-fop/src/org/apache/fop/fo/flow/Attic/FoPcdata.java
Index: FoPcdata.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoPcdata.java,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- FoPcdata.java 17 Nov 2002 09:50:08 - 1.1.2.3
+++ FoPcdata.java 21 Nov 2002 07:53:02 - 1.1.2.4
@@ -104,23 +104,32 @@
private String characters;
/**
+ * Construct an FoPcdata object to contain the characers from a
+ * character data node. There is no corresponding Flow Obect in the
+ * specification.
* @param foTree the FO tree being built
* @param parent the parent FONode of this node
* @param event the ttFoXMLEvent/tt that triggered the creation of
* this node
- * @param attrSet the index of the attribute set applying to the node.
+ * @param stateFlags - passed down from the parent. Includes the
+ * attribute set information.
*/
public FoPcdata
-(FOTree foTree, FONode parent, FoXMLEvent event, int attrSet)
+(FOTree foTree, FONode parent, FoXMLEvent event, int stateFlags)
throws TreeException, FOPException
{
super(foTree, FObjectNames.PCDATA, parent, event,
- attrSet, sparsePropsMap, sparseIndices);
+ stateFlags, sparsePropsMap, sparseIndices);
characters = event.getChars();
-FoXMLEvent ev;
-String nowProcessing;
-
makeSparsePropsSet();
+}
+
+/**
+ * Get the ttString/tt data of the node.
+ * @return the string of characters.
+ */
+public String getCharacters() {
+return characters;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/flow FoInstreamForeignObject.java FoPageNumberCitation.java FoPageNumber.java FoTableColumn.java
pbwest 2002/11/20 23:55:19
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoInstreamForeignObject.java
FoPageNumberCitation.java FoPageNumber.java
FoTableColumn.java
Log:
Fixed stateFlags.
Revision ChangesPath
No revision
No revision
1.1.2.7 +3 -3
xml-fop/src/org/apache/fop/fo/flow/Attic/FoInstreamForeignObject.java
Index: FoInstreamForeignObject.java
===
RCS file:
/home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoInstreamForeignObject.java,v
retrieving revision 1.1.2.6
retrieving revision 1.1.2.7
diff -u -r1.1.2.6 -r1.1.2.7
--- FoInstreamForeignObject.java 17 Nov 2002 09:50:08 - 1.1.2.6
+++ FoInstreamForeignObject.java 21 Nov 2002 07:55:18 - 1.1.2.7
@@ -108,11 +108,11 @@
* attribute set information.
*/
public FoInstreamForeignObject
-(FOTree foTree, FONode parent, FoXMLEvent event, int attrSet)
+(FOTree foTree, FONode parent, FoXMLEvent event, int stateFlags)
throws TreeException, FOPException
{
super(foTree, FObjectNames.INSTREAM_FOREIGN_OBJECT, parent, event,
- attrSet, sparsePropsMap, sparseIndices);
+ stateFlags, sparsePropsMap, sparseIndices);
// TODO
makeSparsePropsSet();
}
1.1.2.6 +2 -2
xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageNumberCitation.java
Index: FoPageNumberCitation.java
===
RCS file:
/home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageNumberCitation.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
1.1.2.6 +2 -2 xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageNumber.java
Index: FoPageNumber.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoPageNumber.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
1.1.2.6 +2 -2 xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableColumn.java
Index: FoTableColumn.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTableColumn.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/flow FoBlock.java FoBidiOverride.java
pbwest 2002/11/20 23:56:29
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoBlock.java FoBidiOverride.java
Log:
Fixed exception message. Fixed MC_OUT_OF_LINE.
Revision ChangesPath
No revision
No revision
1.1.2.7 +3 -3 xml-fop/src/org/apache/fop/fo/flow/Attic/FoBlock.java
Index: FoBlock.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoBlock.java,v
retrieving revision 1.1.2.6
retrieving revision 1.1.2.7
diff -u -r1.1.2.6 -r1.1.2.7
--- FoBlock.java 17 Nov 2002 09:50:08 - 1.1.2.6
+++ FoBlock.java 21 Nov 2002 07:56:29 - 1.1.2.7
@@ -142,10 +142,10 @@
ev = xmlevents.getEndElement(ev);
}
} catch(UnexpectedStartElementException e) {
+ev = xmlevents.getStartElement();
MessageHandler.logln
(Ignoring unexpected Start Element:
+ ev.getQName());
-ev = xmlevents.getStartElement();
ev = xmlevents.getEndElement(ev);
}
} while (ev != null);
1.1.2.7 +3 -3 xml-fop/src/org/apache/fop/fo/flow/Attic/FoBidiOverride.java
Index: FoBidiOverride.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoBidiOverride.java,v
retrieving revision 1.1.2.6
retrieving revision 1.1.2.7
diff -u -r1.1.2.6 -r1.1.2.7
--- FoBidiOverride.java 17 Nov 2002 09:50:08 - 1.1.2.6
+++ FoBidiOverride.java 21 Nov 2002 07:56:29 - 1.1.2.7
@@ -116,10 +116,10 @@
ev = xmlevents.getEndElement(ev);
}
} catch(UnexpectedStartElementException e) {
+ev = xmlevents.getStartElement();
MessageHandler.logln
(Ignoring unexpected Start Element:
+ ev.getQName());
-ev = xmlevents.getStartElement();
ev = xmlevents.getEndElement(ev);
}
} while (ev != null);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/flow FoTitle.java
pbwest 2002/11/20 23:57:04
Modified:src/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design
FoTitle.java
Log:
Fixed excpetion message.
Revision ChangesPath
No revision
No revision
1.1.2.6 +2 -2 xml-fop/src/org/apache/fop/fo/flow/Attic/FoTitle.java
Index: FoTitle.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Attic/FoTitle.java,v
retrieving revision 1.1.2.5
retrieving revision 1.1.2.6
diff -u -r1.1.2.5 -r1.1.2.6
--- FoTitle.java 17 Nov 2002 09:50:09 - 1.1.2.5
+++ FoTitle.java 21 Nov 2002 07:57:04 - 1.1.2.6
@@ -113,10 +113,10 @@
ev = xmlevents.getEndElement(ev);
}
} catch(UnexpectedStartElementException e) {
+ev = xmlevents.getStartElement();
MessageHandler.logln
(Ignoring unexpected Start Element:
+ ev.getQName());
-ev = xmlevents.getStartElement();
ev = xmlevents.getEndElement(ev);
}
} while (ev != null);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
