fop-user mail list automatically added footer
Hello there! This simple question was raised already, but still seems to be not solved. fop-user mail-list entries don't get automatically added footer about unsubscribing like fop-dev's ones have, look at the bottom of this letter. Some subscribers cannot find a way to unsubscribe and litter the list by requests. Dunno why but others mail me :) requests to remove them from fop-user list. Could somebody in charge take a care about it? -- Oleg Tkachenko eXperanto team Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
Although I'd appreciate the capability to produce RTF files from DocBook documents, I really don't think FOP would be the right tool to do it. RTF is not intended to provide full rendering capabilities, it is in scope somewhere between docbook and FO. It mixes style and content, the illness for which stylesheets where designed. I think it would be feasible to produce the RTF directly with XSLT stylesheets (it is text based anyway), and rely on Word and other RTF-aware editors to render the document. Has anyone tried that? I'd rather see FOP incorporate more crucial features like floats and auto tables then simply degrade a FO file into RTF. = Marcelo Jaccoud Amaral Petrobrás (http://www.petrobras.com.br) mailto:[EMAIL PROTECTED] voice: +55 21 2534-3485 fax: +55 21 2534-1809 = There are only 10 kinds of people in the world: those who understand binary and those who don't. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Where to start for an RTF renderer (was: New Developer Suggestion)
Yes, we've been talking about structure-based renderers (like RTF and MIF) vs. layout-based ones (PDF being the focal point) for some time. [ ... ] 4) My suggestion is to first use the RTF library from jfor in binary form, by including jfor's jar in the FOP distribution, to create the RTF document from the StructureHandler events. The current jfor code does a similar thing where the jfor Converter (jfor/jfor/converter/Converter) uses SAX events to drive the jfor RTF library. This makes sense, and I will start looking at it. But, as I said up front, nobody should count on my being able to accomplish this, and anyone who wants to do it will not offend me by going ahead and doing it without me. -- Scott .sig wanders off, mumbling something about learning CVS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: New Developer Suggestion
= J.Pietschmann [EMAIL PROTECTED] [ ... ]For working on HEAD, pick an area: - layout core - a renderer - the font subsystem - API and configuration - parsing and property resolution - FO extensions [ ... ] Thanks for the great suggestions. This one message taught me more about the system design than a month's worth of list-reading. And now, it's time to start looking at code. -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Where to start for an RTF renderer (was: New Developer Sugges tion)
Hi Scott, . . .anyone who wants to do it will not offend me by going ahead and doing it without me. . . . We haven't had too many volunteers lately in this area, so this shouldn't be a problem. Just make sure to send your patches early, without waiting for your enhancements to be finished. This will help coordinating your work with that of other developers. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Where to start for an RTF renderer (was: New Developer Sugges tion)
Hi Bertrand, . . .anyone who wants to do it will not offend me by going ahead and doing it without me. . . . We haven't had too many volunteers lately in this area, so this shouldn't be a problem. Well, I left mid-afternoon yesterday to deal with a sick child; I've been back in for two hours now, and I'm still 150 emails behind, so I don't know how much time I will find to dedicate to it... Just make sure to send your patches early, without waiting for your enhancements to be finished. This will help coordinating your work with that of other developers. Will do, as soon as I figure out how to get CVS past my company's new firewall. Problems, always problems. :( -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Patch for SVG scaling in external-graphic
As I have only been looking at the code for a couple of hours and I do not have CVS access at work I am attaching a patch. If this is not the correct way to send patches I appologise. It would seem that GIFs and JPEGs are automatically scaled to be the full size of the area into which they are to be dispayed (as defined by width= and height==). However SVG images are not scaled. This is because the width and height are not passed from PDFRenderer.drawImageScaled() to PDFRenderer.renderSVGDocument(). This patch added a width and height to the renderSVGDocument() method and uses them to correclty scale the SVG content to the size oft he Image Area. As I have only been looking at the code for a couple of hours I am sure tht this is not the best way to approach this problem, but it should give someone more experienced a base to work from. regards, Frugal svg_scale.patch svg_scale.patch Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: documentation
Christian Geisert wrote: Forrest offers one PDF per page at the moment (see http://outerthought.net/forrest/ for example) One PDF per page is fine, but it is inconvenient to download or print the whole. Item 1: The 0.20.4 release does not seem to have the fo.pdf file included, probably because the xmldoc files aren't in the maintenance branch (to build Because pdf generation was broken.. You must be talking about on the trunk, because I don't see xmldocs in the maint branch at all. The patch that I submitted should substantially fix the pdf generation that was broken in the trunk (I have more work here to submit as well). I'm too not sure what's the best .. Some time ago we decided to maintain the docs in the trunk only. For the 0.20.3 release I copied the xml-sources to the maintenance branch and build the docs there. You must mean in your local sandbox, just to get the build done? We already have some kind of developer documentation (called design docs). See http://xml.apache.org/fop/design/index.html, sources are in docs/design. Yep. That's most of the stuff that went into it, although there are a couple of other documents that are in docs/xmldocs/fop that went in as well (when I say went in, that is past tense for me, but I have not submitted that work yet). Eventually, I think some developer-oriented content should be culled from the user docs moved over to design/developer docs. It's quite complicated at the moment and Forrest should improve this but I don't see how this will happen at the moment. Well, in the meantime, unless my patch or approach messes up Joerg's work somehow, it seems reasonable to do what we can with what we have. Vic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/pagination FoLayoutMasterSet.java
pbwest 2002/10/10 10:07:00 Modified:src/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design FoLayoutMasterSet.java Log: Immediate initialisation of pageMasters and simplePageMasters. Revision ChangesPath No revision No revision 1.1.2.7 +5 -7 xml-fop/src/org/apache/fop/fo/pagination/Attic/FoLayoutMasterSet.java Index: FoLayoutMasterSet.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/pagination/Attic/FoLayoutMasterSet.java,v retrieving revision 1.1.2.6 retrieving revision 1.1.2.7 diff -u -r1.1.2.6 -r1.1.2.7 --- FoLayoutMasterSet.java9 Oct 2002 06:00:49 - 1.1.2.6 +++ FoLayoutMasterSet.java10 Oct 2002 17:06:59 - 1.1.2.7 @@ -53,13 +53,13 @@ * Hash of SimplePageMaster and PageSequenceMaster objects, * indexed by master-name of the object. */ -private HashMap pageMasters; +private HashMap pageMasters = new HashMap(); /** * Hash of SimplePageMaster objects, * indexed by master-name of the object. */ -private HashMap simplePageMasters; +private HashMap simplePageMasters = new HashMap(); /** * @param foTree the FO tree being built @@ -96,8 +96,6 @@ System.out.println(Found simple-page-master); simple = new FoSimplePageMaster(foTree, this, ev); simpleName = simple.getMasterName(); -if (pageMasters == null) -pageMasters = new HashMap(); if (pageMasters.get ((Object)(simpleName)) != null) throw new FOPException - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/xml XMLEvent.java
pbwest 2002/10/10 10:10:44
Modified:src/org/apache/fop/xml Tag: FOP_0-20-0_Alt-Design
XMLEvent.java
Log:
Make components of XMLEvent.UriLocalName public.
Revision ChangesPath
No revision
No revision
1.1.2.4 +6 -6 xml-fop/src/org/apache/fop/xml/Attic/XMLEvent.java
Index: XMLEvent.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/xml/Attic/XMLEvent.java,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- XMLEvent.java 9 Oct 2002 06:08:37 - 1.1.2.3
+++ XMLEvent.java 10 Oct 2002 17:10:44 - 1.1.2.4
@@ -218,11 +218,11 @@
/**
* A nested class for holding an passing a URI index and local name
- * pair, as used in the contain ttXMLEvent/tt class.
+ * pair, as used in the containing ttXMLEvent/tt class.
*/
public static class UriLocalName {
-private int uriIndex;
-private String localName;
+public int uriIndex;
+public String localName;
/**
* @param uriIndex - the index of the namespace URI maintained in
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
Peter B. West wrote: How is bidi support accessed in 1.3? Must you make your own determinations of directionality, or has the CDB BIDI data also been smuggled in? Well, some bidi support was in swing packages a long time ago but it seems to be intended entirely for system usage, e.g. javax.swing.text.Bidi class in jdk1.3 has package access level. Another one - sun.awt.font.Bidi is in Sun proprietary package but is public. It's not so rich as jdk1.4's one, among methods it has createLineBidi, getVisualToLogicalMap, getLevels etc and at least it knows all these LRM, RLM, PDF, LRO stuff. So, you right about jdk1.3 - it remains to be seen, another alternatives could be our own TR9 implementation (afaik renderx guys went this way last summer, probably because they have to support jdk1.1 and ms jvm) or some third-party implementation, e.g. ICU4J. -- Oleg Tkachenko eXperanto team Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
- Message d'origine - De : Oleg Tkachenko [EMAIL PROTECTED] So, you right about jdk1.3 - it remains to be seen, another alternatives could be our own TR9 implementation (afaik renderx guys went this way last summer, probably because they have to support jdk1.1 and ms jvm) or some third-party implementation, e.g. ICU4J. They also claim to have only limited (or basic) bidi support, if I recall properly. Did I understand properly Peter that FOP 1.0 should support Jdk 1.3 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
- Message d'origine - De : Peter B. West [EMAIL PROTECTED] Envoyé : 10 oct. 2002 20:40 Patrick, I'm just trying to determine the limits. At the moment 1.3 is needed to compile, because of TrueType font support, although users may continue to run the results in their existing 1.2 environments. There has been vigorous discussion for as long as I have subscribed to this list about migration to later JDK versions. This is perfectly justifiable for me, I just wanted this clarified. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
