DO NOT REPLY [Bug 25997] - [PATCH] Basic OpenType CFF Support for maintenance branch: 3 Patches
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25997. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25997 [PATCH] Basic OpenType CFF Support for maintenance branch: 3 Patches --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 08:38 --- related thread in FOP dev http://marc.theaimsgroup.com/?l=fop-devm=107342953607261w=2
Re: Using Just the Font Metrics Stuff From FOP
Glen Mazza wrote: Yes, an explanation in Bugzilla on what the patches are for (I haven't been following the thread, and if it takes some weeks to be applied, no one will remember what they're for.) You're welcome to provide a link to the FOP archives to cut down on re-typing. Ok - Ive added links to the archives. Chris
cvs commit: xml-fop/examples/embedding/java/embedding ExampleDOM2PDF.java
jeremias2004/01/09 00:56:43
Modified:examples/embedding/java/embedding ExampleDOM2PDF.java
Log:
Style, javadoc and tab character fixes
Revision ChangesPath
1.3 +21 -15xml-fop/examples/embedding/java/embedding/ExampleDOM2PDF.java
Index: ExampleDOM2PDF.java
===
RCS file: /home/cvs/xml-fop/examples/embedding/java/embedding/ExampleDOM2PDF.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ExampleDOM2PDF.java 13 Aug 2003 23:19:57 - 1.2
+++ ExampleDOM2PDF.java 9 Jan 2004 08:56:43 - 1.3
@@ -4,7 +4,7 @@
*The Apache Software License, Version 1.1
*
*
- * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
+ * Copyright (C) 1999-2004 The Apache Software Foundation. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without modifica-
* tion, are permitted provided that the following conditions are met:
@@ -62,7 +62,6 @@
// DOM
import org.w3c.dom.Document;
import org.w3c.dom.Element;
-import org.w3c.dom.NamedNodeMap;
import org.w3c.dom.Node;
import org.w3c.dom.Text;
@@ -86,7 +85,7 @@
/**
* Converts a DOM Document to a PDF file using FOP.
- * @param doc the DOM Document
+ * @param xslfoDoc the DOM Document
* @param pdf the target PDF file
* @throws IOException In case of an I/O problem
* @throws FOPException In case of a FOP problem
@@ -166,7 +165,7 @@
ele2 = foDoc.createElementNS(foNS, fo:flow);
ele1.appendChild(ele2);
ele2.setAttributeNS(null, flow-name, xsl-region-body);
-AddElement(ele2, fo:block, Hello World!);
+addElement(ele2, fo:block, Hello World!);
ExampleDOM2PDF app = new ExampleDOM2PDF();
app.convertDOM2PDF(foDoc, pdffile);
@@ -178,15 +177,22 @@
}
}
- protected static void AddElement(Node parent, String newNodeName,
-String textVal)
- {
- if (textVal == null) return; // use only with text nodes
- Element newElement =
-parent.getOwnerDocument().createElementNS(foNS, newNodeName);
- Text elementText = parent.getOwnerDocument().createTextNode(textVal);
- newElement.appendChild(elementText);
- parent.appendChild(newElement);
- }
+/**
+ * Adds an element to the DOM.
+ * @param parent parent node to attach the new element to
+ * @param newNodeName name of the new node
+ * @param textVal content of the element
+ */
+protected static void addElement(Node parent, String newNodeName,
+String textVal) {
+if (textVal == null) {
+return;
+} // use only with text nodes
+Element newElement = parent.getOwnerDocument().createElementNS(
+foNS, newNodeName);
+Text elementText = parent.getOwnerDocument().createTextNode(textVal);
+newElement.appendChild(elementText);
+parent.appendChild(newElement);
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Remember to update the copyright year
Fellow committers We've got a new year. Please remember to update the copyright year on every file you change. Jeremias Maerki
DO NOT REPLY [Bug 25999] - [PATCH] Basic OpenType CFF Support for development branch: 3 Patches
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25999. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25999 [PATCH] Basic OpenType CFF Support for development branch: 3 Patches --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 09:15 --- I've got trouble applying your patch. Would you please add it as an attachment, please? Bugzilla does some line-breaking which messes up the patch. As an optional bonus it would be cool if you could remove the tab characters and replace them with 4 spaces each. Thanks!
Chris and Andreas: New committers, send your CLAs
Enough time has passed since I cast the three votes for new committers. I'm a bit disappointed that Clay's vote didn't pass but I guess we need to give it some time. Chris passed with 6 +1s, Andreas with 5. No -1s anymore. So, Chris and Andreas, we need your preferred unix usernames and the email address you would like to have uid@apache.org forwarded to. At least as important is to immedidately sign the Contributors License agreement (CLA) and send (or fax) it to the Apache Software Foundation as fast as possible. I'd send it in paper, even if it takes longer there's a higher chance of immediate success. You only get the account if the CLA has been received. Find the CLA here: http://www.apache.org/licenses#clas As a new committer there are a few things to learn: http://incubator.apache.org/learn/newcommitters.html http://incubator.apache.org/learn/ Jeremias Maerki
Re: Chris and Andreas: New committers, send your CLAs
Jeremias Maerki wrote: So, Chris and Andreas, we need your preferred unix usernames and the email address you would like to have uid@apache.org forwarded to. Preferred User Name: cbowditch email forwarding address: [EMAIL PROTECTED] At least as important is to immedidately sign the Contributors License agreement (CLA) and send (or fax) it to the Apache Software Foundation as fast as possible. I'd send it in paper, even if it takes longer there's a higher chance of immediate success. You only get the account if the CLA has been received. Find the CLA here: http://www.apache.org/licenses#clas Ok, i'll get this in the post. Thanks very much, Chris
Re: Chris and Andreas: New committers, send your CLAs
On Jan 9, 2004, at 1:33 AM, Jeremias Maerki wrote: Enough time has passed since I cast the three votes for new committers. I'm a bit disappointed that Clay's vote didn't pass but I guess we need to give it some time. I'm a bit disappointed too, although I'm ecstatic I don't have to wonder any more. The suspense was killing me! :-) Chris passed with 6 +1s, Andreas with 5. No -1s anymore. Congratulations Chris and Andreas! May you see the release of FOP 1.0! Web Maestro Clay
multi page-sequence don't work for (XML+XSL) to PDF on the fly
Hi FOP DevTeam, I developed a way to generate multiple page-sequence on XSL without to change my XML, but the XML-XSL-PDF don't work, to make this work, first I need to generate the .fo file, then transform this to PDF. if run: fop.sh -xml sample.xml -xsl multiplePageSequence.xsl -pdf sample.pdf I get follow output: [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] FOP 0.20.5 [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] building formatting object tree [INFO] setting up fonts [ERROR] org.apache.fop.apps.FOPException: flow must be child of page-sequence, not fo:flow but if I first generate the .fo file with: xalan.sh -IN sample.xml -XSL multiplePageSequence.xsl -OUT sample.fo then generate the .pdf file from .fo file with: fop.sh -fo sample.fo -pdf sample.pdf I get the follow output: [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] FOP 0.20.5 [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] building formatting object tree [INFO] setting up fonts [INFO] [1] [INFO] [2] [INFO] [3] [INFO] [4] [INFO] Parsing of document complete, stopping renderer The part of XSL that cause on the fly transformation to catch the ERROR is: xsl:template name=ctrlPage xsl:if test=(position() mod 3) = 0 xsl:text disable-output-escaping=yes![CDATA[/fo:flow/fo:page-sequencefo:page-sequence master-reference=A4 language=pt country=br]]/xsl:text xsl:call-template name=header/ xsl:text disable-output-escaping=yes![CDATA[fo:flow flow-name=xsl-region-body]]/xsl:text /xsl:if /xsl:template to close and open fo:flow and fo:page-sequence for xsl:template match=data fo:page-sequence master-reference=A4 language=pt country=br xsl:call-template name=header/ fo:flow flow-name=xsl-region-body xsl:apply-templates / /fo:flow /fo:page-sequence /xsl:template I can't understand because on the fly don't woks and from .fo file generated from xml+xsl transformation work, maybe a bug of FOP, or I can't generate XML elements using CDATA from this form. I post this in dev list because I think that this is a feature or a bug on FOP then I attached the XSL and XML files that the team can test this issue, and the code is better to read than my bad English ;) Thanks for any help or tip Clovis ?xml version=1.0 encoding=ISO-8859-1? xsl:stylesheet version=1.0 xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:output method=xml/ xsl:template match=/ fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=A4 page-width=297mm page-height=210mm margin-top=5mm margin-bottom=5mm margin-left=3mm margin-right=5mm fo:region-before extent=20.8mm/ fo:region-body margin-top=21.8mm margin-bottom=0in/ fo:region-after extent=0in/ fo:region-start extent=0in margin-top=0mm margin-bottom=0mm margin-left=0mm margin-right=0mm/ fo:region-end extent=0in margin-top=0mm margin-bottom=0mm margin-left=0mm margin-right=0mm/ /fo:simple-page-master /fo:layout-master-set xsl:apply-templates / /fo:root /xsl:template xsl:template match=info/xsl:template xsl:template match=data fo:page-sequence master-reference=A4 language=pt country=br xsl:call-template name=header/ fo:flow flow-name=xsl-region-body xsl:apply-templates / /fo:flow /fo:page-sequence /xsl:template xsl:template match=product xsl:call-template name=detail / /xsl:template !-- Header For Pages -- xsl:template name=header fo:static-content flow-name=xsl-region-before fo:table table-layout=fixed fo:table-column column-width=40mm/ fo:table-column column-width=40mm/ fo:table-column column-width=40mm/ fo:table-body fo:table-row fo:table-cell fo:blockHEADER CEL 1/fo:block /fo:table-cell fo:table-cell fo:blockHEADER CEL 2/fo:block /fo:table-cell fo:table-cell fo:blockHEADER CEL 3/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:static-content /xsl:template !-- Control Page Sequence Creation -- xsl:template name=ctrlPage xsl:if test=(position() mod 3) = 0 xsl:text disable-output-escaping=yes![CDATA[/fo:flow/fo:page-sequencefo:page-sequence master-reference=A4
Re: multi page-sequence don't work for (XML+XSL) to PDF on the fly
On 09.01.2004 18:29:14 Clóvis Wichoski wrote: snip/ xsl:template name=ctrlPage xsl:if test=(position() mod 3) = 0 xsl:text disable-output-escaping=yes![CDATA[/fo:flow/fo:page-sequencefo:page-sequence master-reference=A4 language=pt country=br]]/xsl:text xsl:call-template name=header/ xsl:text disable-output-escaping=yes![CDATA[fo:flow flow-name=xsl-region-body]]/xsl:text /xsl:if /xsl:template The problem is that you put some XML code into a CDATA section. On-the-fly processing works with SAX. And in SAX your code will be delivered as text instead of as elements. snip/ I can't understand because on the fly don't woks and from .fo file generated from xml+xsl transformation work, maybe a bug of FOP, or I can't generate XML elements using CDATA from this form. The latter. I post this in dev list because I think that this is a feature or a bug on FOP then I attached the XSL and XML files that the team can test this issue, and the code is better to read than my bad English ;) Well, bad luck. Your issue would have been a better fit for fop-user. Jeremias Maerki
Justification in HEAD
Fellow FOP Devs, I've been thnking about how to implement Justified text in HEAD, and would appreciate some suggestions/comments on my thought process. I know Joerg posted something on this back in November in which he said the missing piece was the renderer not resizing the spaces, but the problem is deeper than this. The child LM of Line LM is Text LM. It appears that when dealing with just plain text paragraphs, i.e. no fo:inlines or fo:wrapper changing fonts within a line, etc, then there is almost a 1:1 relationship between Line LM and Text LM. So when renderText is called on the renderer it is presented with a whole line of text, and there is no opportunity to insert extra spaces. Unless the renderer is going to break this string and place individual characters, but that to me seems wrong. So question is should TextLM.getNextBreakPoss be splitting the line into individual words? Which can then be placed by the renderer with the space adjustment required for justification. I believe this is similar to how it works in the maintenance branch. Although I'm sure TextLM is keeping lines together for a good reason. Chris
Re: multi page-sequence don't work for (XML+XSL) to PDF on the fly
Hi Jeremias, The CDATA is only to maintain the XSL well-formed, since I close fo:flow on another template, the tech is good, maybe dev team implement a SAX over the stream from XML+XSL transformation option, this is the feature that I mean. Note that this is to reduce memory consuption. Best regards Clovis Jeremias Maerki wrote: On 09.01.2004 18:29:14 Clvis Wichoski wrote: snip/ xsl:template name="ctrlPage" xsl:if test="(position() mod 3) = 0" xsl:text disable-output-escaping="yes"![CDATA[/fo:flow/fo:page-sequencefo:page-sequence master-reference="A4" language="pt" country="br"]]/xsl:text xsl:call-template name="header"/ xsl:text disable-output-escaping="yes"![CDATA[fo:flow flow-name="xsl-region-body"]]/xsl:text /xsl:if /xsl:template The problem is that you put some XML code into a CDATA section. On-the-fly processing works with SAX. And in SAX your code will be delivered as text instead of as elements. snip/ I can't understand because on the fly don't woks and from .fo file generated from xml+xsl transformation work, maybe a bug of FOP, or I can't generate XML elements using CDATA from this form. The latter. I post this in dev list because I think that this is a feature or a bug on FOP then I attached the XSL and XML files that the team can test this issue, and the code is better to read than my bad English ;) Well, bad luck. Your issue would have been a better fit for fop-user. Jeremias Maerki
Problems with new Driver()
I receive this error FopJsp_jsp - java.lang.IllegalArgumentException: org.apache.fop.svg.SVGElementMapping is not an ElementMapping when I inizialize the Driver of FOP with the costructor Driver driver = new Driver() What's the problems? I use Oc4j as stand alone application Server The inizialization above is in the public void jspInit() method of a Jsp (FopJsp.jsp). This FopJsp.jsp was already used with Jserv as servlet/Jsp container and it don't give any problems. The version of fop that I use is the 0.20.5rc; I try also to use the 0.20.5 but the problems is the same. Thanks a lot and Best Regards Luca Lorenzon Stefano Masselli
Re: multi page-sequence don't work for (XML+XSL) to PDF on the fly
Clóvis Wichoski wrote: The CDATA is only to maintain the XSL well-formed, since I close fo:flow on another template, Opening and closing XML tags within different XSL templates is bad practice. You'll need to redesign your XSL stylesheet or run the XSL Transform as a separate process, serialize the resulting FO and then present the FO to FOP. the tech is good, maybe dev team implement a SAX over the stream from XML+XSL transformation option, this is the feature that I mean. This isnt very clear, but if you mean serializing the result of the XSL transform before processing the FO then I wouldnt see this as a desirable feature for FOP. Mainly because it will slow down processing. If users require this functionality then they can implement it themselves very easily as I suggested above. Note that this is to reduce memory consuption. Chris
Re: multi page-sequence don't work for (XML+XSL) to PDF on the fly
Chris Bowditch wrote: Opening and closing XML tags within different XSL templates is bad practice. You'll need to redesign your XSL stylesheet or run the XSL Transform as a separate process, serialize the resulting FO and then present the FO to FOP. But with multiple pages like 500 pages the redesign must be in XML source, that need redesign in all XSL too (HTML, PDF, TXT and many others), this cause a rework that I attempted to avoid, and only needed because FOP throubles with memory, this is only a relief. Thanks for all reply Clovis
Re: multi page-sequence don't work for (XML+XSL) to PDF on the fly
This is just a guess, but perhaps you could do a pre-pass using XSL to generate multiple output pages, and then use something like iText[1] to concatenate your output files together. FOP Resources: http://xml.apache.org/fop/resources.html I hope this helps! Web Maestro Clay On Jan 9, 2004, at 10:45 AM, Clóvis Wichoski wrote: Chris Bowditch wrote: Opening and closing XML tags within different XSL templates is bad practice. You'll need to redesign your XSL stylesheet or run the XSL Transform as a separate process, serialize the resulting FO and then present the FO to FOP. But with multiple pages like 500 pages the redesign must be in XML source, that need redesign in all XSL too (HTML, PDF, TXT and many others), this cause a rework that I attempted to avoid, and only needed because FOP throubles with memory, this is only a relief. Thanks for all reply Clovis
Re: Problems with new Driver()
Luca Lorenzon wrote: I receive this error FopJsp_jsp - java.lang.IllegalArgumentException: org.apache.fop.svg.SVGElementMapping is not an ElementMapping This means the code loading the element mappings does not recognize the SVGElementMapping as an ElementMapping, as it expects. The most likely reason is that they are loaded from different class loaders - welcome to class loader hell. ... I use Oc4j as stand alone application Server You'll probably have to ask on the application server's list for a solution. I guess you call servlets/JSPs across web applications, but there may be other reasons. It's definitely not a fault with the FOP code. J.Pietschmann
Re: Justification in HEAD
Chris,
On Fri, Jan 09, 2004 at 05:20:42PM +, Chris Bowditch wrote:
Chris Bowditch wrote:
The problem isnt that TextLM.getNextBreakPoss isnt finding BPs, problem
is with addAreas, which, just skips over all the BPs and creates a
single TextArea. This is evident from the following at the start of
TextLM.addAreas:
/* On first area created, add any leading space.
* Calculate word-space stretch value.
*/
while (posIter.hasNext()) {
LeafPosition tbpNext = (LeafPosition) posIter.next();
ai = (AreaInfo) vecAreaInfo.get(tbpNext.getLeafPos());
if (iStart == -1) {
iStart = ai.iStartIndex;
}
iWScount += ai.iWScount;
}
This loop only counts word spaces. Later the member iTSadjust is set
on the text area: t.setTSadjust(iAdjust / iWScount). It seems that
this is supposed to take care of space stretching, I do not know
how. I guess the renderer should know how to use this information. In
my test runs, it is equal to 0, which explains the lack of
justification. I am not sure whether it is necessary to break up the
text area into pieces.
The real calculations are happening much earlier, in the
getNextBreakPoss loop. In LineLayoutManager.makeLineBreak, ipdAdjust
and dAdjust are calculated based on the length of the line, and set as
members on the new linebreak position. In the ensuing addAreas loop,
LineLayoutManager.addAreas fetches these again from the linebreak
position and sets them on the layout context. From there they are
fetched by the above calculation and used in calculating iTSadjust --
with little succes at the moment.
ipdAdjust seems to be for scaling between min, opt and max. dAdjust
seems to be the scaling for justification.
These are my thoughts on the process.
Regards, Simon
--
Simon Pepping
email: [EMAIL PROTECTED]
home page: http://www.leverkruid.nl
public key: http://www.leverkruid.nl/personal/sp.asc
fingerprint: E3BF 7295 9AA8 8B8A C01A 219D FAAC 088C 6B28 F549
DO NOT REPLY [Bug 25810] - [PATCH] support for property=inherit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25810. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25810 [PATCH] support for property=inherit [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 22:32 --- Looks good--applied--thanks!
Re: Remember to update the copyright year
Jeremias Maerki wrote: Fellow committers We've got a new year. Please remember to update the copyright year on every file you change. Thanks for the reminder, Jeremias. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: Chris and Andreas: New committers, send your CLAs
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Enough time has passed since I cast the three votes for new committers. I'm a bit disappointed that Clay's vote didn't pass but I guess we need to give it some time. Yeah, as I already mentioned off-list to others, I'm very glad he replied that he'll be back for more (*that*'s the spirit). So, Chris and Andreas, we need your preferred unix usernames and the email address you would like to have uid@apache.org forwarded to. preferred username : is 'andreas' already taken? If so, 'adelmelle' will do just fine forward mail to [EMAIL PROTECTED] At least as important is to immedidately sign the Contributors License agreement (CLA) and send (or fax) it to the Apache Software Foundation as fast as possible. I'd send it in paper, even if it takes longer OK. I'll fax on Monday, and send a copy by snail-mail (just to make sure). there's a higher chance of immediate success. You only get the account if the CLA has been received. Find the CLA here: http://www.apache.org/licenses#clas As a new committer there are a few things to learn: http://incubator.apache.org/learn/newcommitters.html http://incubator.apache.org/learn/ Thanks for the info. Great to be aboard! Cheers, Andreas
RE: Problems with new Driver()
-Original Message- From: Luca Lorenzon [mailto:[EMAIL PROTECTED] snip / I use Oc4j as stand alone application Server Doesn't OC4J ship with its own JDK? If I remember correctly, the problem here is that the XML parsers supplied by Oracle are incompatible with FOP. As Joerg already (partly) suggested: make sure the Xerces and Xalan jars in the FOP distro are loaded *before* the Oracle XML-related libs (or just replace the latter by the former). Should work. Cheers, Andreas
Re: Remember to update the copyright year
Yes, thanks--I just forgot to a few minutes ago though :( I'll leave a message on my monitor to reduce the chances of me forgetting. Glen --- Peter B. West [EMAIL PROTECTED] wrote: Jeremias Maerki wrote: Fellow committers We've got a new year. Please remember to update the copyright year on every file you change. Thanks for the reminder, Jeremias. Peter -- __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
RE: multi page-sequence don't work for (XML+XSL) to PDF on the fly
-Original Message- From: Clovis Wichoski [mailto:[EMAIL PROTECTED] snip / But with multiple pages like 500 pages the redesign must be in XML source, that need redesign in all XSL too (HTML, PDF, TXT and many others), this cause a rework that I attempted to avoid, and only needed because FOP throubles with memory, this is only a relief. Hi, Can't you use multiple page-sequences instead of just creating one sequence 'interrupted' by the 'ctrlPage' template? A few remarks to help you on your way: 1. I can't seem to find the reason why you are placing the whole fo:static-content into a separate template, since it is ... well, static and it doesn't rely on the elements in the XML (unless something is missing). 2. In the ctrlPage template, you are testing for a position(): you could also use XPath to select these, like xsl:apply-templates select=product[(position() mod 3) = 0] Then inside the product template, use xsl:for-each select=preceding::product[position() 3] / to grab the two preceding product nodes. 3. Check our http://xml.apache.org/fop/resources.html page, among the books and articles, there's a link to Dave Pawson's XSLT FAQ. Over there, you'll find a lot of useful stuff (amongst others on grouping which I think you'll find particularly helpful), so I'll bet you can work out a redesign which affects only the XSL itself and leaves the other files alone. If you really can't get any further, try posting your problem on Mulberry's XSLT list. Warning: it's a quite high-traffic list, but the upside is that the tips are 'highly-usable' ;) Hope this helps! Cheers, Andreas
DO NOT REPLY [Bug 25933] - [PATCH] Fix for handling column-spanning ( and a few column props )
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25933. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25933 [PATCH] Fix for handling column-spanning ( and a few column props ) --- Additional Comments From [EMAIL PROTECTED] 2004-01-10 00:25 --- OK, I think I found the solution to the first case (as already mentioned to Finn off-list): The first patch adds a for-loop to Table.addChild(). In case of a 3-column-span this created 1 column with i.e. column-number = 1, but increased the index of the following column to 4. However, further on, in the Row LM, a cell in the spanning column would need access to column 1, 2 and 3 for their respective widths. The latter two weren't created... so an AIOOBE was thrown. Fixed this by adding an inner for-loop to create the 'table-grid' columns, so now in the same case 3 columns would be added as children to the table ( while only one has been specified in the FO; in case fo:table-column number-columns-spanned=3 number-columns-repeated=3 / I believe 9 columns should be created to allow the Row LMs to calculate the cell-widths, if not specified). The second case I believe to have been partially caused/resolved by the patch Glen applied earlier today (bugzilla ref. 25809)... IIC, Finn was already using the altered version at home/work, so that would explain why this was working before. *But* an NPE gets thrown anyway because the TableRow would need access to the TableColumns, and Finn's patch adds the 'column' in AddLMVisitor, so it would not yet be available at FO Tree stage. Revised patch will be posted (I hope) later this weekend.
RE: Remember to update the copyright year
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] We've got a new year. Please remember to update the copyright year on every file you change. If nobody objects, this seems like an ideal pesky task for a freshman... I mean: would it help if I (or Chris, or Clay ;P ) just checked out all of HEAD (to begin with), run a S R script on all the java and generator sources to update the year and enter it as a patch in Bugzilla or something? Unless the intention is to only update files that are actually changed. In that case I haven't posted anything. Cheers, Andreas
[Bug 25480] - [PATCH] Experimental performance improvements.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-01-10 Glen / Finn, Hope you don't mind my interrupting here: Particularly this point I found interesting: 3.) PropertySets.java defines those properties which are valid for each FO--in PropertyList, the proposed implementation then uses that information to limit the properties that can be assigned to an FObj (i.e., only those defined as valid for it.) Am I correct here on this point? If so, we may need to expand the valid properties to include the inheritable ones. snip / Do we need to expand then the property sets for each FO to include the inheritable properties (you may already have done so, I'm not sure if those were included)--and do we also need to somehow additionally qualify *those* properties as valid for the FO but not directly relevant for it? (I think yes for the first question, no for the second.) IIC the initial strategy WRT inherited properties was to add methods to the FObj's to get these from their parent. I think the problem with this implementation is that, in the case of very large documents with deeply nested elements that inherit a property which is specified at the top-level, you would end up with one getter being dispatched to the parent's getter, and this in its turn being dispatched to yet another ancestor's getter (or Makers in case of Property creation)... In this case, however, I think you can't fully 'push' these onto the descendants, as this would lead to absurd storage-reqs for quite average-sized documents. OTOH, the inherited property value (resolved or unresolved) can indeed be supposed as available at parse time, because a parent is per se processed *before* any of its children. I just wonder if this has something to do with Finn's other idea of moving logic to the property side to save on unnecessary calls to empty methods ? 4.) Finally, I'm too far removed from my C programming days to understand the math here: this.specified = new int[(indices[0] 5) + 1]; He's dividing the value by 32 [or 2^5], right? (where indices[0] defines the number of properties valid for the FObj) also, in putSpecified(int idx, Property value), you code this: specified[i 5] |= 1 (i 31); I'm not clear what this is doing either. What does putSpecified() do, and what's the point of the i 31 and the Or'ing? I *definitely* *have* *to* take a closer look at that code! I *definitely* *have* *to* take a closer look at that code! I *definitely* *have* *to* take a closer look at that code! ... That's all I can add for you now, Glen. Sorry :( Cheers, Andreas
Re: Fix for handling column-spanning ( and a few column props )
--- Additional Comments From [EMAIL PROTECTED] 2004-01-10 00:25 --- OK, I think I found the solution to the first case (as already mentioned to Finn off-list): Re: off-list discussions. My own view is that off-list discussion should be restricted to personal or inter-personal matters. I have only posted off-list on a few occasions, and I think three times before doing so. If the question is at all technical, post to the list. This is how all of the developers keep abreast of the development of ideas in design and implementation. If we don't follow this policy, we risk fostering cliques, and anyone who tries to follow the development of an idea in the archive will be at a loss. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Fix for handling column-spanning ( and a few column props )
Peter B. West wrote: --- Additional Comments From [EMAIL PROTECTED] 2004-01-10 00:25 --- OK, I think I found the solution to the first case (as already mentioned to Finn off-list): Re: off-list discussions. My own view is that off-list discussion should be restricted to personal or inter-personal matters. I have only posted off-list on a few occasions, and I think three times before doing so. If the question is at all technical, post to the list. This is how all of the developers keep abreast of the development of ideas in design and implementation. If we don't follow this policy, we risk fostering cliques, and anyone who tries to follow the development of an idea in the archive will be at a loss. P.S. Lest anyone think this is directed at him, I confess to being a recent culprit in my discussions with John about patches to alt.design. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Remember to update the copyright year
Andreas L. Delmelle wrote: If nobody objects, this seems like an ideal pesky task for a freshman... I mean: would it help if I (or Chris, or Clay ;P ) just checked out all of HEAD (to begin with), run a S R script on all the java and generator sources to update the year and enter it as a patch in Bugzilla or something? Unless the intention is to only update files that are actually changed. In that case I haven't posted anything. I'm not sure about this, but I would have thought we only change the notice in files that are modified. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Fix for handling column-spanning ( and a few column props )
Andreas L. Delmelle wrote:
Morning Peter! ('t is morning over there not? :) )
Completely agree with you on this. Was a mere exception, not being
subscribed to fop-dev at work. Just having a bit of spare time over there,
decided to have a look at Finn's test cases and in all my excitement I just
wanted to post it to _someone_.
Just so you know...
Enjoy your w.e.!
Afternoon. Working this w.e.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
cvs commit: xml-fop/src/java/org/apache/fop/fo FoRoot.java FONode.java
pbwest 2004/01/09 22:29:50 Modified:src/java/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design FoSimplePageMaster.java FoPageSequenceMaster.java FoLayoutMasterSet.java src/java/org/apache/fop/fo/flow Tag: FOP_0-20-0_Alt-Design FoFootnote.java FoTableBody.java FoMultiCase.java FoListBlock.java FoListItem.java FoTable.java FoPageSequence.java FoFloat.java FoStaticContent.java FoTitle.java FoFlow.java FoBasicLink.java FoBidiOverride.java FoLeader.java FoTableCell.java FoBlockContainer.java FoMultiToggle.java FoTableRow.java FoMultiProperties.java FoMultiSwitch.java FoWrapper.java FoMarker.java FoTableAndCaption.java FoListItemLabel.java FoTableHeader.java FoFootnoteBody.java FoBlock.java FoListItemBody.java FoInline.java FoTableCaption.java FoTableFooter.java FoInlineContainer.java src/java/org/apache/fop/xml Tag: FOP_0-20-0_Alt-Design XMLEventPool.java XMLEvent.java XMLNamespaces.java FoXMLSerialHandler.java SyncedFoXmlEventsBuffer.java FoXMLEvent.java src/java/org/apache/fop/fo/declarations Tag: FOP_0-20-0_Alt-Design FoDeclarations.java src/java/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FoRoot.java FONode.java Log: Switched to namespaces for control of pool. XMLNamespaces contains pools, sequence ids and masks for each known namespace. Discriminate DefAttrNSpace and XSLNSpace for FoMXLEvents. Revision ChangesPath No revision No revision 1.1.2.2 +18 -17 xml-fop/src/java/org/apache/fop/fo/pagination/Attic/FoSimplePageMaster.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/pagination/Attic/FoSimplePageMaster.java.diff?r1=1.1.2.1r2=1.1.2.2 1.1.2.3 +8 -7 xml-fop/src/java/org/apache/fop/fo/pagination/Attic/FoPageSequenceMaster.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/pagination/Attic/FoPageSequenceMaster.java.diff?r1=1.1.2.2r2=1.1.2.3 1.1.2.3 +5 -5 xml-fop/src/java/org/apache/fop/fo/pagination/Attic/FoLayoutMasterSet.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/pagination/Attic/FoLayoutMasterSet.java.diff?r1=1.1.2.2r2=1.1.2.3 No revision No revision 1.1.2.2 +5 -5 xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoFootnote.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoFootnote.java.diff?r1=1.1.2.1r2=1.1.2.2 1.1.2.2 +6 -6 xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoTableBody.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoTableBody.java.diff?r1=1.1.2.1r2=1.1.2.2 1.1.2.2 +5 -5 xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoMultiCase.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoMultiCase.java.diff?r1=1.1.2.1r2=1.1.2.2 1.1.2.2 +5 -5 xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoListBlock.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoListBlock.java.diff?r1=1.1.2.1r2=1.1.2.2 1.1.2.2 +6 -6 xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoListItem.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoListItem.java.diff?r1=1.1.2.1r2=1.1.2.2 1.1.2.2 +9 -9 xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoTable.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoTable.java.diff?r1=1.1.2.1r2=1.1.2.2 1.1.2.2 +7 -7 xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoPageSequence.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoPageSequence.java.diff?r1=1.1.2.1r2=1.1.2.2 1.1.2.2 +5 -5 xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoFloat.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoFloat.java.diff?r1=1.1.2.1r2=1.1.2.2 1.1.2.2 +5 -5 xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoStaticContent.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoStaticContent.java.diff?r1=1.1.2.1r2=1.1.2.2 1.1.2.2 +5 -5 xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoTitle.java http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/flow/Attic/FoTitle.java.diff?r1=1.1.2.1r2=1.1.2.2 1.1.2.2 +5 -5
cvs commit: xml-fop/src/java/org/apache/fop/xml FoXMLEventPool.java
pbwest 2004/01/09 22:35:15 Removed: src/java/org/apache/fop/xml Tag: FOP_0-20-0_Alt-Design FoXMLEventPool.java Log: No longer required. XMLEventPool and event definitions made general enough to deal with any types. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
