RE: meaning of Area.TreeExt interface
If you hard code the bookmarks how would you handle the id resolution, as that is done through the area tree. Potentially you could code the bookmarks in other renderers like AWT. -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Monday, 25 October 2004 12:26 PM To: [EMAIL PROTECTED] Subject: RE: meaning of Area.TreeExt interface Thanks for the clarification. PDF Bookmarks aren't working currently, so that's what I'm looking at ATM. We may have another object extending the TreeExt interface, should we have a fox:metadata in the future. Still, I wonder if it may be better to do away with this interface and just hardcode the layout/rendering of these objects (i.e. bookmarks) directly, just like we do all the other Area objects that are created during the layout process. This would simplify area.extensions.BookmarkData and area.AreaTreeModel processing code. Thoughts (anyone)? The major benefit I see of TreeExt is that our Renderer interface can remain with a single renderExtension() for this and any other TreeExt in the future. But OTOH clarity arguments can be made for explicitly spelling out each object that a Renderer may need to support. For example, having renderBookmarks(), processMetaData(), etc. methods instead of using instanceof within renderExtension() methods to determine the TreeExt object in question. Thanks, Glen
RE: Difference between 0.20.5 and 1.0 PDF libraries?
Glen, The way PDF works is that it allows for the adding of new instructions and objects that are fully backward and forward compatible. So an older view can read and show newer files but without the new function (such as transparency) it just interprets the objects in the normal default way. Also an older file on a newer viewer works as expected with the features in the file. So you can use newer features in the fo and output PDF and as long as the default for the objects is suitable then it should display well on both. Keiron -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Monday, 18 October 2004 9:51 PM To: [EMAIL PROTECTED] Subject: RE: Difference between 0.20.5 and 1.0 PDF libraries? Keiron, Thanks. Keiron/Jeremias, Jeremias mentioned transparency added in the new library, which is a 1.4 Spec feature (according to an old email from Keiron that Clay brought out.) Does this mean that the PDF renderer in HEAD won't work if you use a 1.3-level Acrobat reader, or it won't work *only* if you try to use transparency (or some other 1.4 feature) in a 1.3-level Acrobat reader? (i.e., are the parts of the spec that are common in PDF 1.3 and 1.4 spec defined the same way, so we can support 1.4 features while someone who wants 1.3 compliance can still have that just by not using any 1.4 features in his FO?) (Hopefully I'm being clear here... ;) Thanks, Glen
RE: XML Graphics: board concerns
Hi, Thanks for the support. I will go ahead and do whatever I can to help out with this and be part of the XML graphics PMC. I have read all the emails about this concept and think that it is a good idea and should help things develop in useful directions. Regards, Keiron Liddle -Original Message- From: Thomas DeWeese [mailto:[EMAIL PROTECTED] Sent: Thursday, 23 September 2004 12:20 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: XML Graphics: board concerns Jeremias Maerki wrote: Does anyone of the Batik and FOP committers have an objection against inviting Bertrand and Keiron into the XML Graphics PMC? I'm happy to have Keiron +1 I don't know anything about Bertrand, so I guess +0. As far as the chair is concerned +0. I'd rather see someone who is active on the projects as chair.
RE: AFP Renderer
-Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED] Sent: Tuesday, 10 August 2004 6:10 PM To: [EMAIL PROTECTED] Subject: Re: AFP Renderer Glen Mazza wrote: There are already other AFP Renderers for FOP 0.20.5--actually Hansuli has it in our resources page: http://xml.apache.org/fop/resources.html I agree with Pete here - this AFP renderer is too disjointed and has a few limitations which make it too unpractical. And--amazing what Google searches turn up--Keiron also created one for FOP apparently: http://www.aftexsw.com/personal/resume.html Interesting, I never knew that either! Well I did it for an internal project and was never allowed to release the code so it has remained unchanged and closed for some time now. I still believe that all is needed is for someone to start put the code into the public. The basic format (although binary and a bit difficult to understand) is not that hard once you get the idea. I wouldn't think there are any licensing issues since the format specs are available in to the public. But if you wish to donate code to the ASF, you are welcome to submit it as a patch--in either 0.20.5 or 1.0 format. (I caution though that the 1.0 rendering system architecturally is not finalized.) We can possibly leverage it along with the others in the future. The fact that we don't have native support for it already, however, could mean that there were licensing issues involved with its inclusion (or the fonts it uses, perhaps). This may be an IBM-only technology for which you must use IBM-only products--I don't know. I dont think there are any licensing issues. AFP is a widely used print format. I have worked on software products dealing with AFP before. Chris
RE: Offline
Congrats, have fun should be nice down there. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Sent: Thursday, 17 June 2004 11:07 PM To: fop-dev Subject: Offline Fopfellows, I will be offline for the next week. I'm marrying Jenni tomorrow, and honeymooning in the frozen south of the South Island of New Zealand for a week. I'll post some photos to my web site when I get back. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Which area rectangle does Block.height and Block.width specify?
Hi, I was looking at some of the border issues and would like to ask for a little clarification of which of area rectangle that is described by Block.getHeight and Block.getWidth. I think the intention was that it is the allocation width and height, the content is then calculated from the border, padding and indents. So the width and height is the external values for use by other elements for example when working out the ipd or bpd used by the area. http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#area-geo From looking at the layout managers it seems to specify the content rectangle but the border code in PDFRendere interprets the values as the allocation rectangle. I would guess that that values should be the size of content rectangle. regards, finn
Re: SVG vs PDF output
Hi George, The SVG output uses the AWT font metrics of the current system, which is the same font metrics that Batik uses to do the text rendering. Whereas the PDF output uses the PDF font metrics which are standardized across any system. These metrics are often different which will explain the different output you are experiencing as the flow of the text depends on the size of each character in the font. Keiron Hi, everyone. I recently come across to that the SVG output and PDF output are slightly off each other. Take a look at the examples\basic\simple.fo, the difference starts at the 4th line, in SVG, it ends with word with while in PDF, it ends with both. This difference is small for font san-serif, but it is very distinguish when using some narrow fonts. Is this a known issue? George
Re: SVG vs PDF output
This sounds bad, shouldn't FOP take the charge of font metric measurement before rendering to different format? It does, the font metrics for SVG are the AWT metrics taken from java which are from the current platform. Does this mean that for different fonts, SVG output will alway have the same number of character in each line? No. The SVG output depends on the AWT fonts available which are often different to the PDF fonts. It should fit the characters according to the font metrics being used. George
Re: Batik hanging on FOP 0.20.x nightly/1.0 dev release.
--- Thomas DeWeese [EMAIL PROTECTED] wrote: At least one of the issues is with the PDFGraphics2D. in PDFGraphics2D.java:632 in draw(shape s). There is a check for a newTransform which inexplicably decides that if the new transform is the Identity transform there is no change. IIRC that was because the transform would have no effect. A transform in PDF appends to the current transform rather than setting the transform. Thanks, Thomas, for taking a look at the code for us. Andreas added your comments to the Bugzilla report so they won't be lost. We'll get to these issues (hopefully!) soon. Glen Keiron
Re: [VOTE] Move StructureHandler and LayoutHandler classes
Team, While Victor and Jeremias are discussing an input API--I'd like to take advantage now of the relative freeze in the codebase to move the StructureHandler and LayoutHandler classes from the apps package to the fo and area packages respectively (similar to what we're doing with MIF/RTFHandler). Shouldn't the LayoutHandler go with the layout manager package. The area package is really only for the area tree. It primarily involves moving two files and updating the headers of several others. I've already submitted a patch for this (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20397) but it has fallen out of date; this time I will make the change again and commit it to CVS. I should be able to get it done this weekend (sorry I can't do it earlier.) Here's my +1 on this. +1 for moving them out of apps. Thanks, Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop status.xml
keiron 2003/04/01 16:40:04 Modified:.status.xml Log: updated status re markers Revision ChangesPath 1.28 +11 -11xml-fop/status.xml Index: status.xml === RCS file: /home/cvs/xml-fop/status.xml,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- status.xml28 Mar 2003 08:27:17 - 1.27 +++ status.xml2 Apr 2003 00:40:04 - 1.28 @@ -41,17 +41,6 @@ /action action context=code dev=open - Add markers to page when areas added. - When an area is added that is created by an FO that contains markers - then the markers can also be added. There are four types of positions - for markers. -/action -action context=code dev=open - Retrieve markers from page. - When doing the static areas the markers will need to be available for - retrieving. The marker can then be layed out as normal. -/action -action context=code dev=open Implement spacing between blocks and the adjustment to actual height when adding areas. /action @@ -115,6 +104,17 @@ changes release version=2003 date=2003 +action context=code dev=KLL type=update + Added markers to page when areas added. + When an area is added that is created by an FO that contains markers + then the markers can also be added. There are four types of positions + for markers. +/action +action context=code dev=KLL type=update + Retrieved markers from page. + When doing the static areas the markers will need to be available for + retrieving. Layout currently has some issues. +/action action context=code dev=JM type=update PDF and PS transcoders now have a common base class. It also optionally supports Avalon Logging and Configuration. Support for - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the -c user config option implemented???
Thanks Keiron for the feedback! I found and reviewed the discussion regarding the move to Avalon (ref: http://marc.theaimsgroup.com/?l=fop-devm=10226606705w=2 ). I also appreciate your point that some aspects of configuration have already been 're-enabled'; as exemplified in CommandLineStarter.run() which calls commandLineOptions.getOutputFile() and commandLineOptions.getRendererOptions(). I want to use the -c option to import a font refed in a userconfig.xml file as per http://xml.apache.org/fop/fonts.html#Register+the+fonts+within+FOP- N10261 I can see that CommandLineOptions.parseOptions(...) is caching my userconfig.xml file in its userConfigFile member. Grepping the source does not reveal anyone calling the getUserConfigFile() accessor and I'm unable to find anyone parsing the userConfigFile, so this is what I mean when I say that I suspect configuration is not completely re-enabled. To get the configuration we will probably use the DefaultConfigurationBuilder in avalon framework: http://avalon.apache.org/framework/api/index.html The buildFromFile will return a Configuration object which holds all the configuration data. If you then look in org.apache.fop.render.pdf.PDFRenderer in the configure method you will see that it reads the filter and font information. I don't think there is any code to hook this up. You could do the filename to Configuration object in the Driver. Then it could call configure on the Renderer. I think it will need to get a child Configuration object that matches the mime type for the renderer. Take a look at xml-fop/conf/fop.xconf for a draft of the configuration XML format. Good luck. If you need any more help then give us a yell. So, I guess my question now is: Are CommandLineOptions.userConfigFile font tags being processed? If so, then where? If not, then... yes, given some pointers, I'm interested in helping to get it working. -- Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Patterns
Hi Jeremias, The patterns were working to a degree as far as I know. The one under src/documentation/content/xdocs/dev/svg/paints.svg partly works but the patterns have the wrong transform and patterns in patterns gives an error when viewing with acrobat 5. I can fix the angle of the transform but I can't figure out the translation. The tests under batik however show a number of problems. I did notice that there are a few problems with \n characters, extra or missing, for example after the filter. I am also getting a problem with no number assigned in the PDFGoTo with the link.svg. So in what way is it not working for you, is the pattern not visible which may be due to a wrong transform or is it some other problem. Keiron. Keiron, during testing I found that type 1 patterns didn't work. Was that always so? I coded a little proggie that built a PDF from scratch by hand with only the PDF library and I was able to create a working type 1 pattern. I also tried to edit a simple PDF generated by the PDF transcoder to make it work, but I always got nothing. If you want to look into it, I can send you my code and ultra-simple testcase. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] logo contest vote, round 1
Hi, My three would be: 30, 13 and 20 Keiron Hello! I have added #30 as somehow modified #7 and added one new penguin logo. Now lets finally finish with this stuff. As Peter suggested lets vote by 3 favorite logos first. My list: #30 #2 #21 PS. Here is the list for you convenience: http://vote.sparklit.com/web_poll.spark/714566 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/svg PDFGraphics2D.java
keiron 2003/03/27 15:53:29
Modified:src/java/org/apache/fop/svg PDFGraphics2D.java
Log:
moved image drawing so drawing with size also works
Revision ChangesPath
1.4 +44 -45xml-fop/src/java/org/apache/fop/svg/PDFGraphics2D.java
Index: PDFGraphics2D.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/svg/PDFGraphics2D.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- PDFGraphics2D.java27 Mar 2003 11:27:28 - 1.3
+++ PDFGraphics2D.java27 Mar 2003 23:53:28 - 1.4
@@ -406,6 +406,50 @@
return false;
}
+return drawImage(img, x, y, width, height, observer);
+}
+
+private BufferedImage buildBufferedImage(Dimension size) {
+return new BufferedImage(size.width, size.height,
+ BufferedImage.TYPE_INT_ARGB);
+}
+
+/**
+ * Draws as much of the specified image as has already been scaled
+ * to fit inside the specified rectangle.
+ * p
+ * The image is drawn inside the specified rectangle of this
+ * graphics context's coordinate space, and is scaled if
+ * necessary. Transparent pixels do not affect whatever pixels
+ * are already there.
+ * p
+ * This method returns immediately in all cases, even if the
+ * entire image has not yet been scaled, dithered, and converted
+ * for the current output device.
+ * If the current output representation is not yet complete, then
+ * codedrawImage/code returns codefalse/code. As more of
+ * the image becomes available, the process that draws the image notifies
+ * the image observer by calling its codeimageUpdate/code method.
+ * p
+ * A scaled version of an image will not necessarily be
+ * available immediately just because an unscaled version of the
+ * image has been constructed for this output device. Each size of
+ * the image may be cached separately and generated from the original
+ * data in a separate image production sequence.
+ * @paramimgthe specified image to be drawn.
+ * @paramx the ix/i coordinate.
+ * @paramy the iy/i coordinate.
+ * @paramwidth the width of the rectangle.
+ * @paramheight the height of the rectangle.
+ * @paramobserverobject to be notified as more of
+ * the image is converted.
+ * @return true if the image was drawn
+ * @see java.awt.Image
+ * @see java.awt.image.ImageObserver
+ * @see java.awt.image.ImageObserver#imageUpdate(java.awt.Image, int, int,
int, int, int)
+ */
+public boolean drawImage(Image img, int x, int y, int width, int height,
+ ImageObserver observer) {
// first we look to see if we've already added this image to
// the pdf document. If so, we just reuse the reference;
// otherwise we have to build a FopImage and add it to the pdf
@@ -540,51 +584,6 @@
currentStream.write( + width + 0 0 + (-height) + + x
+ + (y + height) + cm\n + /Im
+ imageInfo.getXNumber() + Do\nQ\n);
-return true;
-}
-
-private BufferedImage buildBufferedImage(Dimension size) {
-return new BufferedImage(size.width, size.height,
- BufferedImage.TYPE_INT_ARGB);
-}
-
-/**
- * Draws as much of the specified image as has already been scaled
- * to fit inside the specified rectangle.
- * p
- * The image is drawn inside the specified rectangle of this
- * graphics context's coordinate space, and is scaled if
- * necessary. Transparent pixels do not affect whatever pixels
- * are already there.
- * p
- * This method returns immediately in all cases, even if the
- * entire image has not yet been scaled, dithered, and converted
- * for the current output device.
- * If the current output representation is not yet complete, then
- * codedrawImage/code returns codefalse/code. As more of
- * the image becomes available, the process that draws the image notifies
- * the image observer by calling its codeimageUpdate/code method.
- * p
- * A scaled version of an image will not necessarily be
- * available immediately just because an unscaled version of the
- * image has been constructed for this output device. Each size of
- * the image may be cached separately and generated from the original
- * data in a separate image production sequence.
- * @paramimgthe specified image to be drawn.
- * @paramx the ix/i coordinate.
- * @param
Re: Drawing images with PDFDocumentGraphics2D
I was curious and tried your code. Look like the drawImage method in
question isn't implemented in PDFGraphics2D.java.
This is fixed in cvs, just moved some code.
I modified your code and got a image in PDF when I did the following:
while(!PDFGenerator1.drawImage(img, 400, 300, panel)) {
Thread.sleep(200);
}
The TestPDFGen now works with both draw image methods provided you wait on
the observer as above.
Not in the right place and with the right size, but the image
nonetheless. Looks like Graphics2D.java still needs a little work.
Also, maybe using System.out to create PDFs using FOP may not be the
best idea because there are still some System.out.println statements
scattered around the codebase.
Maybe that helps.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: PDF library refactoring
These changes are in CVS (redesign) now. I've also introduced a dependency on Jakarta Commons IO, mainly because of the CountingOutputStream needed for on-the-fly stream output. It also contains several utility methods (such as for stream copy) that also exist in out codebase. I'd like to remove ours over time. Help is welcome. I hope you guys don't mind that I have done this. I will revert if anyone objects, but I think it makes sense to use the Commons classes. I still need to update the build to create that all-in-one PDF transcoder. I seems to be working well. Good stuff. I noticed that the default filter is now no filter. Is that intended? The FOP and the PDF transcoder will probably want to set at least flate compression. I've also updated the Gump descriptor for the new dependency. I hope it works. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Drawing images with PDFDocumentGraphics2D
Hi, The ImageObserver is used in the getWidth, getHeight and drawImage methods with the image that is passed in. So in a sense it depends on the img that you are passing in. The observer is an object waiting for the image to be loaded. How are you creating the image, can you get an abserver from there somehow. Maybe you could use a dummy observer if the image is already loaded. Keiron. How can I obtain an java.awt.ImageObserver that I can pass to one of the drawImage methods of PDFDocumentGraphics2D? Example: pdfgen = new PDFDocumentGraphics2D(true,System.out,800,1100); ... pdfgen.drawImage(img,100,100,50,50,imgObserver); With a pure AWT application, I would pass the java.awt.Panel whose paint method invokes drawImage. But with PDFDocumentGraphics2D, I don't have such a Panel object. Even if I create a surrogate one, the resulting PDF will not have the images in it. What can act as the ImageObserver? Thanks, Julio Lerm Chicago, IL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Development/Redesign tabs
I made some decent progress today on getting my head into the trunk code, and to document some of what I have learned. I am still confused by the Development and Redesign tabs. At first, I thought that maybe Development was for those who might be developing on the maintenance branch, and Redesign for those on the trunk, but the title to the index document under Development seems to belie that. I see that we have some problems with the left nav bar that result from our directory structure. For example, first click http://xml.apache.org/fop/design/index.html, then click on the tab entitled Understanding, and watch the left nav bar change, which you would think it should not. Perhaps we made the two tabs to ease that problem? Assuming that I can find the Forrest solution to that problem, is there any objection to merging these two tabs into one entitled Development? Hi Victor, The original idea of the development was for user documentation for the current development. So it can be updated as the API and other such details are changed. For example with the faq, it had some different information on things such as text in SVG. Maybe it would be better to only have the new information there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Development/Redesign tabs
With regard to the faq, I just last night sliced out nearly all of the contents of the dev/faq.xml file. As far as I could tell, it was a duplicate of an old version of the faq.xml. Those changes are not reflected on the site yet (I have emailed Jeff to try to find out why not). It wasn't quite a duplication of the old version. So where should the new/updated information be put? It should be put somewhere so the information can be updated as we a\go and not be lost while still have the old version available. I don't care a lot about whether we have 1 or 2 developer tabs -- I just want to clarify what they are, not only so that I know what to put where, but also so that the web site users understand what they are seeing. It is confusing enough to have two branches of development, but to have our documentation mixed up or unclear is a serious problem. A case could be made that we don't want a developer tab for the maintenance branch, because we don't really want anyone developing for it. I kind of thought that was what was going on when I saw the index for it with the title FOP 1.0 development. I propose the following for a 3-tab structure (I am not ignoring the Alt Design tab, it just isn't affected by this): Home Release Development 1.0 Development If you prefer to combine the developer doc, then: Home Development Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOText constructor (trunk)
Hi Victor, If I can remember correctly, it was done for a few reasons. Originally it was using the parent to load properties, it would then store these properties in variables and pass them to methods when doing layout. It is possible that the same parent could have more than one FOText child created, depending on SAX events and other children, this meant that it was reading those properties and putting them into variables multiple times when only one copy was needed. The TextInfo class holds this information. Also now that the layout is done separately it is easier to pass a single object with all the text information. The other is to reduce references in the fo tree. So if possible I would suggest putting the required properties into the TextInfo class. Keiron. There is a change between the maintenance branch the redesign (trunk) that I do not understand. The constructor for FOText no longer has its parent node as a parameter as it did in the maintenance branch. Does anyone know the purpose of this? FWIW, it was part of the very first revision after the maintenance branch was created (rev 1.25). Specifically, is it a problem if I put it back in? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOText constructor (trunk)
Jeremias Maerki wrote: Anyway, may I ask for the reason that you want to do that? Sure. I am trying to port some code I wrote to implement text-transform for the maintenance branch over to the trunk. One of the key things there is to tie together all FOText objects that are part of the same Block, so that word boundaries are respected regardless of the markup. The way I implemented this was to keep finding ancestors until I came to a Block. I can't do that without the reference to the parent. It is not a high priority thing, but I am trying to finish up all of the stuff I started in the maintenance branch. Should've read this earlier. This sounds more like a layout thing. If you are going to find complete words to do some manipulation then I would suggest taking a look at the getWordChars method in the layout managers. This is used to gather together all strings in from different layout managers, eg. when there is a inline fo. At the moment it is meant for hyphenation. The exact implementation for this may change but that is the general idea. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF Encryption in HEAD
That's why I didn't commit the patch: I didn't want to re-add the PDFDocument reference to PDFXObject in order to get the add the encryption filter after the makeStream() without asking why the reference had been dropped on the way from maintenance to HEAD. The PDFDocument was used in the constructor to create ICCStreams for jpeg images. This seemed all to specific and was moved to the setup for the FopPDFImage. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Build problems... please help/advise...
Hi, I'm new to FOP, just joined the mailing list and I'm not sure what exactly is going on so I'd *really* appreciate it if someone could explain how to build FOP from the latest src (if it is even possible). I've been unable to build FOP from the src archive as of 3/11. A couple of the error messages I get are: I just did a build and it seems fine. The problem appears to be the version of batik that you have in the classpath. The batik javadocs you are refering to below are from june and are probably outdated. Make sure you are using the version of batik from cvs and there is no other batik in the classpath. [javac] /Users/bkylberg/Projects/xml-fop/src/java/org/apache/fop/image/ analyser/SVGReader.java:204: Method createSVGDocument(java.lang.String, java.io.InputStream) not found in class org.apache.batik.dom.svg.SAXSVGDocumentFactory [javac] SVGDocument doc = (SVGDocument) factory.createSVGDocument(uri, fis); [javac] /Users/bkylberg/Projects/xml-fop/src/java/org/apache/fop/render/ps/ PSTextPainter.java:93: class org.apache.fop.render.ps.PSTextPainter must be declared abstract. It does not define java.awt.geom.Rectangle2D getBounds(org.apache.batik.gvt.TextNode) from interface org.apache.batik.gvt.TextPainter. and so on until the build fails... The first error can be corrected by calling createDocument instead of createSVGDocument. createSVGDocument is an undefined API on SAXSVGDocumentFactory so I'm not sure how anyone has been able to compile this (ref: http://xml.apache.org/batik/javadoc/org/apache/batik/dom/svg/ SAXSVGDocumentFactory.html ). The second error is due to the fact that PSTextPainter claims to implement TextPainter (ref: http://xml.apache.org/batik/javadoc/org/apache/batik/gvt/ TextPainter.html ) but is in fact missing API implementations, among which getBounds is one. In fact I believe the implementation of PSTextPainter.getOutline(TextNode node) is altogether wrong insofar as PROXY_PAINTER isa StrokingTextPainter whose getOutline method takes a TextNode *and* a boolean (ref: http://xml.apache.org/batik/javadoc/org/apache/batik/gvt/renderer/ StrokingTextPainter.html ). According to the mailing list archives PSTextPainter was recently submitted and added to the repository (ref: http://marc.theaimsgroup.com/?l=fop-devm=104737262930539w=2 and http://marc.theaimsgroup.com/?l=fop-devm=104735385419249w=2 ). Perhaps everyone is using a different version of Java than I am ;-) but if not, then I'm wondering how anyone is able to build FOP given these defects? Am I the only one whose tried to build FOP from scratch in the past 2 days? Any advice would be greatly appreciated. -- Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Transcoders
As there is likely to be a batik beta release sometime soon what does everyone feel about having at least a PDF transcoder release. A PS transcoder would be good if it is working okay (I have no PS viewer at the moment). Doing a release doesn't really depend on batik from our end. So if we can make a release and then make that available to batik. We will need to make a cvs tag. It will need to be decided within the next few days. Heres my +1 So what do others think. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF Encryption in HEAD
The encryption filter uses the number and generation as part of the hash to generate the key for a given object. In short, the encryption key is different for every object and is based on the number and generation of the object. I would have preferred something simpler but the PDFXObject is not what is streamed. It was the PDFICCStream which does not have the number and generation properly set. If someone has a suitable example with the various image formats, I will test, verify and correct an issues. Try the example in test/resources/fop/image/types.fo this has various image formats. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Conversion from src/org.. to src/java/org..
I'm in major refactoring mode/mood. :-) So I would like to finally make the long due move from src/org/.. to src/java/org. We've discussed it more than once and we didn't come to an end. So I would like to propose the following: We remove the files normally using CVS commands and readd them in the new locations. I only want to do that in the trunk, not in the maintenance branch. Result: - No CVS surgery - Ability to fully restore a state - We lose the ability to diff a file using CVS any further back than when the move has taken place. (I think we can live with that.) My main motivations for the move as such: - Easier handling of FOP in IDEs - Best practices confirmance - Finish what we (I) started If you guys agree with that, I will do the move someday next week (during daytime CET). I will announce the start and the end of the move so we don't have to clean up if someone commits anything in between. Here's my +1. +1 If the vote fails, I would like a volunteer who comes up with a new proposal, we vote again and this person does the change. Timeframe: max. 2 weeks. If this sounds like blackmail, it's not intended. I just want to push the process forward. I don't want to discourage -1s. As an option, we can also agree to do the same in the maintenance branch, but since it's finally about to trail off (or so I hope). I've realised today, that the new src/java-1.x directories make it virtually impossible to compile FOP in Eclipse without the the move to src/java. -0 from me, but I'd volunteer to do the move nonetheless. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hyphenation patterns
Keiron, I assume it was you who wrote two of the mails and put the notifications on the Wiki page? With only the IP address it's difficult to tell (you can register your name in Preferences. Nudge, nudge). Was it Togan, you contacted or one of the other two? Not that we write to the same people twice. Thanks Sorry about that, still trying to sort out how this wiki stuff works. Yes, I sent mails to the email for those who submitted the files. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encryption
Peter, Keiron: how is the web site updated? I thought there was a cron job every few hours? Currently it only updates the site here: http://forrestbot.cocoondev.com (seems to be down at the moment) From this site you can update the main site by entering the correct name/password, I'll send offlist. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: inline-container support
Hi Peter, For the inline-container all it does is return one or more inline viewport areas. I think, but need to check, that it only can create more than one viewport if the IPD of the contents is perpendicular to the parent IPD. This ensures that the areas a properly ordered. If the IPD is the same as the parent then there cannot be inline areas after the inline-container viewport unless the inline-container is finished in which case only one viewport will be created. The viewport/reference areas are almost the same as for images and instream foreign objects. Inside the reference area will be the block areas from the child block FO's stacked in the BPD. The IPD is either set or has a maximum of the parent IPD. So to find the dimensions of the inline container it needs to layout the child block areas and get the result. I'm not sure what you mean by pass line-areas back up to a parent as the child areas of the inline container are not passed up. This is a different situation than when there are blocks inside and fo:inline. Could you spell this out in a bit more detail if possible? I am also interested in how the inline-area copes with having to pass line-areas back up to a parent. I am thinking of the interpretation we developed on the basis of the clarification of the behaviour of various inline FOs. -- Peter B. West [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Batik Extension/FOP problem
Hi All, I am trying to use batik extensions through FOP. I added BatikElementMapping and BatikObj objects into my FOP src and then registered them in the driver class but I am still getting some exceptions. Can anybody help me out ? I am trying to embed the flowText.svg ( provided by batik distribution ) into a simple fo document and then trying to convert into a pdf. As the exception is happening in batik it may be a version problem. Have you tried with the latest FOP rc. Swapan. [ERROR] svg graphic could not be built: null java.lang.ClassCastException at org.apache.batik.bridge.CSSUtilities.getComputedStyle(CSSUtilities.java:96) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation sitemap.xmap
keiron 2003/03/06 22:15:15
Modified:src/documentation sitemap.xmap
Log:
updated to latest forrest sitemap 1.71
Revision ChangesPath
1.11 +795 -531 xml-fop/src/documentation/sitemap.xmap
Index: sitemap.xmap
===
RCS file: /home/cvs/xml-fop/src/documentation/sitemap.xmap,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- sitemap.xmap 27 Dec 2002 10:04:11 - 1.10
+++ sitemap.xmap 7 Mar 2003 06:15:14 - 1.11
@@ -1,85 +1,96 @@
?xml version=1.0?
-
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
-
!-- === Components --
+ map:components
+ map:generators default=file
+ map:generator name=file
src=org.apache.cocoon.generation.FileGenerator label=content /
+
+ map:generator name=directory
src=org.apache.cocoon.generation.DirectoryGenerator label=content /
+
+ map:generator name=html
src=org.apache.cocoon.generation.HTMLGenerator label=content /
+
+ map:generator name=libre
src=org.apache.forrest.yer.use.cocoon.HierarchyGenerator label=content /
+
+ map:generator name=nekodtd
src=org.apache.forrest.components.generator.XNIConfigurableFileGenerator
label=content /
+
+ map:generator name=textparser
src=org.apache.cocoon.generation.TextParserGenerator label=content /
+
+!-- FIXME: Change this once better view handling is implemented --
+ map:generator name=file-nolabel
src=org.apache.cocoon.generation.FileGenerator /
+ /map:generators
+
+ map:transformers default=xslt
+ map:transformer name=idgen
src=org.apache.cocoon.transformation.IdGeneratorTransformer
+element//*[local-name() = 'section']/element
+idtitle/text()/id
+ /map:transformer
+
+ map:transformer name=linkrewriter
src=org.apache.cocoon.transformation.LinkRewriterTransformer
+input-module name=linkmap src={src} reloadable=true /
+input-module name=site
+ input-module name=linkmap src={src} reloadable=true /
+ prefix/site///prefix
+ suffix/@href/suffix
+/input-module
+ /map:transformer
+
+ map:transformer name=xpath logger=sitemap.transformer.xpath
src=org.apache.cocoon.transformation.XPathTransformer /
+
+ map:transformer name=xslt
src=org.apache.cocoon.transformation.TraxTransformer
logger=sitemap.transformer.xsltc pool-max=32 pool-min=8 pool-grow=2
+use-request-parametersfalse/use-request-parameters
+use-browser-capabilities-dbfalse/use-browser-capabilities-db
+use-delifalse/use-deli
+!-- transformer-factorycom.icl.saxon.TransformerFactoryImpl/transformer-factory
--
+!--
transformer-factoryorg.apache.xalan.xsltc.trax.TransformerFactoryImpl/transformer-factory
--
+ /map:transformer
+
+ map:transformer name=xinclude
src=org.apache.cocoon.transformation.XIncludeTransformer
logger=sitemap.transformer.xinclude pool-grow=2 pool-max=16 pool-min=2 /
+ /map:transformers
+
+ map:readers default=resource
+ map:reader name=resource src=org.apache.cocoon.reading.ResourceReader
/
+ /map:readers
+
+ map:serializers default=html
+ map:serializer name=html mime-type=text/html
src=org.apache.cocoon.serialization.HTMLSerializer
+doctype-public-//W3C//DTD HTML 4.01 Transitional//EN/doctype-public
+doctype-systemhttp://www.w3.org/TR/html4/loose.dtd/doctype-system
+encodingISO-8859-1/encoding
+ /map:serializer
+
+ map:serializer name=xml mime-type=text/xml
src=org.apache.cocoon.serialization.XMLSerializer
+encodingISO-8859-1/encoding
+ /map:serializer
+
+ map:serializer name=rss091 mime-type=text/xml
src=org.apache.cocoon.serialization.XMLSerializer
+doctype-public-//Netscape Communications//DTD RSS
0.91//EN/doctype-public
+
doctype-systemhttp://my.netscape.com/publish/formats/rss-0.91.dtd/doctype-system
+encodingISO-8859-1/encoding
+ /map:serializer
+
+ map:serializer name=fo2pdf
src=org.apache.cocoon.serialization.FOPSerializer mime-type=application/pdf /
+
+ map:serializer name=links
src=org.apache.cocoon.serialization.LinkSerializer
+encodingISO-8859-1/encoding
+ /map:serializer
+
+ map:serializer name=svg2jpeg mime-type=image/jpeg
src=org.apache.cocoon.serialization.SVGSerializer
+parameter name=quality type=float value=1.0 /
+ /map:serializer
- map:components
-
- map:generators default=file
- map:generator name=file
src
Re: batik transcoders
Hi Jeremias, You mean Batik will have pdf-transcoder.jar and ps-transcoder.jar in their distributions? Not the source, right? That is correct. What about factoring out the code for the transcoders and supporting classes (like fonts) into a separate container/subproject accessible by both the FOP and Batik teams? XML-Commons, maybe? That way we could encourage the Batik guys to participate in the future development of the PDF- and PS-related SVG stuff. Just a thought. That could be a good idea for the future. For the short term just a bundling. So will there be any problems. There is th/e pdf-transcoder build target that creates the transcoder jar. We could create a tag for the release (call it beta2?). We do need to make it clear that a FOP release cannot be used at the same time as this jar due to various changes. +1. We could give the transcoders a bit more visibility on our site. The PDF transcoder seems to be working fine. There are a couple of problems. Issues: - the use of avalon Enumeration requires avalon in the path. It is only used as an interface for one of the font classes, do we really need that Not really at the moment. But as soon as I have this licensing issues and an initial release of my barcode package behind me, I wanted to go into full Avalon-refactoring mode. And that brings some more Avalon stuff into FOP especially the renderers, fonts and image support. Thats fine. I'd like to propose this: - I'll modify the build so we can generate a raw pdf-transcoder.jar as it is now (needs avalon-framework.jar), but along with another (pdf-transcoder-all.jar) that also contains the necessary Avalon classes. - I'll do the documentation involved. Okay. - do we need all of the font classes for transcoding, which ones can be left out ATM the PFM parser and the apps subpackage are the only ones that can be left out, I think. There are some minor bugs with patterns in patterns, drawing images and fonts but there won't be any fixes soon. Wouldn't it make sense to work with the Batik team to get the PDF and PS transcoders into their test infrastructure so we have some good feedback and can quickly improve on the quality to match the AWT output? If I understand their testing properly, it is currently no setup in a way that could handle PDF/PS output. They have various levels of testing: xml parsing, dom, bridge, gvt, image output and various others. The image output is the one that is parallel with the PDF/PS transcoding, it is done by comparing the result with a reference image stored in cvs. Someone needs to know what the reference should be like. Also there are PDF version/viewer version issues. I'll see what can be sorted out. Also what is the status of the PS transcoder? Could this be included. I haven't set up the PS transcoder, yet. But I could do that soon. I'm still hoping for George to send in a patch for his PostScript work. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: inline-container support
Hi Jens, Hi! I've got a fo-task for which I need a working fo:inline-container-object. This feature seems not to be implemented in the 0.20.x-version. I would like to know weather support for this element is planned for the coming versions (maintenance or redesigned-branch). Are any milestones planned? In the redesign it is not planned as such but we do want to implement it. Would it be possible / difficult to take part in the implementation-process myself if no support is planned? Do you want to get started on implementing it in the redesign? What we will need is an InlineContainerLayoutManager that returns a single inline object as with other layout managers such as image. The inline-container area will have width, height and alignment. The renderers will need to handle the inline container, this might already be done but it wouldn't be tested. Inside the inline container it will need to find all the breaks and then to calculate the height. The IPD must be fixed and this will be passed down to the child layout managers. Once it has all the breaks all it need to do is set the height. When the areas are added it will get all the child LM's to add there areas from the breaks, then it will add the inline container to the parent and do the alignment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
batik transcoders
Hi All, The PDF transcoder could be packaged with Batik so that it can be used by users of Batik only and also used independanlty from the rest of FOP. So will there be any problems. There is the pdf-transcoder build target that creates the transcoder jar. We could create a tag for the release (call it beta2?). We do need to make it clear that a FOP release cannot be used at the same time as this jar due to various changes. The PDF transcoder seems to be working fine. There are a couple of problems. Issues: - the use of avalon Enumeration requires avalon in the path. It is only used as an interface for one of the font classes, do we really need that - do we need all of the font classes for transcoding, which ones can be left out There are some minor bugs with patterns in patterns, drawing images and fonts but there won't be any fixes soon. Also what is the status of the PS transcoder? Could this be included. Keiron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
This still leaves the question: Does a block with a break-before=page or a break-after=page span two pages, or will it always be the first/last area on the page its content is rendered on? Examples fo:block id=A fo:marker marker-class=I id=m1/ fo:block id=B break-after=page fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Does last-ending-within-page retrieve m1 or m2? I'd think m2. The area from block A will always be a parent of the area from block B. So surely that after block B ends then the containing block A will end. The forced break only tells us that we should force a break at that position otherwise it is the same as a normal break. fo:block id=A break-after=page fo:marker marker-class=I id=m1/ fo:block id=B fo:marker marker-class=I id=m2/ ... /fo:block /fo:block Does last-ending-within-page retrieve m1 or m2? Probably m1, but where in the spec can I find backing for this opinion? Look in 4.2.5 Stacking constraints. In the diagram case 2, A is before B. So that in your example the after edge of block A is after the after edge of block B, so m1. Keiron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/layoutmgr/table Body.java Caption.java Cell.java Row.java TableAndCaptionLayoutManager.java TableLayoutManager.java
keiron 2003/03/03 19:48:09
Modified:src/org/apache/fop/layoutmgr AbstractLayoutManager.java
BlockContainerLayoutManager.java
BlockLayoutManager.java
BlockStackingLayoutManager.java BreakPoss.java
BreakPossPosIter.java ContentLayoutManager.java
FlowLayoutManager.java
InlineStackingLayoutManager.java LayoutManager.java
LeafPosition.java LineLayoutManager.java
NonLeafPosition.java PageLayoutManager.java
Position.java PositionIterator.java
RetrieveMarkerLayoutManager.java
StaticContentLayoutManager.java
src/org/apache/fop/layoutmgr/list Item.java
ListBlockLayoutManager.java
ListItemLayoutManager.java
src/org/apache/fop/layoutmgr/table Body.java Caption.java
Cell.java Row.java
TableAndCaptionLayoutManager.java
TableLayoutManager.java
Added: src/org/apache/fop/layoutmgr LayoutProcessor.java
Log:
split LayoutManager interface so that the new LayoutProcessor
interface is the local interface used by the implementation
to do the layout
Revision ChangesPath
1.23 +9 -9 xml-fop/src/org/apache/fop/layoutmgr/AbstractLayoutManager.java
Index: AbstractLayoutManager.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/AbstractLayoutManager.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- AbstractLayoutManager.java27 Feb 2003 23:30:48 - 1.22
+++ AbstractLayoutManager.java4 Mar 2003 03:48:08 - 1.23
@@ -23,16 +23,16 @@
/**
* The base class for all LayoutManagers.
*/
-public abstract class AbstractLayoutManager implements LayoutManager {
+public abstract class AbstractLayoutManager implements LayoutProcessor {
protected FOUserAgent userAgent;
-protected LayoutManager parentLM = null;
+protected LayoutProcessor parentLM = null;
protected FObj fobj;
protected String foID = null;
protected Map markers = null;
/** True if this LayoutManager has handled all of its content. */
private boolean bFinished = false;
-protected LayoutManager curChildLM = null;
+protected LayoutProcessor curChildLM = null;
protected ListIterator childLMiter;
protected boolean bInited = false;
@@ -76,7 +76,7 @@
return userAgent.getLogger();
}
-public void setParentLM(LayoutManager lm) {
+public void setParent(LayoutProcessor lm) {
this.parentLM = lm;
}
@@ -128,14 +128,14 @@
* Note: child must implement LayoutManager! If it doesn't, skip it
* and print a warning.
*/
-protected LayoutManager getChildLM() {
+protected LayoutProcessor getChildLM() {
if (curChildLM != null !curChildLM.isFinished()) {
return curChildLM;
}
while (childLMiter.hasNext()) {
-curChildLM = (LayoutManager) childLMiter.next();
+curChildLM = (LayoutProcessor) childLMiter.next();
curChildLM.setUserAgent(getUserAgent());
-curChildLM.setParentLM(this);
+curChildLM.setParent(this);
curChildLM.init();
return curChildLM;
}
@@ -172,7 +172,7 @@
}
while (curChildLM != lm childLMiter.hasPrevious()) {
curChildLM.resetPosition(null);
-curChildLM = (LayoutManager) childLMiter.previous();
+curChildLM = (LayoutProcessor) childLMiter.previous();
}
// Otherwise next returns same object
childLMiter.next();
1.12 +4 -4
xml-fop/src/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java
Index: BlockContainerLayoutManager.java
===
RCS file:
/home/cvs/xml-fop/src/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- BlockContainerLayoutManager.java 27 Feb 2003 23:30:49 - 1.11
+++ BlockContainerLayoutManager.java 4 Mar 2003 03:48:08 - 1.12
@@ -98,7 +98,7 @@
stackLimit = context.getStackLimit();
}
-LayoutManager curLM ; // currently active LM
+LayoutProcessor curLM ; // currently active LM
MinOptMax stackSize = new MinOptMax();
// if starting add space before
@@ -156,7 +156,7 @@
public BreakPoss
cvs commit: xml-fop/src/org/apache/fop/fo/flow BasicLink.java BidiOverride.java PageNumberCitation.java
keiron 2003/03/03 19:50:54
Modified:src/org/apache/fop/fo/flow BasicLink.java BidiOverride.java
PageNumberCitation.java
Log:
updated for LayoutProcessor
Revision ChangesPath
1.20 +9 -3 xml-fop/src/org/apache/fop/fo/flow/BasicLink.java
Index: BasicLink.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/BasicLink.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- BasicLink.java14 Feb 2003 04:15:03 - 1.19
+++ BasicLink.java4 Mar 2003 03:50:54 - 1.20
@@ -22,7 +22,7 @@
import org.apache.fop.area.Area;
import org.apache.fop.layoutmgr.InlineStackingLayoutManager;
import org.apache.fop.layoutmgr.LMiter;
-import org.apache.fop.layoutmgr.LayoutManager;
+import org.apache.fop.layoutmgr.LayoutProcessor;
// Java
import java.util.List;
@@ -58,7 +58,7 @@
lms.add(lm);
}
-protected void setupLinkArea(LayoutManager parentLM, InlineParent area) {
+protected void setupLinkArea(LayoutProcessor parentLM, InlineParent area) {
if (link == null) {
return;
}
@@ -137,6 +137,12 @@
private String idRef;
private Area area;
+/**
+ * Create a new link resolver.
+ *
+ * @param id the id to resolve
+ * @param a the area that will have the link attribute
+ */
public LinkResolver(String id, Area a) {
idRef = id;
area = a;
1.13 +6 -9 xml-fop/src/org/apache/fop/fo/flow/BidiOverride.java
Index: BidiOverride.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/BidiOverride.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- BidiOverride.java 14 Feb 2003 04:15:03 - 1.12
+++ BidiOverride.java 4 Mar 2003 03:50:54 - 1.13
@@ -8,17 +8,14 @@
package org.apache.fop.fo.flow;
// FOP
-import org.apache.fop.fo.*;
+import org.apache.fop.fo.FONode;
+import org.apache.fop.fo.FObjMixed;
import org.apache.fop.layout.AuralProps;
import org.apache.fop.layout.RelativePositionProps;
-import org.apache.fop.fo.flow.*;
-import org.apache.fop.fo.properties.*;
-import org.apache.fop.apps.FOPException;
import org.apache.fop.layoutmgr.LeafNodeLayoutManager;
-import org.apache.fop.layoutmgr.LayoutManager;
+import org.apache.fop.layoutmgr.LayoutProcessor;
import org.apache.fop.area.inline.InlineArea;
-import org.apache.fop.area.inline.Word;
import java.util.List;
import java.util.ArrayList;
@@ -38,9 +35,9 @@
ArrayList childList = new ArrayList();
super.addLayoutManager(childList);
for (int count = childList.size() - 1; count = 0; count--) {
-LayoutManager lm = (LayoutManager) childList.get(count);
+LayoutProcessor lm = (LayoutProcessor) childList.get(count);
if (lm.generatesInlineAreas()) {
-LayoutManager blm = new
BidiLayoutManager((LeafNodeLayoutManager) lm);
+LayoutProcessor blm = new
BidiLayoutManager((LeafNodeLayoutManager) lm);
blm.setFObj(this);
list.add(blm);
} else {
1.29 +25 -19xml-fop/src/org/apache/fop/fo/flow/PageNumberCitation.java
Index: PageNumberCitation.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/PageNumberCitation.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- PageNumberCitation.java 14 Feb 2003 04:15:04 - 1.28
+++ PageNumberCitation.java 4 Mar 2003 03:50:54 - 1.29
@@ -8,27 +8,33 @@
package org.apache.fop.fo.flow;
// FOP
-import org.apache.fop.fo.*;
-import org.apache.fop.fo.pagination.*;
-import org.apache.fop.datatypes.*;
-import org.apache.fop.fo.properties.*;
-import org.apache.fop.layout.*;
-import org.apache.fop.apps.FOPException;
-import org.apache.fop.layoutmgr.LeafNodeLayoutManager;
-import org.apache.fop.area.inline.InlineArea;
-import org.apache.fop.area.PageViewport;
-import org.apache.fop.util.CharUtilities;
+import java.util.List;
+
import org.apache.fop.apps.StructureHandler;
+import org.apache.fop.area.PageViewport;
+import org.apache.fop.area.Resolveable;
+import org.apache.fop.area.Trait;
+import org.apache.fop.area.inline.InlineArea;
+import org.apache.fop.area.inline.UnresolvedPageNumber;
+import org.apache.fop.area.inline.Word;
+import org.apache.fop.datatypes.ColorType;
+import org.apache.fop.fo.FONode;
+import org.apache.fop.fo.FObj
cvs commit: xml-fop/src/org/apache/fop/fo/flow Leader.java
keiron 2003/03/03 19:55:54 Modified:src/org/apache/fop/fo Title.java src/org/apache/fop/fo/flow Leader.java Log: fixed for changed method Revision ChangesPath 1.14 +12 -11xml-fop/src/org/apache/fop/fo/Title.java Index: Title.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Title.java,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- Title.java14 Feb 2003 04:15:03 - 1.13 +++ Title.java4 Mar 2003 03:55:54 - 1.14 @@ -8,16 +8,17 @@ package org.apache.fop.fo; // FOP -import org.apache.fop.fo.*; -import org.apache.fop.datatypes.*; -import org.apache.fop.layout.*; -import org.apache.fop.fo.flow.*; -import org.apache.fop.fo.properties.*; -import org.apache.fop.apps.FOPException; - -import org.apache.fop.layoutmgr.LMiter; -import org.apache.fop.layoutmgr.InlineStackingLayoutManager; +import org.apache.fop.datatypes.ColorType; +import org.apache.fop.datatypes.Length; +import org.apache.fop.layout.AccessibilityProps; +import org.apache.fop.layout.AuralProps; +import org.apache.fop.layout.BackgroundProps; +import org.apache.fop.layout.BorderAndPadding; +import org.apache.fop.layout.FontState; +import org.apache.fop.layout.MarginInlineProps; import org.apache.fop.layoutmgr.ContentLayoutManager; +import org.apache.fop.layoutmgr.InlineStackingLayoutManager; +import org.apache.fop.layoutmgr.LMiter; /** */ @@ -43,7 +44,7 @@ ContentLayoutManager clm = new ContentLayoutManager(title); clm.setUserAgent(getUserAgent()); -lm.setParentLM(clm); +lm.setParent(clm); clm.fillArea(lm); 1.33 +25 -20xml-fop/src/org/apache/fop/fo/flow/Leader.java Index: Leader.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Leader.java,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- Leader.java 14 Feb 2003 04:15:04 - 1.32 +++ Leader.java 4 Mar 2003 03:55:54 - 1.33 @@ -8,30 +8,35 @@ package org.apache.fop.fo.flow; // FOP -import org.apache.fop.fo.*; -import org.apache.fop.fo.properties.*; -import org.apache.fop.datatypes.*; +import java.util.List; + +import org.apache.fop.apps.StructureHandler; +import org.apache.fop.area.Trait; +import org.apache.fop.area.inline.FilledArea; import org.apache.fop.area.inline.InlineArea; -import org.apache.fop.layout.*; +import org.apache.fop.area.inline.Space; +import org.apache.fop.area.inline.Word; +import org.apache.fop.datatypes.ColorType; +import org.apache.fop.datatypes.Length; +import org.apache.fop.datatypes.PercentLength; +import org.apache.fop.fo.FONode; +import org.apache.fop.fo.FObjMixed; +import org.apache.fop.fo.properties.LeaderPattern; +import org.apache.fop.layout.AccessibilityProps; +import org.apache.fop.layout.AuralProps; +import org.apache.fop.layout.BackgroundProps; +import org.apache.fop.layout.BorderAndPadding; +import org.apache.fop.layout.FontInfo; import org.apache.fop.layout.FontState; -import org.apache.fop.apps.FOPException; -import org.apache.fop.layoutmgr.LayoutManager; -import org.apache.fop.layoutmgr.InlineStackingLayoutManager; -import org.apache.fop.layoutmgr.LeafNodeLayoutManager; +import org.apache.fop.layout.MarginInlineProps; +import org.apache.fop.layout.RelativePositionProps; import org.apache.fop.layoutmgr.ContentLayoutManager; -import org.apache.fop.layoutmgr.LayoutContext; +import org.apache.fop.layoutmgr.InlineStackingLayoutManager; import org.apache.fop.layoutmgr.LMiter; +import org.apache.fop.layoutmgr.LayoutContext; +import org.apache.fop.layoutmgr.LeafNodeLayoutManager; import org.apache.fop.layoutmgr.MinOptMax; -import org.apache.fop.area.inline.Space; -import org.apache.fop.area.inline.Word; -import org.apache.fop.area.inline.InlineParent; -import org.apache.fop.area.inline.FilledArea; import org.apache.fop.util.CharUtilities; -import org.apache.fop.apps.StructureHandler; -import org.apache.fop.area.Trait; - -import java.util.List; -import java.util.ArrayList; /** * Implements fo:leader; main property of leader leader-pattern. @@ -134,7 +139,7 @@ ContentLayoutManager clm = new ContentLayoutManager(fa); clm.setUserAgent(getUserAgent()); -lm.setParentLM(clm); +lm.setParent(clm); clm.fillArea(lm); int width = clm.getStackingSize(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A weekly/monthly redesign bulletin? (Was: keep propery)
Jeremias Maerki [EMAIL PROTECTED]: ... Check the FOP website regularly for the status of the redesign. To stave off the biggest FOP FAQ after doesn't keep-* work in Fop?, ie. what's the schedule for the redesign?, could it perhaps be an idea to post a weekly bulletin on the devel list? Just a very short message eg. something like this: Subject: FOP redesign bulletin, week #30, 2003 Work done this week: - improvement of font metrics - made to work with IBM Java VM - blah. blah. Work planned for next week: - make it work with gcj FYII just got a patched gcj 3.3 (compiling an exe) working with a cutdown of the code. I think that gcj needs some work before it will be really useful. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/layoutmgr AbstractLayoutManager.java LayoutManager.java BlockLayoutManager.java BlockContainerLayoutManager.java StaticContentLayoutManager.java PageLayoutManager.java ContentLayoutManager.java
keiron 2003/02/27 15:30:51
Modified:src/org/apache/fop/area PageViewport.java
src/org/apache/fop/layoutmgr AbstractLayoutManager.java
LayoutManager.java BlockLayoutManager.java
BlockContainerLayoutManager.java
StaticContentLayoutManager.java
PageLayoutManager.java ContentLayoutManager.java
Log:
improvement on markers, don't know if it is correct
Revision ChangesPath
1.15 +68 -43xml-fop/src/org/apache/fop/area/PageViewport.java
Index: PageViewport.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/PageViewport.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- PageViewport.java 20 Feb 2003 02:47:44 - 1.14
+++ PageViewport.java 27 Feb 2003 23:30:47 - 1.15
@@ -47,8 +47,9 @@
// start and end are added by the fo that contains the markers
private Map markerFirstStart = null;
private Map markerLastStart = null;
-private Map markerFirstEnd = null;
+private Map markerFirstAny = null;
private Map markerLastEnd = null;
+private Map markerLastAny = null;
/**
* Create a page viewport.
@@ -185,8 +186,8 @@
* For first-starting-within-page it adds the markers
* that are starting only if the marker class name is not
* already added.
- * For first-including-carryover it adds any marker if
- * the marker class name is not already added.
+ * For first-including-carryover it adds any starting marker
+ * if the marker class name is not already added.
* For last-starting-within-page it adds all marks that
* are starting, replacing earlier markers.
* For last-ending-within-page it adds all markers that
@@ -196,44 +197,58 @@
*
* @param marks the map of markers to add
* @param start if the area being added is starting or ending
+ * @param isfirst isfirst or islast flag
*/
-public void addMarkers(Map marks, boolean start) {
+public void addMarkers(Map marks, boolean start, boolean isfirst) {
if (start) {
-if (markerFirstStart == null) {
-markerFirstStart = new HashMap();
-}
-if (markerLastStart == null) {
-markerLastStart = new HashMap();
-}
-if (markerFirstEnd == null) {
-markerFirstEnd = new HashMap();
-}
-// only put in new values, leave current
-for (Iterator iter = marks.keySet().iterator(); iter.hasNext();) {
-Object key = iter.next();
-if (!markerFirstStart.containsKey(key)) {
-markerFirstStart.put(key, marks.get(key));
+if (isfirst) {
+if (markerFirstStart == null) {
+markerFirstStart = new HashMap();
}
-if (!markerFirstEnd.containsKey(key)) {
-markerFirstEnd.put(key, marks.get(key));
+if (markerFirstAny == null) {
+markerFirstAny = new HashMap();
+}
+// only put in new values, leave current
+for (Iterator iter = marks.keySet().iterator(); iter.hasNext();) {
+Object key = iter.next();
+if (!markerFirstStart.containsKey(key)) {
+markerFirstStart.put(key, marks.get(key));
+}
+if (!markerFirstAny.containsKey(key)) {
+markerFirstAny.put(key, marks.get(key));
+}
+}
+if (markerLastStart == null) {
+markerLastStart = new HashMap();
+}
+// replace all
+markerLastStart.putAll(marks);
+
+} else {
+if (markerFirstAny == null) {
+markerFirstAny = new HashMap();
+}
+// only put in new values, leave current
+for (Iterator iter = marks.keySet().iterator(); iter.hasNext();) {
+Object key = iter.next();
+if (!markerFirstAny.containsKey(key)) {
+markerFirstAny.put(key, marks.get(key));
+}
}
}
-markerLastStart.putAll(marks);
} else {
-if (markerFirstEnd == null) {
-markerFirstEnd = new HashMap();
-}
-if (markerLastEnd == null) {
-markerLastEnd = new HashMap();
-}
-// only put in new values, leave current
Re: markers in redesign
Hi all, I think I am getting an idea of the markers with Peter's and others points but I don't fully understand how it should work or be implemented. Anyway I have committed the code of how it might roughly work and hopefully it is correct for the containing page. It isn't that much code anyway, it is mainly a matter of getting the logic right. When we know how it definitely should work then we can adjust it if necessary. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Wrong operand type error in ASV 3.0
!-- If I remove this line, everything seems to work fine -- svg:line x1=58 y1=179 x2=403 y2=179 stroke=#00 stroke- width=0.5 / IIRC It is probably an error caused by this line being 0.5 width. In PDF lines can only be whole numbers and it might wrongly be inserting 0.5 in the PDF causing the error. Try making it width 1. If you need a 0.5 width line it can be scaled. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
layout manager interface
Hi all, In order to make things more modular I would like to split the layout manager interface into two parts. One part that is used in the creation from the FO tree and another that is used by the implementations in order to do the actual layout. This should eventually make it possible to have different layout implementations. For now it shoud help make it a bit clearer and I want to have a go at trying the ideas I have for doing the layout in a slightly different way. I will call it LayoutProcessor unless there is a better idea. Any objections? Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: layout manager interface
Keiron Liddle wrote: Hi all, In order to make things more modular I would like to split the layout manager interface into two parts. One part that is used in the creation from the FO tree and another that is used by the implementations in order to do the actual layout. See my notes on the relationship between FO tree buildng and layout. In my view, the FO expressions cannot, in certain circumstances, and therefore in general, be *parsed* until the layout of their enclosing areas has occurred. The description in the spec of discrete processes of FO tree and area tree building is simply wrong and grossly misleading. I have had a quick read and there should be no problem. This doesn't effect what the layout manager implementations see, only what the FO tree sees when creating the managers. If you need to put a call back or call a method on the FO tree it will still be possible. As long as the information path from the layout implementation back through the FO tree/layout interface to the FO tree builder is defined. It will remain as possible as it is know. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
But the marker subtree from the previous page is tranposed into the same containing page. Where do you get that from, how is it transposed, I have not seen any information about this? Considering all the retrieve positions refer to areas in the containing page then these markers transposed from a previous page are not attached to areas in the containing page. Are you agreeing then that if it cannot find it on the current page it should look an the previous page and so on, or does this transposing do something else. Another point, why have this statement: A qualifying area within a page is better than any qualifying area within a preceding page, Unless it is possible that if there is no qualifying marker on the current page then it is possible to retrieve a marker from a preceding page. Yes, it is possible, but again, the qualifying marker on a previous page will be transposed to the containing page - the page whose fo:retrieve-marker started all the trouble. The rest of the above-quoted sentence, following the comma, is: ...except that areas do not have a position in the hierarchy if they are within pages that follow the containing page. In my reading, the implication is that the containing page is an absolute point of reference - the page in which the fo:retrieve-marker accurs. Yes, one of the many contradictions. I presume you mean where the fo:retrieve- marker is replaced with the retrieved marker (since it occurs on every page with that static content). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Looking at it again, I disagree. The containing page is the page containing the first area generated or returned by the children of the retrieved fo:marker. That is, the page on which the fo:retrieve-marker occurs in the static-content. This will only vary if the retrieval forces a re-layout. How do you jump from the first sentance to the second one. The containing page refers to the page where the marker is first formatted not where the retrieve-marker occurs. I vote for a clarification and a re-write, the containing page is defined by the retrieved marker, the marker to retrieve is defined by the containing page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Keiron, I haven't looked at markers too closely, but I would tend to think that, in the first case, block c is the last-starting-within-page. Blocks a, b and c all qualify; they all have an is-first trait of true. So which one follows all others in the area tree, *in pre-order traversal order*? Pre-order traversal gives us a, b, c. So c follows in the area tree any other similarly constrained area. So does b and c follow a, what is the definition of follows. I agree with your reasoning but we are talking about the spec. Just that off-hand statement about every area being better than an area below. I think they need to explain the implications of what the definitions are. If you think of last-starting as sort of the opposite of first-including-carryover (which doesn't need to have an is-last), then the parent a actually comes first. But that is only wild speculation. Then the column break would have no impact on the selection. It seems to me that the hierarchy is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. I think. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Exactly. All definitions regarding retrieve-position exclusively refer to the current page. There is not a single word on what should happen if there is no matching marker on the current page but several on the previous page which are eligible. FOP picks the last, but there is absolutely nothing in the spec which backs this, and I searched thoroughly last weekend. For the current page or containing page I take it to mean like so (assuming doc or page-sequence boundary): If we are on the third page of a document and we want to retrieve a first-starting- within-page then it will look on page 3, if it finds the marker then fine. If not then there is no such area (on the current page) and it should look at page 2. Page 2 is now the containing page and it looks for a marker that is first-starting-within- page on page 2. Then page 1... Admitedly it doesn't actually say that, but I can't interpret the wording otherwise. BTW for the page sequence retrieving scope there is a current page sequence casually mentioned but definition of the term is left to imagination, in contrast to the meticulous definition of current page. Additionally, some oddball examples for discussion and fun: fo:block fo:footnotefo:inline/fo:footnote-bodyfo:block fo:marker marker-class-name=foo/stuff/fo:block /fo:footnote-body/fo:footnote /fo:block fo:block fo:marker marker-class-name=foo/stuff /fo:block Isn't the footnote in an area that is after the main-reference area and hence last. Which one is the last? Similarly for fo:block-container position=absolute top=10cm left=0cm width=5cm height=5cm fo:marker marker-class-name=foo/fo:blockstufffo:block /fo:block-container fo:block-container position=absolute top=0cm left=0cm width=5cm height=5cm fo:marker marker-class-name=foo/fo:blockstufffo:block /fo:block-container Ordering stays, regardless of where it is drawn. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
I haven't looked at markers too closely, but I would tend to think that, in the first case, block c is the last-starting-within-page. Blocks a, b and c all qualify; they all have an is-first trait of true. So which one follows all others in the area tree, *in pre-order traversal order*? Pre-order traversal gives us a, b, c. So c follows in the area tree any other similarly constrained area. Then the column break would have no impact on the selection. I re-read that part and what you say makes sense now. It's all very confusing. It seems to me that the hierarchy is not the same as the area tree or fo tree hierarchy. It is a unique hierarchy constructed by applying the constraints on the qualifying areas. The boundary conditions impose absolute constraints - violate one and you are out. But the other conditions are not absolute, and they, along with actual page for multi-page boundaries, are used to construct the hierarchy. I think. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: markers in redesign
Hi all, Is it correct that it should look for markers on the current page and if page boundary is current page then stop there. If boundary is page-sequence then keep going backwards on each page until a marker is found or reaches the start of the page-sequence and similarly for the document boundary. I'm trying to work out exactly how the markers should work. For the first starting within page and last ending I am fine with. First including carry-over seems okay. Last starting within page is a bit confusing. A statement [1] in the spec suggests that it shouldn't really find the last starting in the page but rather find the closest node to the root in the area tree that is the last starting area. Another statement [2] seems confusing but maybe this is if it is searching previous pages. So if this was in a page then block a would be the last starting in the page. -start-- ... block id=a block id=b /block ---pos1- block id=c /block /block end--- But if there is a column break in pos1 the last starting in page will become block c as block a is not starting in that part of the area tree. If this is the case then there are two possible cases when starting an area: isfirst and other. When finishing an area there are: islast, (had) isfirst and both. This will supply enough information to add only the needed markers to the area tree. These markers can then be kept for later retrieval. [1] Every area in the hierarchy is considered preferential to, or better than, any area below it in the hierarchy. [2] If there is no such area, then the last qualifying area in the containing page is better than any other area. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns
[EMAIL PROTECTED] wrote: I am donating the hyphenation file to the ASF, and although it would be nice to keep the copyright, I think that would hamper future enhancements, or not? As long as you don't choose to revoke the license for all future and past versions (rather than forking or whatever), there wouldn't be a problem. This was recently extensively discussed on slashdot in response to an interview with a real lawyer. From a quick look at the contributors license (I couldn't find a link that works) it appears that when code is contributed to the ASF the copyright is granted to the ASF. THe contributor does reserve remaining rights, title and interest. I don't know if code contributed under this agreement is the same as code contributed with normal patches etc., maybe it is implied? Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: ready to go again
OK, I am ready to jump in do some work. Sorry for being out of action for so long. The threads that I would like to complete, or at least resolve, first, are: 1. Documentation. The main problem here is the web site generation, but it seemed to me that Peter and some others may have gotten that working. If so, is the readme doc up-to-date? (The last time I tried to run it, in December, the generation failed with errors). everything seems to be working fine on: http://forrestbot.cocoondev.org/ with only a couple of broken links. It is possible to update the site from the web interface (I haven't tried it) if you know the password. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/layoutmgr PageLayoutManager.java RetrieveMarkerLayoutManager.java BlockLayoutManager.java
keiron 2003/02/19 18:47:45
Modified:src/org/apache/fop/area AreaTree.java AreaTreeModel.java
PageViewport.java
src/org/apache/fop/layoutmgr PageLayoutManager.java
RetrieveMarkerLayoutManager.java
BlockLayoutManager.java
Log:
implement position and boundary for markers
Revision ChangesPath
1.15 +10 -1 xml-fop/src/org/apache/fop/area/AreaTree.java
Index: AreaTree.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/AreaTree.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- AreaTree.java 22 Dec 2002 22:40:31 - 1.14
+++ AreaTree.java 20 Feb 2003 02:47:44 - 1.15
@@ -73,6 +73,15 @@
}
/**
+ * Get the area tree model for this area tree.
+ *
+ * @return AreaTreeModel the model being used for this area tree
+ */
+public AreaTreeModel getAreaTreeModel() {
+return model;
+}
+
+/**
* Start a new page sequence.
* This signals that a new page sequence has started in the document.
* @param title the title of the new page sequence or null if no title
1.3 +33 -1 xml-fop/src/org/apache/fop/area/AreaTreeModel.java
Index: AreaTreeModel.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/AreaTreeModel.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AreaTreeModel.java23 Jan 2003 18:59:07 - 1.2
+++ AreaTreeModel.java20 Feb 2003 02:47:44 - 1.3
@@ -11,6 +11,9 @@
* This is the model for the area tree object.
* The model implementation can handle the page sequence,
* page and extensions.
+ * The mathods to acces the page viewports can only
+ * assume the PageViewport is valid as it remains for
+ * the life of the area tree model.
*/
public abstract class AreaTreeModel {
/**
@@ -36,4 +39,33 @@
* Signal the end of the document for any processing.
*/
public abstract void endDocument();
+
+/**
+ * Get the page sequence count.
+ * @return the number of page sequences in the document.
+ */
+public abstract int getPageSequenceCount();
+
+/**
+ * Get the title for a page sequence.
+ * @param count the page sequence count
+ * @return the title of the page sequence
+ */
+public abstract Title getTitle(int count);
+
+/**
+ * Get the page count.
+ * @param seq the page sequence to count.
+ * @return returns the number of pages in a page sequence
+ */
+public abstract int getPageCount(int seq);
+
+/**
+ * Get the page for a position in the document.
+ * @param seq the page sequence number
+ * @param count the page count in the sequence
+ * @return the PageViewport for the particular page
+ */
+public abstract PageViewport getPage(int seq, int count);
+
}
1.14 +84 -13xml-fop/src/org/apache/fop/area/PageViewport.java
Index: PageViewport.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/PageViewport.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- PageViewport.java 19 Feb 2003 05:43:24 - 1.13
+++ PageViewport.java 20 Feb 2003 02:47:44 - 1.14
@@ -16,6 +16,8 @@
import java.util.HashMap;
import java.util.Iterator;
+import org.apache.fop.fo.properties.RetrievePosition;
+
/**
* Page viewport that specifies the viewport area and holds the page contents.
* This is the top level object for a page and remains valid for the life
@@ -43,8 +45,10 @@
// hashmap of markers for this page
// start and end are added by the fo that contains the markers
-private Map markerStart = null;
-private Map markerEnd = null;
+private Map markerFirstStart = null;
+private Map markerLastStart = null;
+private Map markerFirstEnd = null;
+private Map markerLastEnd = null;
/**
* Create a page viewport.
@@ -176,27 +180,94 @@
}
/**
- * Add the start markers for this page.
+ * Add the markers for this page.
+ * Only the required markers are kept.
+ * For first-starting-within-page it adds the markers
+ * that are starting only if the marker class name is not
+ * already added.
+ * For first-including-carryover it adds any marker if
+ * the marker class name is not already added.
+ * For last-starting-within-page it adds all marks that
+ * are starting, replacing earlier markers
markers in redesign
Hi all, Since the topic is being discussed why don't we look at implementing markers in the redesign. I'll try to do what is obvious, getting the markers from the fo, adding when adding areas and retrieving when needed. I think some areas need changing so that the layout manager type is resolved after resolving markers, for example with tables it shouldn't make any assumptions about the type of child. I don't understand the boundaries etc. so I might need some help there. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/flow InstreamForeignObject.java
keiron 2003/02/18 21:39:20
Modified:src/org/apache/fop/fo/flow InstreamForeignObject.java
Log:
cleaned up some styling
Revision ChangesPath
1.36 +50 -43xml-fop/src/org/apache/fop/fo/flow/InstreamForeignObject.java
Index: InstreamForeignObject.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/InstreamForeignObject.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- InstreamForeignObject.java14 Feb 2003 04:15:04 - 1.35
+++ InstreamForeignObject.java19 Feb 2003 05:39:20 - 1.36
@@ -1,6 +1,6 @@
/*
* $Id$
- * Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
+ * Copyright (C) 2001-2003 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
*/
@@ -8,54 +8,54 @@
package org.apache.fop.fo.flow;
// FOP
-import org.apache.fop.fo.*;
-import org.apache.fop.fo.properties.*;
-import org.apache.fop.datatypes.Length;
-import org.apache.fop.area.Area;
-import org.apache.fop.area.inline.InlineArea;
-import org.apache.fop.area.inline.Viewport;
+import java.awt.geom.Point2D;
+import java.awt.geom.Rectangle2D;
+import java.util.List;
+
import org.apache.fop.area.inline.ForeignObject;
-import org.apache.fop.layout.FontState;
+import org.apache.fop.area.inline.Viewport;
+import org.apache.fop.datatypes.Length;
+import org.apache.fop.fo.FONode;
+import org.apache.fop.fo.FObj;
+import org.apache.fop.fo.XMLObj;
+import org.apache.fop.fo.properties.DisplayAlign;
+import org.apache.fop.fo.properties.Overflow;
+import org.apache.fop.fo.properties.Scaling;
+import org.apache.fop.fo.properties.TextAlign;
import org.apache.fop.layout.AccessibilityProps;
import org.apache.fop.layout.AuralProps;
-import org.apache.fop.layout.BorderAndPadding;
import org.apache.fop.layout.BackgroundProps;
+import org.apache.fop.layout.BorderAndPadding;
import org.apache.fop.layout.MarginInlineProps;
import org.apache.fop.layout.RelativePositionProps;
-import org.apache.fop.apps.FOPException;
-import org.apache.fop.layoutmgr.LayoutManager;
import org.apache.fop.layoutmgr.LeafNodeLayoutManager;
-
import org.w3c.dom.Document;
-import java.awt.geom.Point2D;
-import java.awt.geom.Rectangle2D;
-import java.util.List;
-
+/**
+ * The instream-foreign-object flow formatting object.
+ * This is an atomic inline object that contains
+ * xml data.
+ */
public class InstreamForeignObject extends FObj {
-int breakBefore;
-int breakAfter;
-int spaceBefore;
-int spaceAfter;
-int startIndent;
-int endIndent;
-
-Viewport areaCurrent;
+private Viewport areaCurrent;
/**
* constructs an instream-foreign-object object (called by Maker).
*
* @param parent the parent formatting object
- * @param propertyList the explicit properties of this object
*/
public InstreamForeignObject(FONode parent) {
super(parent);
}
+/**
+ * Add the layout manager for this into the list.
+ * @see org.apache.fop.fo.FObj#addLayoutManager(List)
+ */
public void addLayoutManager(List list) {
areaCurrent = getInlineArea();
-if(areaCurrent != null) {
+if (areaCurrent != null) {
LeafNodeLayoutManager lm = new LeafNodeLayoutManager();
lm.setUserAgent(getUserAgent());
lm.setFObj(this);
@@ -68,6 +68,8 @@
/**
* Get the inline area created by this element.
+ *
+ * @return the viewport inline area
*/
protected Viewport getInlineArea() {
if (children == null) {
@@ -79,7 +81,7 @@
return null;
}
FONode fo = (FONode)children.get(0);
-if(!(fo instanceof XMLObj)) {
+if (!(fo instanceof XMLObj)) {
// error
return null;
}
@@ -115,14 +117,14 @@
int bpd = -1;
int ipd = -1;
boolean bpdauto = false;
-if(hasLH) {
+if (hasLH) {
bpd = properties.get(line-height).getLength().mvalue();
} else {
// this property does not apply when the line-height applies
// isn't the block-progression-dimension always in the same
// direction as the line height?
len = properties.get(block-progression-dimension.optimum).getLength();
-if(!len.isAuto()) {
+if (!len.isAuto()) {
bpd = len.mvalue();
} else {
len = properties.get(height).getLength();
@@ -133,11 +135,11
cvs commit: xml-fop/src/org/apache/fop/area Page.java PageViewport.java
keiron 2003/02/18 21:43:25
Modified:src/org/apache/fop/area Page.java PageViewport.java
Log:
place markers on page viewport
Revision ChangesPath
1.9 +1 -6 xml-fop/src/org/apache/fop/area/Page.java
Index: Page.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/Page.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Page.java 19 Dec 2002 00:35:31 - 1.8
+++ Page.java 19 Feb 2003 05:43:24 - 1.9
@@ -29,11 +29,6 @@
private RegionViewport regionEnd = null;
private RegionViewport regionAfter = null;
-// hashmap of markers for this page
-// start and end are added by the fo that contains the markers
-private Map markerStart = null;
-private Map markerEnd = null;
-
// temporary map of unresolved objects used when serializing the page
private Map unresolved = null;
1.13 +32 -1 xml-fop/src/org/apache/fop/area/PageViewport.java
Index: PageViewport.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/PageViewport.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- PageViewport.java 27 Jan 2003 09:24:24 - 1.12
+++ PageViewport.java 19 Feb 2003 05:43:24 - 1.13
@@ -41,6 +41,11 @@
private Map pendingResolved = null;
+// hashmap of markers for this page
+// start and end are added by the fo that contains the markers
+private Map markerStart = null;
+private Map markerEnd = null;
+
/**
* Create a page viewport.
* @param p the page reference area that holds the contents
@@ -168,6 +173,32 @@
unresolved = null;
}
}
+}
+
+/**
+ * Add the start markers for this page.
+ *
+ * @param marks the map of start markers to add
+ */
+public void addMarkers(Map marks, boolean start) {
+if (start) {
+if (markerStart == null) {
+markerStart = new HashMap();
+}
+markerStart.putAll(marks);
+} else {
+if (markerEnd == null) {
+markerEnd = new HashMap();
+}
+markerEnd.putAll(marks);
+}
+}
+
+public Object getMarker(String name, int pos) {
+if (markerStart != null) {
+return markerStart.get(name);
+}
+return null;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/layoutmgr/table Body.java Caption.java Cell.java Column.java Row.java TableAndCaptionLayoutManager.java TableLayoutManager.java
keiron 2003/02/18 21:49:29
Modified:src/org/apache/fop/layoutmgr AbstractLayoutManager.java
BlockContainerLayoutManager.java
BlockLayoutManager.java
BlockStackingLayoutManager.java
BreakPossPosIter.java ContentLayoutManager.java
FlowLayoutManager.java
InlineStackingLayoutManager.java LayoutManager.java
LeafNodeLayoutManager.java LineLayoutManager.java
MinOptMax.java PageLayoutManager.java
StaticContentLayoutManager.java
TextLayoutManager.java TraitSetter.java
src/org/apache/fop/layoutmgr/list Item.java
ListBlockLayoutManager.java
ListItemLayoutManager.java
src/org/apache/fop/layoutmgr/table Body.java Caption.java
Cell.java Column.java Row.java
TableAndCaptionLayoutManager.java
TableLayoutManager.java
Added: src/org/apache/fop/layoutmgr
RetrieveMarkerLayoutManager.java
Log:
add and retrive markers
use trait setter for area traits
some style cleanups
Revision ChangesPath
1.21 +23 -65xml-fop/src/org/apache/fop/layoutmgr/AbstractLayoutManager.java
Index: AbstractLayoutManager.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/AbstractLayoutManager.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- AbstractLayoutManager.java14 Feb 2003 04:15:07 - 1.20
+++ AbstractLayoutManager.java19 Feb 2003 05:49:28 - 1.21
@@ -9,18 +9,16 @@
import org.apache.fop.fo.FObj;
import org.apache.fop.fo.FOUserAgent;
+import org.apache.fop.fo.flow.Marker;
import org.apache.fop.area.Area;
import org.apache.fop.area.Resolveable;
import org.apache.fop.area.PageViewport;
import org.apache.fop.fo.PropertyManager;
-import org.apache.fop.area.Trait;
-import org.apache.fop.layout.BorderAndPadding;
-import org.apache.fop.layout.BackgroundProps;
-import org.apache.fop.traits.BorderProps;
import org.apache.avalon.framework.logger.Logger;
import java.util.ListIterator;
+import java.util.Map;
/**
* The base class for all LayoutManagers.
@@ -30,6 +28,7 @@
protected LayoutManager parentLM = null;
protected FObj fobj;
protected String foID = null;
+protected Map markers = null;
/** True if this LayoutManager has handled all of its content. */
private boolean bFinished = false;
@@ -37,7 +36,6 @@
protected ListIterator childLMiter;
protected boolean bInited = false;
-
/**
* Abstract layout manager.
*/
@@ -52,6 +50,7 @@
public void setFObj(FObj fo) {
this.fobj = fo;
foID = fobj.getID();
+markers = fobj.getMarkers();
childLMiter = new LMiter(fobj.getChildren());
}
@@ -64,6 +63,11 @@
userAgent = ua;
}
+/**
+ * Get the user agent.
+ *
+ * @see org.apache.fop.layoutmgr.LayoutManager#getUserAgent()
+ */
public FOUserAgent getUserAgent() {
return userAgent;
}
@@ -318,12 +322,22 @@
}
/**
+ * Add the markers when adding an area.
+ */
+protected void addMarkers(boolean start) {
+// add markers
+if (markers != null) {
+addMarkerMap(markers, start);
+}
+}
+
+/**
* Delegate adding marker to the parent layout manager.
*
* @see org.apache.fop.layoutmgr.LayoutManager
*/
-public void addMarker(String name, LayoutManager lm, boolean start) {
-parentLM.addMarker(name, lm, start);
+public void addMarkerMap(Map marks, boolean start) {
+parentLM.addMarkerMap(marks, start);
}
/**
@@ -331,65 +345,9 @@
*
* @see org.apache.fop.layoutmgr.LayoutManager
*/
-public LayoutManager retrieveMarker(String name, int pos, int boundary) {
+public Marker retrieveMarker(String name, int pos, int boundary) {
return parentLM.retrieveMarker(name, pos, boundary);
}
-/**
- * Add borders to an area.
- * Layout managers that create areas with borders can use this to
- * add the borders to the area.
- */
-public static void addBorders(Area curBlock, BorderAndPadding bordProps) {
-BorderProps bps = getBorderProps(bordProps, BorderAndPadding.TOP);
-if(bps.width != 0) {
-curBlock.addTrait(Trait.BORDER_BEFORE, bps);
-}
-bps = getBorderProps(bordProps, BorderAndPadding.BOTTOM
cvs commit: xml-fop/src/org/apache/fop/fo/flow RetrieveMarker.java
keiron 2003/02/18 21:54:15
Modified:src/org/apache/fop/fo/flow RetrieveMarker.java
Log:
add retrieve marker layout manager
Revision ChangesPath
1.12 +31 -10xml-fop/src/org/apache/fop/fo/flow/RetrieveMarker.java
Index: RetrieveMarker.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/RetrieveMarker.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- RetrieveMarker.java 20 Jun 2002 09:14:13 - 1.11
+++ RetrieveMarker.java 19 Feb 2003 05:54:15 - 1.12
@@ -1,6 +1,6 @@
/*
* $Id$
- * Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
+ * Copyright (C) 2001-2003 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
*/
@@ -8,27 +8,39 @@
package org.apache.fop.fo.flow;
// FOP
-import org.apache.fop.fo.*;
-import org.apache.fop.fo.properties.*;
-import org.apache.fop.layout.*;
-import org.apache.fop.datatypes.*;
import org.apache.fop.apps.FOPException;
-
-// Java
-import java.util.Vector;
-
+import org.apache.fop.fo.FONode;
+import org.apache.fop.fo.FObjMixed;
+import org.apache.fop.layoutmgr.RetrieveMarkerLayoutManager;
import org.xml.sax.Attributes;
+import java.util.List;
+
+/**
+ * The retrieve-marker formatting object.
+ * This will create a layout manager that will retrieve
+ * a marker based on the information.
+ */
public class RetrieveMarker extends FObjMixed {
private String retrieveClassName;
private int retrievePosition;
private int retrieveBoundary;
+/**
+ * Create a retrieve marker object.
+ *
+ * @see org.apache.fop.fo.FONode#FONode(FONode)
+ */
public RetrieveMarker(FONode parent) {
super(parent);
}
+/**
+ * Handle the attributes for the retrieve-marker.
+ *
+ * @see org.apache.fop.fo.FONode#handleAttrs(Attributes)
+ */
public void handleAttrs(Attributes attlist) throws FOPException {
super.handleAttrs(attlist);
this.retrieveClassName =
@@ -39,4 +51,13 @@
this.properties.get(retrieve-boundary).getEnum();
}
+public void addLayoutManager(List lms) {
+RetrieveMarkerLayoutManager rmlm;
+rmlm = new RetrieveMarkerLayoutManager(retrieveClassName,
+retrievePosition,
+retrieveBoundary);
+rmlm.setUserAgent(getUserAgent());
+rmlm.setFObj(this);
+lms.add(rmlm);
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/pdf FlateFilter.java PDFColor.java
keiron 2003/02/18 21:55:25
Modified:src/org/apache/fop/pdf FlateFilter.java PDFColor.java
Log:
fixed some minor errors
Revision ChangesPath
1.6 +7 -7 xml-fop/src/org/apache/fop/pdf/FlateFilter.java
Index: FlateFilter.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/pdf/FlateFilter.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- FlateFilter.java 17 Sep 2002 09:20:57 - 1.5
+++ FlateFilter.java 19 Feb 2003 05:55:25 - 1.6
@@ -135,8 +135,8 @@
* @param predictor the predictor to use
* @throws PDFFilterException if there is an error with the predictor
*/
-public void setPredictor(int predictor) throws PDFFilterException {
-predictor = predictor;
+public void setPredictor(int pred) throws PDFFilterException {
+predictor = pred;
}
@@ -155,9 +155,9 @@
* @param colors the colors to use
* @throws PDFFilterException if predictor is not PREDICTION_NONE
*/
-public void setColors(int colors) throws PDFFilterException {
+public void setColors(int cols) throws PDFFilterException {
if (predictor != PREDICTION_NONE) {
-colors = colors;
+colors = cols;
} else {
throw new PDFFilterException(
Prediction must not be PREDICTION_NONE in
@@ -205,9 +205,9 @@
* @param columns the number of columns to use for the filter
* @throws PDFFilterException if predictor is not PREDICTION_NONE
*/
-public void setColumns(int columns) throws PDFFilterException {
+public void setColumns(int cols) throws PDFFilterException {
if (predictor != PREDICTION_NONE) {
-columns = columns;
+columns = cols;
} else {
throw new PDFFilterException(
Prediction must not be PREDICTION_NONE in
1.16 +6 -6 xml-fop/src/org/apache/fop/pdf/PDFColor.java
Index: PDFColor.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/pdf/PDFColor.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- PDFColor.java 11 Jan 2003 19:38:52 - 1.15
+++ PDFColor.java 19 Feb 2003 05:55:25 - 1.16
@@ -314,9 +314,9 @@
this.green = 1.0 - this.green;
this.blue = 1.0 - this.yellow;
-this.red = (this.black / this.blackFactor) + this.red;
-this.green = (this.black / this.blackFactor) + this.green;
-this.blue = (this.black / this.blackFactor) + this.blue;
+this.red = (this.black / PDFColor.blackFactor) + this.red;
+this.green = (this.black / PDFColor.blackFactor) + this.green;
+this.blue = (this.black / PDFColor.blackFactor) + this.blue;
}
@@ -381,7 +381,7 @@
tempDouble = this.yellow;
}
-this.black = (tempDouble / this.blackFactor);
+this.black = (tempDouble / PDFColor.blackFactor);
}
@@ -402,7 +402,7 @@
tempDouble = this.blue;
}
-this.black = 1.0 - (tempDouble / this.blackFactor);
+this.black = 1.0 - (tempDouble / PDFColor.blackFactor);
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plan for HEAD
Hi all, and especially Keiron. What are currently the most pressing problems with HEAD, in order to make a dev-release? I looked around and found quite a few details, but I can't seem to get the big picture. I have somethig to do for the API spec but there wasn't much activity in this area either last week. Does somebody already have a TODO list with prioritized tasks, preferably broken down to activities taking days rather than months? This page sort of has things: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPProjectTasks Mostly we need to get the renderers back and fix/improve some layout things like forced page break, table cell spanning, couple of problems calculating current bpd. What standard are you looking for in a dev release. Do we include the new api in the release. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Licence issues in hyphenation patterns (was: HyphenationTree bug and Portuguese hyphenation file update)
I'd say we can't keep something like that within our codebase because it contradicts the Apache licence. It is entirely possible that someone sells a product that uses FOP. That wouldn't violate the Apache licence but the licence of this hyphenation file. Recent discussions on various Apache mailing lists show that we shouldn't include anything in our codebase that uses a licence that is not officially approved. I agree. Should probably take a look at it and if we cannot distribute then remove them. Maybe we could try to make them available in some other way. I wasn't aware that the hyphenation patterns had their own licences. So, the obvious conclusion is that we need to check every one of these files and remove the ones that are not compatible with the Apache licence. That includes checking where the files came from. Just for reference: http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/layoutmgr/table Body.java Caption.java Cell.java Column.java Row.java TableAndCaptionLayoutManager.java TableLayoutManager.java
keiron 2003/02/13 20:15:09
Modified:src/org/apache/fop/fo FOText.java FObjMixed.java Title.java
src/org/apache/fop/fo/flow BasicLink.java BidiOverride.java
Block.java BlockContainer.java Character.java
ExternalGraphic.java Flow.java InlineContainer.java
InstreamForeignObject.java Leader.java
ListBlock.java ListItem.java ListItemBody.java
ListItemLabel.java PageNumber.java
PageNumberCitation.java StaticContent.java
Table.java TableBody.java TableCell.java
TableColumn.java TableRow.java
src/org/apache/fop/fo/pagination PageSequence.java
src/org/apache/fop/layoutmgr AbstractLayoutManager.java
BlockContainerLayoutManager.java
BlockLayoutManager.java
BlockStackingLayoutManager.java
ContentLayoutManager.java FlowLayoutManager.java
InlineStackingLayoutManager.java LayoutManager.java
LeafNodeLayoutManager.java LineLayoutManager.java
PageLayoutManager.java
StaticContentLayoutManager.java
TextLayoutManager.java
src/org/apache/fop/layoutmgr/list Item.java
ListBlockLayoutManager.java
ListItemLayoutManager.java
src/org/apache/fop/layoutmgr/table Body.java Caption.java
Cell.java Column.java Row.java
TableAndCaptionLayoutManager.java
TableLayoutManager.java
Log:
set FO on lm as part of interface, simpler and more flexible
Revision ChangesPath
1.42 +4 -2 xml-fop/src/org/apache/fop/fo/FOText.java
Index: FOText.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/FOText.java,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- FOText.java 15 Nov 2002 11:56:27 - 1.41
+++ FOText.java 14 Feb 2003 04:15:03 - 1.42
@@ -85,7 +85,9 @@
ca = new char[length];
System.arraycopy(tmp, 0, ca, 0, length);
}
-list.add(new TextLayoutManager(this, ca, textInfo));
+LayoutManager lm = new TextLayoutManager(ca, textInfo);
+lm.setFObj(this);
+list.add(lm);
}
public CharIterator charIterator() {
1.32 +7 -3 xml-fop/src/org/apache/fop/fo/FObjMixed.java
Index: FObjMixed.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/FObjMixed.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- FObjMixed.java15 Nov 2002 11:56:27 - 1.31
+++ FObjMixed.java14 Feb 2003 04:15:03 - 1.32
@@ -36,8 +36,12 @@
public void addLayoutManager(List lms) {
if (children != null) {
-lms.add(new InlineStackingLayoutManager(this,
- new LMiter(children.listIterator(;
+InlineStackingLayoutManager lm;
+lm = new InlineStackingLayoutManager();
+lm.setUserAgent(getUserAgent());
+lm.setFObj(this);
+lm.setLMiter(new LMiter(children.listIterator()));
+lms.add(lm);
}
}
1.13 +4 -3 xml-fop/src/org/apache/fop/fo/Title.java
Index: Title.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Title.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Title.java18 Nov 2002 15:54:14 - 1.12
+++ Title.java14 Feb 2003 04:15:03 - 1.13
@@ -33,9 +33,10 @@
// use special layout manager to add the inline areas
// to the Title.
InlineStackingLayoutManager lm;
-lm = new InlineStackingLayoutManager(this,
- new LMiter(children.listIterator()));
+lm = new InlineStackingLayoutManager();
lm.setUserAgent(getUserAgent());
+lm.setFObj(this);
+lm.setLMiter(new LMiter(children.listIterator()));
lm.init();
// get breaks then add areas to title
1.19 +8 -4 xml-fop/src/org/apache/fop/fo/flow/BasicLink.java
Index: BasicLink.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/BasicLink.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- BasicLink.java15 Nov 2002 11:56:28 -
Re: Another release candidate ...
This sounds great, but I have one question. We've posted a bug report (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16672) about the SVG rendering in 0.20.4 and 0.20.5. Our SVG's in the rendered PDF document(s) gets clipped. We're now using 0.20.1 and everything is fine there. The PS renderer in 0.20.4 and 0.20.5 also produces a correct rendered SVG. We use FOP at the Swedish Election Authority and consider this to be a big blocker for us, and I assume that's the case for others as well. I haven't seen any activity in this list etc on this bug report and wouldn't it be nice to dig in to this before the final release. Take a look at line 526 of PDFRenderer.java, it clips to the size of the SVG image. Is it possible that part of the SVG goes outside the SVG width and height? Try commenting it out or changing the size of your SVG and seeing if it changes. I'll happily provide the SVG file, XSL etc if this could help. I've been trying to look at the code myself but I'm not really confident with the design and the PDF spec. By the way, thank you for an awesome product ... Christer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/traits SpaceVal.java
keiron 2003/02/12 20:24:19 Modified:src/org/apache/fop/fo/flow Leader.java src/org/apache/fop/layoutmgr BlockContainerLayoutManager.java BlockLayoutManager.java BlockStackingLayoutManager.java BreakPoss.java ContentLayoutManager.java InlineStackingLayoutManager.java LayoutContext.java LeafNodeLayoutManager.java LineLayoutManager.java PageLayoutManager.java SpaceSpecifier.java TextLayoutManager.java src/org/apache/fop/layoutmgr/list Item.java ListBlockLayoutManager.java ListItemLayoutManager.java src/org/apache/fop/layoutmgr/table Body.java Caption.java Cell.java Row.java TableAndCaptionLayoutManager.java TableLayoutManager.java src/org/apache/fop/traits SpaceVal.java Added: src/org/apache/fop/layoutmgr MinOptMax.java Removed: src/org/apache/fop/area MinOptMax.java Log: moved MinOptMax to where it is used Revision ChangesPath 1.31 +2 -2 xml-fop/src/org/apache/fop/fo/flow/Leader.java Index: Leader.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/Leader.java,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- Leader.java 18 Nov 2002 15:54:14 - 1.30 +++ Leader.java 13 Feb 2003 04:24:17 - 1.31 @@ -21,7 +21,7 @@ import org.apache.fop.layoutmgr.ContentLayoutManager; import org.apache.fop.layoutmgr.LayoutContext; import org.apache.fop.layoutmgr.LMiter; -import org.apache.fop.area.MinOptMax; +import org.apache.fop.layoutmgr.MinOptMax; import org.apache.fop.area.inline.Space; import org.apache.fop.area.inline.Word; import org.apache.fop.area.inline.InlineParent; 1.8 +1 -2 xml-fop/src/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java Index: BlockContainerLayoutManager.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- BlockContainerLayoutManager.java 29 Nov 2002 23:18:55 - 1.7 +++ BlockContainerLayoutManager.java 13 Feb 2003 04:24:17 - 1.8 @@ -14,7 +14,6 @@ import org.apache.fop.area.BlockViewport; import org.apache.fop.area.Block; import org.apache.fop.area.LineArea; -import org.apache.fop.area.MinOptMax; import org.apache.fop.fo.PropertyManager; import org.apache.fop.layout.AbsolutePositionProps; import org.apache.fop.fo.properties.AbsolutePosition; 1.26 +1 -2 xml-fop/src/org/apache/fop/layoutmgr/BlockLayoutManager.java Index: BlockLayoutManager.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/BlockLayoutManager.java,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- BlockLayoutManager.java 29 Nov 2002 23:18:55 - 1.25 +++ BlockLayoutManager.java 13 Feb 2003 04:24:17 - 1.26 @@ -14,7 +14,6 @@ import org.apache.fop.area.BlockParent; import org.apache.fop.area.Block; import org.apache.fop.area.LineArea; -import org.apache.fop.area.MinOptMax; import org.apache.fop.area.Trait; import org.apache.fop.traits.LayoutProps; import org.apache.fop.layout.BorderAndPadding; 1.14 +1 -2 xml-fop/src/org/apache/fop/layoutmgr/BlockStackingLayoutManager.java Index: BlockStackingLayoutManager.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/BlockStackingLayoutManager.java,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- BlockStackingLayoutManager.java 13 Nov 2002 10:25:48 - 1.13 +++ BlockStackingLayoutManager.java 13 Feb 2003 04:24:17 - 1.14 @@ -11,7 +11,6 @@ import org.apache.fop.area.Area; import org.apache.fop.area.BlockParent; import org.apache.fop.area.Block; -import org.apache.fop.area.MinOptMax; import java.util.Iterator; 1.11 +1 -2 xml-fop/src/org/apache/fop/layoutmgr/BreakPoss.java Index: BreakPoss.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/BreakPoss.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- BreakPoss.java18 Nov 2002 15:54:15 - 1.10 +++ BreakPoss.java13 Feb 2003 04:24:17 - 1.11 @@ -6,7
Re: source for hz algorithm
True, but I had in mind that any such approach will be built on the fact that any layout is, in some sense, tentative. Rhett raised the question some time ago of a means recording (and scoring) intermediate results, something which will be an essential element of such a solution. At this stage, I would tend to think not of doing every possible layout, but of following the optimum values to perform initial layout, and then testing the result for goodness. The minimum-maximum range provides the slack - within the context of the spec - for applying whatever other set of layout tuning algorithms that FOP implements. The idea I am working with (of which I have prototype working) is that a break is after a line. For this break it finds the BPD distance from the top down (flow layout manager) from the start of the page to the current break. It also finds the keeps from the current break position, looking at parent layout managers and next layout managers for keep with previous. A best break is found based on these two values. A next break is then found, since we don't know we have a best until there is a worse break. This can be done for all pages in the page sequence or until forced break. Then if for example we want to find the optimum break. There is also the possiblity to get the next break within a context (which invalidates all further breaks) or previous break. I am quite confident that this will work well. Footnotes and before floats suddenly become easy. Keeps are quite easy also. The only drawback is that it constantly needs to find the child layout manager that applies to a given break and that finding the BPD distance could be time consuming in some circumstances. Optimisations should help a bit. I would see these being arranged as a set of heuristics - for want of a better word - that are applied in a structured fashion to detected layout conflicts of particular types. What comprises a conflict would be determined by those configurable parameters. In the initial version, we only need to provide for the most basic of these, as long as the mechanism is general enough to allow for refinement. I am hoping that making the breaks simple and easy to find certain properties from any position will help us to explore what to do next. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: source for hz algorithm
On Wednesday, January 29, 2003, at 03:20 PM, Rhett Aultman wrote: This might be semantic nitpicking more than anything, but how can finding a worse break prove you have the best break? Wouldn't you have to find all possible breaks and verify that they're worse? Also, just for personal enlightenment, what principles govern betterness or worseness? I didn't say it properly. Okay, if we are going down a page the first break found after the first line will be the first best break. The next line will then become the best break as it is closer to the optimum distance and has no keeps. As we go down the page it will keep find better breaks for the current page. Going in only forwards a better break is one that has a lower keep value or an equal keep but is closer to the optimum. Once it goes past the optimum then if we find a break with an equal keep to the current best and it is further away then the current best is the best. Then if for example we want to find the optimum break. There is also the possiblity to get the next break within a context (which invalidates all further breaks) or previous break. Could you please expound on this idea a little further? I don't think I'm quite following. Sorry don't have time right now. There is a bit of info in the other message. The only drawback is that it constantly needs to find the child layout manager that applies to a given break and that finding the BPD distance could be time consuming in some circumstances. Optimisations should help a bit. Offhand, I would think that this won't represent a reall performance bottleneck, and it would seem quite necessary given my somewhat green understanding of what you're proposing. I am hoping that making the breaks simple and easy to find certain properties from any position will help us to explore what to do next. I'd really like to see this feature in motion. Being able to find this seems imperative for handing conflicting constraints and other anomalous situations. Take a look at the code in attached to the other message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: source for hz algorithm
On Wednesday, January 29, 2003, at 09:54 PM, J.Pietschmann wrote:
Keiron Liddle wrote:
The only drawback is that it constantly needs to find the child layout
manager that applies to a given break...
Well, if there is a min opt max, and opt doesn't quite fit,
you have to choose whether to use the wiggle room to the min
or to the max side. This bothers me.
By that I mean using this code all the time:
int start = 0;
if (last != null) {
LM currentchild = last.getChildOf(this);
if (currentchild != null) {
start = childBlocks.indexOf(currentchild);
}
}
It has no relationship to finding a break. It is just finding where a
break is when start from last break, adding breaks from last to current
break, finding distance from last to current break.
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Re-design (less ugly msg)
The asap rendering is mostly done, we still need to bring back many of the renderers. I suppose you mean the PDFRenderer is mostly done. Yes. I should probably expand on that topic a bit. The layout creates an area tree which consists of pages. As each page is created by the layout the page is added to the area tree. It is set up so that as a page is added to the area tree it is handled immediately. The area tree model deals with pages as they are added, it can store the page, render immediately or if the page is not ready cache for later rendering. So this is done with the area tree model. The next part is rendering. Each renderer can handle a page that is sent to it or prepare for a page that is not ready. For PDF it can output the page contents in any order so that ready pages are rendered and output to the pdf document, other pages can be setup for later rendering. The next part is the PDF document. This is setup so that it can output immediately any pdf object that is added to the document. This means that it will output images, pages and some other smaller objects immediately and then release any memory used for those objects. The other renderers haven't been updated yet but they will be able to take advantage of this. The SAX input is really about processing the layout as the fo comes in. This depends mainly on the FO tree and the layout system. What up-to-date source and doc could I read in order to understand the purpose of making FO Tree layout ASAP ? This is where the docs are but not really up to date: http://xml.apache.org/fop/design/index.html Cedrick Le Nevanen Airbus France - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/area/inline Container.java InlineArea.java Word.java
keiron 2003/01/23 10:59:08
Modified:src/org/apache/fop/area AreaTreeModel.java BodyRegion.java
CTM.java CachedRenderPagesModel.java MinOptMax.java
RegionViewport.java RenderPagesModel.java Span.java
StorePagesModel.java Trait.java
src/org/apache/fop/area/inline Container.java
InlineArea.java Word.java
Log:
cleaned up some style errors
Revision ChangesPath
1.2 +5 -5 xml-fop/src/org/apache/fop/area/AreaTreeModel.java
Index: AreaTreeModel.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/AreaTreeModel.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AreaTreeModel.java22 Dec 2002 22:40:31 - 1.1
+++ AreaTreeModel.java23 Jan 2003 18:59:07 - 1.2
@@ -1,9 +1,9 @@
/*
-* $Id$
-* Copyright (C) 2002 The Apache Software Foundation. All rights reserved.
-* For details on use and redistribution please refer to the
-* LICENSE file included with these sources.
-*/
+ * $Id$
+ * Copyright (C) 2002 The Apache Software Foundation. All rights reserved.
+ * For details on use and redistribution please refer to the
+ * LICENSE file included with these sources.
+ */
package org.apache.fop.area;
1.8 +55 -6 xml-fop/src/org/apache/fop/area/BodyRegion.java
Index: BodyRegion.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/BodyRegion.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- BodyRegion.java 18 Sep 2002 13:50:13 - 1.7
+++ BodyRegion.java 23 Jan 2003 18:59:07 - 1.8
@@ -19,7 +19,7 @@
private int columnGap;
private int columnCount;
-/** Referenc inline progression dimension for the body. */
+/** Reference inline progression dimension for the body. */
private int refIPD;
/**
@@ -30,46 +30,95 @@
super(BODY);
}
-// Number of columns when not spanning
+/**
+ * Set the number of columns for blocks when not spanning
+ *
+ * @param colCount the number of columns
+ */
public void setColumnCount(int colCount) {
this.columnCount = colCount;
}
-// Number of columns when not spanning
+/**
+ * Get the number of columns when not spanning
+ *
+ * @return the number of columns
+ */
public int getColumnCount() {
return this.columnCount;
}
-// A length (mpoints)
+/**
+ * Set the column gap between columns
+ * The length is in millipoints.
+ *
+ * @param colGap the column gap in millipoints
+ */
public void setColumnGap(int colGap) {
this.columnGap = colGap;
}
+/**
+ * Set the before float area.
+ *
+ * @param bf the before float area
+ */
public void setBeforeFloat(BeforeFloat bf) {
beforeFloat = bf;
}
+/**
+ * Set the main reference area.
+ *
+ * @param mr the main reference area
+ */
public void setMainReference(MainReference mr) {
mainReference = mr;
}
+/**
+ * Set the footnote area.
+ *
+ * @param foot the footnote area
+ */
public void setFootnote(Footnote foot) {
footnote = foot;
}
-
+/**
+ * Get the before float area.
+ *
+ * @return the before float area
+ */
public BeforeFloat getBeforeFloat() {
return beforeFloat;
}
+/**
+ * Get the main reference area.
+ *
+ * @return the main reference area
+ */
public MainReference getMainReference() {
return mainReference;
}
+/**
+ * Get the footnote area.
+ *
+ * @return the footnote area
+ */
public Footnote getFootnote() {
return footnote;
}
+/**
+ * Clone this object.
+ * This is only used to clone the current object, the child areas
+ * are assumed to be null and are not cloned.
+ *
+ * @return a shallow copy of this object
+ */
public Object clone() {
BodyRegion br = new BodyRegion();
br.setCTM(getCTM());
1.7 +36 -8 xml-fop/src/org/apache/fop/area/CTM.java
Index: CTM.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/area/CTM.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- CTM.java 25 Oct 2002 09:29:39 - 1.6
+++ CTM.java 23 Jan 2003 18:59:07 - 1.7
Re: Re-design
On Thursday, January 23, 2003, at 06:37 PM, LENEVANEN Cedrick wrote: Confronted to volumetric problems I am very interested in the re-design branch of the FOP project, in particular the FO SAX input and ASAP rendering tasks. I wonder if I could try helping in order to make possible getting a release available this year. The asap rendering is mostly done, we still need to bring back many of the renderers. The SAX input is really about processing the layout as the fo comes in. This depends mainly on the FO tree and the layout system. Any help would be great. But I have not been able to catch the real design/development state of the 1.0 branch. Does anyone already work on the preceding items ? Generally yes, but we could use any help if you can contribute. There are lots of areas that need development. CÈdrick Le NÈvanen Airbus France - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: strokeSVGText in Postscript format
On Thursday, January 23, 2003, at 07:32 PM, George Yi wrote: Has anyone made or is making an effort to implement strokeSVGText==false feature in PS renderning? Not that I am aware of. I don't want to reinvent wheel here, if no effort is there, I would like to dive into this. Whenever I talk to my collegures or boss about how wonderful FOP is for PDF publishing, the feedback alway is PS SVG sucks. It was written quickly quite some time ago and has been waiting for someone to say it sucks :). My goal is to make PS SVG rendering a decent one. Three things I wanted to achieve, display right color stroke, Quadratic Bezier Curve and text embedding. the first two are relatively easier, I have submitted two patch #16182 and #16306. So far, colors, curves and text are displayed correctly but the file size is huge when you have text in your SVG. This is because the PS renderer actually draws text in SVG. I would like to implement a strokeSVGText like feature in PDF here. Thats great. If any committer has this on his radar, that's a great news to me:-) ( Or give me a boot ) This is an area that would be best tackled with the redesigned code as far as development is concerned. The handling of this issue in the redesign has improved quite a bit (but still has some issues left). If you want it sooner then I can give you a few pointers. The PDF renderer handles this issue in the same way that the PS renderer should handle it. Batik uses a concept of a GVT (graphics vector toolkit) that has a TextPainter that handles text. The default TextPainter is the StrokingTextPainter, when not stroking text it replaces this with a PDFTextPainter. The PDFTextPainter then draws the text using the drawString method instead of creating shapes and drawing them. So for the PS renderer you will need to register a TextPainter in the same way which should do the same sort of thing as for the PDFRenderer. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Fwd: xml.apache.org refactoring #1]
Jeremias Maerki wrote: Common guys! I'd like to have some participation on this matter from all the committers since this an important thing. Sorry a bit sidetracked. Personally I would like to see some sort of rotation (assuming that there will always be 1 or 2). For example every 6 months. Why? So the PMC becomes something that is better known and diverse than the mystery that it currently seems to be. Christian Geisert wrote: And to simplify the nomination I'm stepping back. +1 for Jeremias and Peter Two very fine candidates. +1 +1 also - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fop able to run without Batik?
Batik is only necessary to generate SVG output, right? I guess, a lot of people are using Fop to generate PDF only, but Fop needs batik.jar in any case because the driver initializes an SVG element mapping: org.apache.fop.apps.Driver.setupDefaultMappings() : addElementMapping(org.apache.fop.svg.SVGElementMapping); That is to handle svg input which could be used in a PDF (or any other) output document. This method will throw a ClassNotFoundException when batik.jar is not in the classpath There are a number of other areas that require batik in the classpath. Maybe the initialization of the element mapping could somehow be moved to SVG specific code. Ideally it would be included only when the output format requires Batik This has been dealt with in the redesign. The code that handles the element mapping, external XML and image loading is separated so that if batik is not in the classpath it will continue to operate. Eckard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: duplicated sax classes
Current cvs batik has been fixed so that it uses the xml-apis.jar instead of having its own version. So if this is what is causing the problem you can make a build from current cvs. On Sunday, January 19, 2003, at 06:41 PM, Jeremias Maerki wrote: I think we could just remove the SAX classes from batik.jar. batik.jar was compiled by us manually and Keiron (for trunk) and I (for branch) both haven't realized that the SAX classes slipped in, I guess. I'll check the way we generate that jar again tomorrow. It might simply be a matter of sending the Batik team a little patch for their build.xml so we get an Ant target for creating a big batik.jar like we need/like it for FOP. You'll hear from me again. On 19.01.2003 12:05:53 Oleg Tkachenko wrote: We've got SAX classes both in xml-apis.jar and batik.jar. I don't care about superfluous 10-20 Kb, but unfortunately it causes problems in some environments, for instance in eclipse. One fellow has developed FOP plugin for eclipse and he's got Duplicate class definition problem because of it, but when he replaces batik.jar for a bunch of batik jars except of batik-ext.jar it works ok. Anybody has any ideas? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Distributing jimi.jar
Did you know that the Cocoon guys have jimi.jar in their CVS? I wonder if that's correct and if yes, I think we should do it, too. From my reading of it, by downloading the jar you automatically agree to the license. This is quite different to ASL. It is also non-transferable, I think that means the person who downloaded and agreed to the license cannot then make it available to others. Reading the licence I get the impression that redistribution of the jar is possible but not without restrictions. IANAL so who can we ask if distributing this jar is ok? The XML PMC is supposed to look after these issues (and I think if cocoon is top level then a cocoon PMC). I get the impression that things like that will be an everlasting problem. There should be a central source of information on licencing at Apache. A place where the gathered legal knowledge can be hammered in stone and be reused by other projects. Even the fact that we didn't include jimi.jar and Cocoon did gives me an uneasy feeling that the licence-sweep held at the XML project last year wasn't done 100% right. I'd like to escalate that topic again. What I think would be in the best interest of the Apache Foundation would be a central source of information where all projects and subprojects can get information on licencing. The following things would be very helpful: - Licence guidelines - A document describing the relationship of the APL to other licences. (what's compatible, what's not and why) - A list of approved products to be redistributable by Apache What are your thoughts? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Distributing jimi.jar
Isn't the jai.jar (which would give fop great functionality!) not redistributet for the same reason? Yes. I think the javax.imageio package is where Jimi and Jai were leading. So once jdk1.4 can be used... Best Regards Markus Schäffler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop build.xml
keiron 2003/01/15 11:30:24
Modified:.build.xml
Log:
include font classes for pdf transcoder
Revision ChangesPath
1.73 +1 -0 xml-fop/build.xml
Index: build.xml
===
RCS file: /home/cvs/xml-fop/build.xml,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -r1.72 -r1.73
--- build.xml 15 Jan 2003 15:07:05 - 1.72
+++ build.xml 15 Jan 2003 19:30:23 - 1.73
@@ -479,6 +479,7 @@
exclude name=org/apache/fop/render/pdf/PDFXMLHandler*/
/fileset
fileset dir=${build.dest}
+include name=org/apache/fop/fonts/**/
include name=org/apache/fop/layout/Font*.class/
include name=org/apache/fop/image/FopImag*.class/
include name=org/apache/fop/image/Jpeg*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/pdf PDFRoot.java PDFOutline.java
keiron 2003/01/14 11:55:20
Modified:src/org/apache/fop/pdf PDFRoot.java PDFOutline.java
Log:
setting for page mode, fixed some errors
Revision ChangesPath
1.13 +45 -9 xml-fop/src/org/apache/fop/pdf/PDFRoot.java
Index: PDFRoot.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/pdf/PDFRoot.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- PDFRoot.java 11 Jan 2003 19:38:52 - 1.12
+++ PDFRoot.java 14 Jan 2003 19:55:20 - 1.13
@@ -13,6 +13,26 @@
public class PDFRoot extends PDFObject {
/**
+ * Use no page mode setting, default
+ */
+public static final int PAGEMODE_USENONE = 0;
+
+/**
+ * Use outlines page mode to show bookmarks
+ */
+public static final int PAGEMODE_USEOUTLINES = 1;
+
+/**
+ * Use thumbs page mode to show thumbnail images
+ */
+public static final int PAGEMODE_USETHUMBS = 2;
+
+/**
+ * Full screen page mode
+ */
+public static final int PAGEMODE_FULLSCREEN = 3;
+
+/**
* the /Pages object that is root of the Pages hierarchy
*/
protected PDFPages rootPages;
@@ -22,6 +42,8 @@
*/
private PDFOutline outline;
+private int pageMode = PAGEMODE_USENONE;
+
/**
* create a Root (/Catalog) object. NOTE: The PDFRoot
* object must be created before the PDF document is
@@ -38,13 +60,13 @@
}
/**
- * Before the root is written to the document stream,
- * make sure it's object number is set. Package-private access
- * only; outsiders should not be fiddling with this stuff.
- */
-/*void setNumber(int number) {
-this.number = number;
-}*/
+ * Set the page mode for the PDF document.
+ *
+ * @param mode the page mode
+ */
+public void setPageMode(int mode) {
+pageMode = mode;
+}
/**
* add a /Page object to the root /Pages object
@@ -95,8 +117,22 @@
if (outline != null) {
p.append( /Outlines + outline.referencePDF() + \n);
p.append( /PageMode /UseOutlines\n);
+} else {
+switch (pageMode) {
+case PAGEMODE_USEOUTLINES:
+p.append( /PageMode /UseOutlines\n);
+break;
+case PAGEMODE_USETHUMBS:
+p.append( /PageMode /UseThumbs\n);
+break;
+case PAGEMODE_FULLSCREEN:
+p.append( /PageMode /FullScreen\n);
+break;
+case PAGEMODE_USENONE:
+default:
+break;
+}
}
-p.append( /PageMode /FullScreen\n);
p.append( \nendobj\n);
return p.toString().getBytes();
}
1.6 +3 -3 xml-fop/src/org/apache/fop/pdf/PDFOutline.java
Index: PDFOutline.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/pdf/PDFOutline.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- PDFOutline.java 11 Jan 2003 19:38:52 - 1.5
+++ PDFOutline.java 14 Jan 2003 19:55:20 - 1.6
@@ -52,7 +52,7 @@
* @param title the title of the outline entry (can only be null for root
Outlines obj)
* @param action the action for this outline
*/
-public PDFOutline(int number, String title, String action) {
+public PDFOutline(int number, String ti, String action) {
super(number);
subentries = new ArrayList();
count = 0;
@@ -61,7 +61,7 @@
next = null;
first = null;
last = null;
-title = title;
+title = ti;
actionRef = action;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Encryption
Jeremias, Thanks for the reply. Outside of clean up, I have working code. It is limited since only PDF 1.3 is supported by FOP and I am currently using a The redesign code generates PDF 1.4 (which currently is used in a completely backwards/forwards compatible way). How does the compatibilty of encryption work. Can it have the 1.4 features and still work in 1.3? non-commercial RC4 implementation. If I get the time, I could have it cleaned up in a week and a half. It might be a little longer if I go ahead and implement RC4 myself. I might need some help testing, but I already have it generating encrypted PDFs with and without passwords, permissions etc. Pat Lankswert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: thoughts on fonts (was: text-decoration)
properly discuss things like Session, Document, Rendering run, FOP instances etc. Where to cache what? What objects/services hold/provide In my mind Document and Rendering run (as defined in the glossary) are probably the same thing (??). I added something called Rendering instance to distinguish between different output media for the same document. Feel free to choose different terms -- I throw those out only to draw the distinction. That's good. I wonder what the others think about this terminology, because IMO this affects the whole redesign. If I understand it correctly we could have: - multiple output targets for one rendering run - targets with the same font metrics can layout to a common area tree - targets with similar or substitute metrics could force layout to one area tree - other targets can have different area trees from the same fo tree Would a rendering context make sense, which is created for each rendering instance and used to determine what to do for layout, rendering. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: text-decoration
Hello! How are we going to process underline/overline etc stuff? It's a little bit confusing - we've got unused TextState class along with TextInfo that includes text-decoration info already. Lets get rid of TextState ? And what about rendering, does pdf support text-decoration directly or we have to draw lines as in the branch? For the area tree and rending these traits, I think, can apply to inline area, inline parent or line area. For the pdf renderer I think it needs to be a line drawn as in the branch as pdf doesn't support it. One problem would be that the underline should be constant across all the text and whitespace, if pdf supported it then it would not work properly anyway. Have you managed to work out how the underline/overline should work, for example when there are embedded inline areas that contain a different font, colour or baseline. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: coordinates
On Thu, 2003-01-02 at 12:15, Oleg Tkachenko wrote: Hello! I'm stuck in understanding the coordinate system trying to sort out writing mode stuff, e.g. in this snippet from SimplePageMaster.java: /* Create the page reference area rectangle in first quadrant coordinates * (ie, 0,0 is at bottom,left of the page media and y increases * when moving towards the top of the page. * The media rectangle itself is (0,0,pageWidth,pageHeight). */ Rectangle pageRefRect = new Rectangle(mProps.marginLeft, mProps.marginTop, pageWidth - mProps.marginLeft - mProps.marginRight, pageHeight - mProps.marginTop - mProps.marginBottom); am I right that the comment is wrong and 0,0 is really at top-left? Yes, you are right. That appears to be the old coordinate system which was tied to the pdf coordinate system. The new way is to have 0,0 at the top left. It appears that some of the page master stuff hasn't been updated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation skinconf.xml
keiron 2003/01/02 05:01:12 Modified:src/documentation skinconf.xml Log: images don't seem to exist Revision ChangesPath 1.3 +2 -2 xml-fop/src/documentation/skinconf.xml Index: skinconf.xml === RCS file: /home/cvs/xml-fop/src/documentation/skinconf.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- skinconf.xml 29 Nov 2002 22:00:31 - 1.2 +++ skinconf.xml 2 Jan 2003 13:01:12 - 1.3 @@ -75,7 +75,7 @@ !-- Credits are typically rendered as a set of small clickable images in the page footer -- credits -credit +!--credit nameBuilt with Cocoon/name urlhttp://xml.apache.org/cocoon//url imageskin/images/built-with-cocoon.gif/image @@ -88,6 +88,6 @@ imageskin/images/centipede-logo-small.gif/image width138/width height31/height -/credit +/credit-- /credits /skinconfig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs/dev/fo embedding.fo
keiron 2002/12/27 01:39:31 Modified:src/documentation/content/xdocs/dev/fo embedding.fo Log: proper widths Revision ChangesPath 1.3 +2 -2 xml-fop/src/documentation/content/xdocs/dev/fo/embedding.fo Index: embedding.fo === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/dev/fo/embedding.fo,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- embedding.fo 29 Nov 2002 22:00:32 - 1.2 +++ embedding.fo 27 Dec 2002 09:39:30 - 1.3 @@ -795,8 +795,8 @@ Here we have some examples of how the XML can be specified in the fo document. fo:block fo:table - fo:table-column column-width=500pt/ - fo:table-column column-width=100pt/ + fo:table-column column-width=350pt/ + fo:table-column column-width=150pt/ fo:table-body fo:table-row fo:table-cell number-columns-spanned=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation sitemap.xmap
keiron 2002/12/27 02:04:11
Modified:src/documentation sitemap.xmap
Log:
updated to current forrest
Revision ChangesPath
1.10 +86 -52xml-fop/src/documentation/sitemap.xmap
Index: sitemap.xmap
===
RCS file: /home/cvs/xml-fop/src/documentation/sitemap.xmap,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- sitemap.xmap 29 Nov 2002 22:00:31 - 1.9
+++ sitemap.xmap 27 Dec 2002 10:04:11 - 1.10
@@ -33,7 +33,7 @@
!--
transformer-factoryorg.apache.xalan.xsltc.trax.TransformerFactoryImpl/transformer-factory
--
/map:transformer
/map:transformers
-
+
map:readers default=resource
map:reader name=resource
src=org.apache.cocoon.reading.ResourceReader/
/map:readers
@@ -48,6 +48,12 @@
encodingISO-8859-1/encoding
/map:serializer
+ map:serializer name=rss091mime-type=text/xml
src=org.apache.cocoon.serialization.XMLSerializer
+ doctype-public-//Netscape Communications//DTD RSS 0.91//EN/doctype-public
+
doctype-systemhttp://my.netscape.com/publish/formats/rss-0.91.dtd/doctype-system
+ encodingISO-8859-1/encoding
+ /map:serializer
+
map:serializer name=fo2pdf
src=org.apache.cocoon.serialization.FOPSerializer
mime-type=application/pdf/
@@ -90,8 +96,20 @@
map:actions
!-- map:action logger=sitemap.action.request name=request
src=org.apache.cocoon.acting.RequestParamAction/ --
map:action logger=sitemap.action.resource-exists name=resource-exists
src=org.apache.cocoon.acting.ResourceExistsAction/
+map:action logger=sitemap.action.sourcetype name=sourcetype
src=org.apache.forrest.components.sourcetype.SourceTypeAction
+ sourcetype name=document-v11
+document-declaration public-id=-//APACHE//DTD Documentation V1.1//EN/
+ /sourcetype
+ sourcetype name=howto-v10
+document-declaration public-id=-//APACHE//DTD How-to V1.0//EN/
+ /sourcetype
+/map:action
/map:actions
+ map:selectors
+map:selector logger=sitemap.selector.parameter name=parameter
src=org.apache.cocoon.selection.ParameterSelector/
+ /map:selectors
+
!--
The different pipeline implementations
--
@@ -103,7 +121,7 @@
map:pipeline name=profile-noncaching
src=org.apache.cocoon.components.profiler.ProfilingNonCachingProcessingPipeline/
--
/map:pipelines
-
+
/map:components
!-- === Views === --
@@ -121,11 +139,11 @@
map:resources
map:resource name=skinit
- map:transform src=skins/{defaults:skin}/xslt/html/{type}.xsl
+ map:transform src=skins/{forrest:skin}/xslt/html/{type}.xsl
map:parameter name=isfaq value={isfaq}/
map:parameter name=nopdf value={nopdf}/
map:parameter name=path value={path}/
- !-- Can set an alternative project skinconfig here
+ !-- Can set an alternative project skinconfig here
map:parameter name=config-file value=../../../../skinconf.xml/
--
/map:transform
@@ -141,7 +159,21 @@
/map:resource
map:resource name=skin-read
-map:read src=skins/{defaults:skin}/{path} mime-type={mime-type}/
+map:read src=skins/{forrest:skin}/{path} mime-type={mime-type}/
+ /map:resource
+
+ !-- Checks the document type of the resource passed in the src parameter
+ and converts it to document if necessary --
+ map:resource name=transform-to-document
+map:act type=sourcetype src={src}
+ map:select type=parameter
+map:parameter name=parameter-selector-test value={sourcetype}/
+map:when test=howto-v10
+ map:transform src=library/xslt/howto2document.xsl label=content/
+/map:when
+map:otherwise/
+ /map:select
+/map:act
/map:resource
/map:resources
@@ -149,28 +181,28 @@
!-- === Pipelines = --
map:pipelines
-
+
!-- Pipeline that manages the internal URI space
For the external URI space manager, see the next pipeline. --
- map:pipeline internal-only=true
+ map:pipeline
map:match pattern=**tab-**.xml
map:generate src=content/xdocs/tabs.xml/
map:call resource=skinit
map:parameter name=type value=tab2menu/
- map:parameter name=path value={2}.html/
+ map:parameter name=path value={2}/
/map:call
/map:match
map:match pattern=**book-**/*.xml
map:call resource=book
- map:parameter name=path value={2}/{3}/
+ map:parameter name=path value={2}/{3}.xml/
/map:call
/map:match
map:match pattern=**book-**.xml
map:call resource=book
cvs commit: xml-fop/src/documentation/content/xdocs examples.xml
keiron 2002/12/27 05:48:40 Modified:src/documentation/content/xdocs examples.xml Added: src/documentation/content/xdocs/fo fonts.fo Log: added easy lookup font characters pdf Revision ChangesPath 1.1 xml-fop/src/documentation/content/xdocs/fo/fonts.fo Index: fonts.fo === ?xml version=1.0 ? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; !-- defines the layout master -- fo:layout-master-set fo:simple-page-master master-name=first page-height=29.7cm page-width=21cm margin-top=1cm margin-bottom=2cm margin-left=2.5cm margin-right=2.5cm fo:region-body margin-top=1cm/ fo:region-before extent=1cm/ fo:region-after extent=1.5cm/ /fo:simple-page-master /fo:layout-master-set !-- starts actual layout -- fo:page-sequence master-reference=first fo:flow flow-name=xsl-region-body fo:block font-family=Helvetica font-size=14pt Helvetica /fo:block fo:block space-after.optimum=10pt font-family=Helvetica font-size=10pt fo:table fo:table-column column-width=65pt/ fo:table-column column-width=30pt/ fo:table-column column-width=65pt/ fo:table-column column-width=30pt/ fo:table-column column-width=65pt/ fo:table-column column-width=30pt/ fo:table-column column-width=65pt/ fo:table-body fo:table-row fo:table-cell fo:block amp;#x21; : #x21; amp;#x22; : #x22; amp;#x23; : #x23; amp;#x24; : #x24; amp;#x25; : #x25; amp;#x26; : #x26; amp;#x27; : #x27; amp;#x28; : #x28; amp;#x29; : #x29; amp;#x2A; : #x2A; amp;#x2B; : #x2B; amp;#x2C; : #x2C; amp;#x2D; : #x2D; amp;#x2E; : #x2E; amp;#x2F; : #x2F; amp;#x30; : #x30; amp;#x31; : #x31; amp;#x32; : #x32; amp;#x33; : #x33; amp;#x34; : #x34; amp;#x35; : #x35; amp;#x36; : #x36; amp;#x37; : #x37; amp;#x38; : #x38; amp;#x39; : #x39; amp;#x3A; : #x3A; amp;#x3B; : #x3B; amp;#x3C; : #x3C; amp;#x3D; : #x3D; amp;#x3E; : #x3E; amp;#x3F; : #x3F; amp;#x40; : #x40; amp;#x41; : #x41; amp;#x42; : #x42; amp;#x43; : #x43; amp;#x44; : #x44; amp;#x45; : #x45; amp;#x46; : #x46; amp;#x47; : #x47; amp;#x48; : #x48; amp;#x49; : #x49; amp;#x4A; : #x4A; amp;#x4B; : #x4B; amp;#x4C; : #x4C; amp;#x4D; : #x4D; amp;#x4E; : #x4E; amp;#x4F; : #x4F; amp;#x50; : #x50; amp;#x51; : #x51; amp;#x52; : #x52; amp;#x53; : #x53; amp;#x54; : #x54; amp;#x55; : #x55; /fo:block /fo:table-cell fo:table-cell fo:block /fo:block /fo:table-cell fo:table-cell fo:block amp;#x56; : #x56; amp;#x57; : #x57; amp;#x58; : #x58; amp;#x59; : #x59; amp;#x5A; : #x5A; amp;#x5B; : #x5B; amp;#x5C; : #x5C; amp;#x5D; : #x5D; amp;#x5E; : #x5E; amp;#x5F; : #x5F; amp;#x60; : #x60; amp;#x61; : #x61; amp;#x62; : #x62; amp;#x63; : #x63; amp;#x64; : #x64; amp;#x65; : #x65; amp;#x66; : #x66; amp;#x67; : #x67; amp;#x68; : #x68; amp;#x69; : #x69; amp;#x6A; : #x6A; amp;#x6B; : #x6B; amp;#x6C; : #x6C; amp;#x6D; : #x6D; amp;#x6E; : #x6E; amp;#x6F; : #x6F; amp;#x70; : #x70; amp;#x71; : #x71; amp;#x72; : #x72; amp;#x73; : #x73; amp;#x74; : #x74; amp;#x75; : #x75; amp;#x76; : #x76; amp;#x77; : #x77; amp;#x78; : #x78; amp;#x79; : #x79; amp;#x7A; : #x7A; amp;#x7B; : #x7B; amp;#x7C; : #x7C; amp;#x7D; : #x7D; amp;#x7E; : #x7E; amp;#xA1; : #xA1; amp;#xA2; : #xA2; amp;#xA3; : #xA3; amp;#xA4; : #xA4; amp;#xA5; : #xA5; amp;#xA6; : #xA6; amp;#xA7; : #xA7; amp;#xA8; : #xA8; amp;#xA9; : #xA9; amp;#xAA; : #xAA; amp;#xAB; : #xAB; amp;#xAC; : #xAC; /fo:block /fo:table-cell fo:table-cell fo:block /fo:block /fo:table-cell fo:table-cell fo:block amp;#xAE; : #xAE; amp;#xAF; : #xAF; amp;#xB0; : #xB0; amp;#xB1; : #xB1; amp;#xB2; : #xB2; amp;#xB3; : #xB3; amp;#xB4; : #xB4; amp;#xB5; : #xB5; amp;#xB6; : #xB6; amp;#xB7; : #xB7; amp;#xB8; : #xB8; amp;#xB9; : #xB9; amp;#xBA; : #xBA; amp;#xBB; : #xBB; amp;#xBC; : #xBC; amp;#xBD; : #xBD; amp;#xBE; : #xBE; amp;#xBF; : #xBF; amp;#xC0; : #xC0; amp;#xC1; : #xC1; amp;#xC2; : #xC2; amp;#xC3; : #xC3; amp;#xC4; : #xC4; amp;#xC5; : #xC5; amp;#xC6; : #xC6; amp;#xC7; : #xC7; amp;#xC8; : #xC8; amp;#xC9; : #xC9; amp;#xCA; : #xCA; amp;#xCB; : #xCB; amp;#xCC; : #xCC; amp;#xCD; : #xCD; amp;#xCE; : #xCE; amp;#xCF; : #xCF; amp;#xD0; : #xD0; amp;#xD1; : #xD1; amp;#xD2; : #xD2; amp;#xD3; : #xD3; amp;#xD4; : #xD4; amp;#xD5; : #xD5; amp;#xD6; : #xD6; amp;#xD7; : #xD7; amp;#xD8; : #xD8; amp;#xD9; : #xD9; amp;#xDA; : #xDA; amp;#xDB; : #xDB; amp;#xDC; : #xDC; amp;#xDD; : #xDD; amp;#xDE; : #xDE; amp;#xDF; : #xDF
cvs commit: xml-fop/src/org/apache/fop/layoutmgr/table Row.java
keiron 2002/12/27 06:00:44
Modified:src/org/apache/fop/layoutmgr/table Row.java
Log:
properly check if row finished
Revision ChangesPath
1.9 +11 -2 xml-fop/src/org/apache/fop/layoutmgr/table/Row.java
Index: Row.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/table/Row.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Row.java 29 Nov 2002 23:18:56 - 1.8
+++ Row.java 27 Dec 2002 14:00:44 - 1.9
@@ -200,7 +200,16 @@
MinOptMax rowSize = new MinOptMax(min, opt, max);
-setFinished(true);
+boolean fin = true;
+cellcount = 0;
+while ((curLM = getCellLM(cellcount++)) != null) {
+if (!curLM.isFinished()) {
+fin = false;
+break;
+}
+}
+
+setFinished(fin);
RowPosition rp = new RowPosition(this, breakList.size() - 1, breakList);
BreakPoss breakPoss = new BreakPoss(rp);
if (over) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Overconstraint Anomalous documents page in Wiki
On Fri, 2002-12-27 at 14:36, Rhett Aultman wrote: Thanks. I'd really like to get the ball to start rolling on this so that overconstraint can be readily included in with the layout system...figured the new Wiki was a good way to get a little documentation together on this. Anyone with an interest in this topic...please pile the material in there. Also, Keiron, do you think that maybe we might be able to gather together your current pontifications regarding layout? I think it's a very relevant page to put up in the Wiki. I'm happy to write the page if you can help me find the appropriate content. I suppose you mean this: http://marc.theaimsgroup.com/?l=fop-devm=103953681203554w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF transforms (was: Re: File prefix again)
On Sun, 2002-12-22 at 02:18, Kevin O'Neill wrote: It would be possible to do some work with Fop so that it can: - convert xsl:fo to paged xml Is the paged XML a new or existing format? A new format for now at least. It is possible there will be a w3c defined format. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs/design extending.xml
keiron 2002/12/23 02:46:10
Modified:src/documentation/content/xdocs/design extending.xml
Log:
better formatting for example
Revision ChangesPath
1.5 +9 -8 xml-fop/src/documentation/content/xdocs/design/extending.xml
Index: extending.xml
===
RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/design/extending.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- extending.xml 29 Nov 2002 22:00:32 - 1.4
+++ extending.xml 23 Dec 2002 10:46:10 - 1.5
@@ -85,15 +85,16 @@
document into PDF markup.
/p
p
-eg.
-code![CDATA[my:script-link script=app.execMenuItem('AcroSrch:Query');
+For example:/p
+source![CDATA[my:script-link script=app.execMenuItem('AcroSrch:Query');
Search
-/my:script-link]]/code
-
-to result in a text box referencing the following PDF action:
-code![CDATA[ /S /JavaScript /JS (app.execMenuItem(AcroSrch:Query);)
]]/code
-
- /p
+/my:script-link]]/source
+p
+to result in a text box referencing the following PDF action:/p
+source![CDATA[
+/S /JavaScript
+/JS (app.execMenuItem(AcroSrch:Query);)
+]]/source
/section
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/layoutmgr/table TableLayoutManager.java Body.java
keiron 2002/12/23 02:54:52
Modified:src/org/apache/fop/layoutmgr/table TableLayoutManager.java
Body.java
Log:
ignore tables without columns for now
Revision ChangesPath
1.8 +3 -1
xml-fop/src/org/apache/fop/layoutmgr/table/TableLayoutManager.java
Index: TableLayoutManager.java
===
RCS file:
/home/cvs/xml-fop/src/org/apache/fop/layoutmgr/table/TableLayoutManager.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- TableLayoutManager.java 29 Nov 2002 23:18:56 - 1.7
+++ TableLayoutManager.java 23 Dec 2002 10:54:52 - 1.8
@@ -117,6 +117,7 @@
MinOptMax headerSize = null;
if (tableHeader != null) {
+tableHeader.setUserAgent(getUserAgent());
tableHeader.resetPosition(null);
headerBreak = getHeight(tableHeader, context);
headerSize = headerBreak.getStackingSize();
@@ -125,6 +126,7 @@
MinOptMax footerSize = null;
if (tableFooter != null) {
+tableFooter.setUserAgent(getUserAgent());
tableFooter.resetPosition(null);
footerBreak = getHeight(tableFooter, context);
footerSize = footerBreak.getStackingSize();
1.8 +7 -1 xml-fop/src/org/apache/fop/layoutmgr/table/Body.java
Index: Body.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/table/Body.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Body.java 18 Nov 2002 15:54:15 - 1.7
+++ Body.java 23 Dec 2002 10:54:52 - 1.8
@@ -86,6 +86,12 @@
MinOptMax stackSize = new MinOptMax();
BreakPoss lastPos = null;
+if (columns == null) {
+setFinished(true);
+getLogger().warn(ignoring table body with undefined columns);
+return null;
+}
+
while ((curLM = (Row)getChildLM()) != null) {
// Make break positions
// Set up a LayoutContext
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PDF transforms (was: Re: File prefix again)
On Thu, 2002-12-19 at 21:15, Jeremias Maerki wrote: All cool, but how exactly is that better than having a PDF template that is stitched behind or in front of the FOP result using iText or PJ? Works well. Ok, PDF reading with our own library is a bonus as is better XML output for debugging. But I don't see any immediate need for this at the moment given our limited resources. Or do I miss anything? Well I'm not really suggesting is is high priority, just an idea. One things is that the XML and the additions can work both in and out of Fop. At least outputing SAX in the XMLRenderer would probably be an improvement. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Happy Holidays
On Thu, 2002-12-19 at 16:30, Arved Sandstrom wrote: I'd like to wish everyone here happy holidays, whatever is appropriate. This is a good crowd. +1 :-) Regards, Arved Sandstrom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo PropertyList.java
keiron 2002/12/19 00:12:04
Modified:src/org/apache/fop/fo PropertyList.java
Log:
compare to correct string
Revision ChangesPath
1.19 +2 -2 xml-fop/src/org/apache/fop/fo/PropertyList.java
Index: PropertyList.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/PropertyList.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- PropertyList.java 25 Oct 2002 09:29:41 - 1.18
+++ PropertyList.java 19 Dec 2002 08:12:04 - 1.19
@@ -255,7 +255,7 @@
// if value is inherit then get computed value from
// parent
-if(p != null inherit.equals(p.getString())) {
+if(p != null inherit.equals(p.getSpecifiedValue())) {
if (this.parentPropertyList != null) {
p = parentPropertyList.get(propertyName, true, false);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/image ImageFactory.java
keiron 2002/12/19 00:13:18
Modified:src/org/apache/fop/image ImageFactory.java
Log:
add method to remove context
Revision ChangesPath
1.12 +10 -1 xml-fop/src/org/apache/fop/image/ImageFactory.java
Index: ImageFactory.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/image/ImageFactory.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ImageFactory.java 29 Nov 2002 23:18:55 - 1.11
+++ ImageFactory.java 19 Dec 2002 08:13:18 - 1.12
@@ -108,6 +108,15 @@
}
/**
+ * Release the context and all images in the context.
+ *
+ * @param context the context to remove
+ */
+public void removeContext(FOUserAgent context) {
+cache.removeContext(context);
+}
+
+/**
* create an FopImage objects.
* @param href image URL as a String
* @return a new FopImage object
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/render/pdf PDFRenderer.java
keiron 2002/12/18 06:50:35
Modified:src/org/apache/fop/render/pdf PDFRenderer.java
Log:
clear data when stopping renderer
Revision ChangesPath
1.133 +13 -3 xml-fop/src/org/apache/fop/render/pdf/PDFRenderer.java
Index: PDFRenderer.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/pdf/PDFRenderer.java,v
retrieving revision 1.132
retrieving revision 1.133
diff -u -r1.132 -r1.133
--- PDFRenderer.java 29 Nov 2002 23:18:57 - 1.132
+++ PDFRenderer.java 18 Dec 2002 14:50:35 - 1.133
@@ -145,8 +145,6 @@
// drawing state
protected PDFState currentState = null;
-protected PDFColor currentFillColor = new PDFColor(255, 255, 255);
-protected PDFColor currentStrokeColor = new PDFColor(0, 0, 0);
protected String currentFontName = ;
protected int currentFontSize = 0;
protected int pageHeight;
@@ -266,6 +264,18 @@
this.pdfDoc = null;
ostream = null;
+
+pages = null;
+
+pageReferences.clear();
+pvReferences.clear();
+pdfResources = null;
+currentStream = null;
+currentContext = null;
+currentPage = null;
+currentState = null;
+currentFontName = ;
+wordAreaPDF = new StringBuffer();
}
public boolean supportsOutOfOrder() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AreaTree.AreaTreeModel
On Thu, 2002-12-19 at 00:56, Oleg Tkachenko wrote: Hello! Just curious, why AreaTreeModel is defined as static inner class of AreaTree class? It doesn't look like real inner class as it's abstract and has 3 implementations. Are there any objections against moving it out? Mainly it is there because that is where it was put first. The initial idea was that the model would be internal to the AreaTree and not really need to be known outside. The development has shown that the case is different and there will be external implementations, such as caching, which could be created in other places. So it would probably be better moved out, so go ahead. The implementations should also be moved out. By the way, I have checked that the area tree, renderer and pdf lib are not holding onto any memory apart from current working objects (when caching), such as a page and current pdf stream. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
PDF transforms (was: Re: File prefix again)
On Wed, 2002-12-18 at 15:23, Nicola Ken Barozzi wrote: I don't get this. How can PDFs be transformed? There are Java libraries that read PDFs. What would be really cool is to have a reader or something like it that uses a PDF as a template. Using FOP for just filling out forms is overkill, we just need templating. This is a general use case of PDF transformation, and another that I would really like to see is to generate a non-controlled copy stamp on the PDF for the management of ISO9001 documentation. Or simply by adding a copyright statement. Sounds like some good ideas. It would be possible to do some work with Fop so that it can: - convert xsl:fo to paged xml - convert paged xml to pdf (or other formats) - define templates with the paged xml - append paged xml to a current document So it would be possible to create the paged xml from fo. Then to do a transform or directly convert or append the paged xml to pdf. Also the extensions and foreign xml can be passed through directly so that both formats support the same extensions, such as svg. So the changes that would need to be made are: - improve and update xml renderer so that it can output SAX - improve and update AreaTreeBuilder so that it takes SAX input - make some additions to the pdf lib so it can load and read pdf documents Then it shouldn't be so hard to add in extensions for pdf forms etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo FOTreeBuilder.java
keiron 2002/12/17 00:32:12
Modified:src/org/apache/fop/fo FOTreeBuilder.java
Log:
nullify fo tree to release data
Revision ChangesPath
1.42 +5 -3 xml-fop/src/org/apache/fop/fo/FOTreeBuilder.java
Index: FOTreeBuilder.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/FOTreeBuilder.java,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- FOTreeBuilder.java16 Dec 2002 23:27:15 - 1.41
+++ FOTreeBuilder.java17 Dec 2002 08:32:12 - 1.42
@@ -127,6 +127,8 @@
*/
public void endDocument()
throws SAXException {
+rootFObj = null;
+currentFObj = null;
if (getLogger().isDebugEnabled())
getLogger().debug(Parsing of document complete);
structHandler.endDocument();
@@ -168,8 +170,8 @@
fobj.setName(localName);
// set the user agent for resolving user agent values
fobj.setUserAgent(userAgent);
-// set the stream renderer so that appropriate
-// elements can add pages and handle resolving references
+// set the structure handler so that appropriate
+// elements can signal structure events
fobj.setStructHandler(structHandler);
fobj.handleAttrs(attlist);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
