DO NOT REPLY [Bug 1332] - MIF output strings not properly escaped
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=1332. 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=1332 MIF output strings not properly escaped [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 07:57 --- Done in 0.20.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 2995] - runtests.bat has a cvs merging error in the distribution
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=2995. 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=2995 runtests.bat has a cvs merging error in the distribution [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[patch] fix for background image tiling
Guys,
The attached patch implements PDFRenderer.drawImageClipped() properly,
so the right-most and bottom-most images of a tiled image background are
now clipped, rather than being scaled or overrun. It also removes a bit
of System.out cruft I left in the previous image bg patch.
Can a comitter please have a look at the patch and commit if happy.
Cheers,
Mike.
--
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555
? FopImageFactory.patch
? background-image_0.01.patch
? background-image_0.02.patch
? background-image_0.03.patch
? background-image_0.04.patch
? bg-renderer.patch
? dist-bin
? dist-src
? fop-background-image-0.03-bin.tar.gz
? fop-background-image-0.03-bin.zip
? fop-background-image-0.03-src.tar.gz
? fop-background-image-0.03-src.zip
? table-and-block.fo
? table-and-block.pdf
? test-config.xml
? test.fo
? test.pcl
? test.pdf
? test.ps
? test.txt
? docs/html-docs
? docs/xml-docs/book.xml
Index: src/org/apache/fop/layout/BodyRegionArea.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/layout/BodyRegionArea.java,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 BodyRegionArea.java
--- src/org/apache/fop/layout/BodyRegionArea.java 23 Apr 2002 22:26:10 -
1.3.2.1
+++ src/org/apache/fop/layout/BodyRegionArea.java 3 May 2002 08:08:52 -
@@ -25,11 +25,6 @@
}
public BodyAreaContainer makeBodyAreaContainer() {
- System.out.println( +++ Constructing new BodyAreaContainer:);
- System.out.println( - x : + xPosition);
- System.out.println( - y : + yPosition);
- System.out.println( - allocW: + width);
- System.out.println( - maxH : + height);
BodyAreaContainer area =
new BodyAreaContainer(null, xPosition, yPosition, width,
height, Position.ABSOLUTE, columnCount,
Index: src/org/apache/fop/render/AbstractRenderer.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/render/AbstractRenderer.java,v
retrieving revision 1.4.2.2
diff -u -r1.4.2.2 AbstractRenderer.java
--- src/org/apache/fop/render/AbstractRenderer.java 23 Apr 2002 22:26:58 -
1.4.2.2
+++ src/org/apache/fop/render/AbstractRenderer.java 3 May 2002 08:08:52 -
@@ -71,10 +71,6 @@
* @param h the height in millipoints
*/
protected void doBackground(Area area, int x, int y, int w, int h) {
- System.out.println(Doing background: + area);
- System.out.println( x: + x + y: + y);
- System.out.println( w: + w + h: + h);
-
if (h == 0 || w == 0)
return;
Index: src/org/apache/fop/render/pdf/PDFRenderer.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/render/pdf/PDFRenderer.java,v
retrieving revision 1.91.2.2
diff -u -r1.91.2.2 PDFRenderer.java
--- src/org/apache/fop/render/pdf/PDFRenderer.java 23 Apr 2002 22:33:39 -
1.91.2.2
+++ src/org/apache/fop/render/pdf/PDFRenderer.java 3 May 2002 08:08:52 -
@@ -323,18 +323,41 @@
FopImage image,
FontState fs) {
- PDFRectangle clip = new PDFRectangle(clipX / 1000,
-clipY / 1000,
-(clipX + clipW) / 1000,
-(clipY + clipW) / 1000);
+ float cx1 = ((float)x) / 1000f;
+ float cy1 = ((float)y - clipH) / 1000f;
+
+ float cx2 = ((float)x + clipW) / 1000f;
+ float cy2 = ((float)y) / 1000f;
+
+ int imgX = x - clipX;
+ int imgY = y - clipY;
+
+ int imgW;
+ int imgH;
+ try {
+ // XXX: do correct unit conversion here..
+ imgW = image.getWidth() * 1000;
+ imgH = image.getHeight() * 1000;
+ }
+ catch (FopImageException fie) {
+ log.error(Error obtaining image width and height, fie);
+ return;
+ }
if (image instanceof SVGImage) {
try {
closeText();
SVGDocument svg = ((SVGImage)image).getSVGDocument();
- currentStream.add(ET\nq\n);
- renderSVGDocument(svg, x, y, fs);
+ currentStream.add(ET\nq\n +
+ // clipping
+ cx1 + + cy1 + m\n +
+ cx2 + + cy1 + l\n +
+ cx2 + + cy2 + l\n +
+ cx1 + + cy2 + l\n +
+ W\n +
+ n\n);
+ renderSVGDocument(svg, imgX, imgY, fs);
Re: Master reference for fo:page-sequence
Thanks missed that one. Maybe should fix that in the examples provided. Claes |-+ | | Jeremias Maerki | | | jeremias.maerki@| | | outline.ch | | || | | 02.05.2002 17:24 | | | Please respond to| | | fop-dev | | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: (bcc: Claes Bergsten/NO/TJG) | | Subject: Re: Master reference for fo:page-sequence | --| Your stylesheet still uses pre-Recommendation XSL:FO. Please see the release notes for instructions to resolve this: http://xml.apache.org/fop/relnotes.html When trying to process my fo-file I get the following error: FATAL ERROR: 'master-reference' for 'fo:page-sequence'matches no 'simple-page-master' or 'page-sequence-master' Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: May 2, 2002 11:26 PM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion Karen Lease wrote: [ SNIP ] For the record, I disagree with Arved's reading of Line-Building. I read 4.7.2, point 5 as saying that a block area generated by an fo:block can contain a mixture of block areas and line areas. Agreed. In fact, it seems to me that the line-area is a pseudo-block designed to maintain the condition that the all of the children of an area must be of the same type, in the circumstance where there will clearly be block children of an fo:block, and to allow for simple block stacking in the BPDir. There is no need to wrap block areas in a line-area. On that last point let me clarify and point out that I never suggested that. By definition a line area is a block area that contains only inline areas as children. The quibble was over whether block areas returned/generated by by FO children, and line areas that wrap inline areas returned/generated by FO children, can/must/shouldn't co-exist in a single normal block area generated by the top-level block FO. I was suggesting the shouldn't viewpoint; Karen reads it differently. I am off to work so cannot comment more at the moment, on anything. :-) Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 508] - single words in one line won't get hyphenated
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=508. 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=508 single words in one line won't get hyphenated [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 515] - just a test
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=515. 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=515 just a test [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 516] - test
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=516. 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=516 test [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 626] - Negative number are shifted slightly towards left.
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=626. 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=626 Negative number are shifted slightly towards left. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 11:29 --- I can't find any shifting, whether the text is aligned left or right. The report is much to sparse to make anything out of it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 635] - Doesn't support id= attribute in fo:page-sequence
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=635. 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=635 Doesn't support id= attribute in fo:page-sequence [EMAIL PROTECTED] changed: What|Removed |Added Status|CLOSED |REOPENED Resolution|DUPLICATE | Version|0.17|0.20.3 --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 11:35 --- Errorneously marked as duplicate. Referring to an id of a page-sequence still results in a NullPointerException. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Hi devs, I have attached a picture of how I think this process should work (in principle not necessarily with actual areas or code). The spec should say something like: 4.7.2 A block level formatting object which contains inline level formatting objects that will create inline areas will create lines. Any block level areas that are return by child formatting objects will be placed as direct children of this block area. Any inline level areas which area return by child formatting objects will be placed into line areas. Consecutive inline areas will be placed into line areas. The sequence of child areas returned to this block area will be handled so that a sequence of inline areas will be placed into a sequence of line areas and block areas will be placed in the correct order. (part 5. point 1 then says that any child fo that returns a block area means that the block area is a direct child of the current block area) 4.7.3 An inline level formatting object creates and returns inline areas and returns any block areas. Each line area can contain only one inline area created by the inline level formatting object. This inline area is created by adding child inline areas that are allowed in the parent line area (it is not required to fit, eg. no wrap). 6.6.7 (and other inline fo's) Areas: The fo:inline returns these areas, any block areas, any page-level-out-of-line ... So does that make more sense? I think some of the confusion is that a block area can create multiple block areas but this only occurs at page/column breaks. Regards, Keiron. line.gif Description: GIF image line.svg Description: image/svg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 651] - PFMReader throws Exception: No scheme found in URI: charlist.xml
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=651. 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=651 PFMReader throws Exception: No scheme found in URI: charlist.xml [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 652] - Problem compiling with new TTFs because ttffont-file.xsl not found
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=652. 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=652 Problem compiling with new TTFs because ttffont-file.xsl not found [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 658] - the link to specifications is broken
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=658. 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=658 the link to specifications is broken [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 635] - Doesn't support id= attribute in fo:page-sequence
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=635. 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=635 Doesn't support id= attribute in fo:page-sequence --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 12:15 --- Correction: page-number-citation referring to page-sequence ids are still empty. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Hi devs, I have attached a picture of how I think this process should work (in principle not necessarily with actual areas or code). The spec should say something like: 4.7.2 A block level formatting object which contains inline level formatting objects that will create inline areas will create lines. Any block level areas that are return by child formatting objects will be placed as direct children of this block area. Any inline level areas which area return by child formatting objects will be placed into line areas. Consecutive inline areas will be placed into line areas. The sequence of child areas returned to this block area will be handled so that a sequence of inline areas will be placed into a sequence of line areas and block areas will be placed in the correct order. (part 5. point 1 then says that any child fo that returns a block area means that the block area is a direct child of the current block area) 4.7.3 An inline level formatting object creates and returns inline areas and returns any block areas. Each line area can contain only one inline area created by the inline level formatting object. This inline area is created by adding child inline areas that are allowed in the parent line area (it is not required to fit, eg. no wrap). 6.6.7 (and other inline fo's) Areas: The fo:inline returns these areas, any block areas, any page-level-out-of-line ... So does that make more sense? I think some of the confusion is that a block area can create multiple block areas but this only occurs at page/column breaks. Regards, Keiron. line.svg Description: image/svg line.gif Description: GIF image - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Keiron, Keiron Liddle wrote: I'm almost thinking of going a step further. Maybe we could add annotations to the spec to clarify these things with our understanding and then present this information. Yes indeed. And an index, including especially a concept index. It seems to me that the spec writers are not as involved as they should be. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 808] - Batch processing xml files
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=808. 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=808 Batch processing xml files [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 836] - hyphenation problem with very long words
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=836. 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=836 hyphenation problem with very long words [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 14:12 --- FOP 0.20.3 neither crashes on the last testcase nor fails to hyphenate. For the first case, it would be helpful if there were the certain number of characters more precisely specified. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Arved, My apologies. I was just taking the opportunity to think aloud about aspects of the interaction between inline-areas and block-areas. Trying to make sense of the various elements of the spec leaves your ears buzzing. Peter Arved Sandstrom wrote: For the record, I disagree with Arved's reading of Line-Building. I read 4.7.2, point 5 as saying that a block area generated by an fo:block can contain a mixture of block areas and line areas. Agreed. In fact, it seems to me that the line-area is a pseudo-block designed to maintain the condition that the all of the children of an area must be of the same type, in the circumstance where there will clearly be block children of an fo:block, and to allow for simple block stacking in the BPDir. There is no need to wrap block areas in a line-area. On that last point let me clarify and point out that I never suggested that. By definition a line area is a block area that contains only inline areas as children. The quibble was over whether block areas returned/generated by by FO children, and line areas that wrap inline areas returned/generated by FO children, can/must/shouldn't co-exist in a single normal block area generated by the top-level block FO. I was suggesting the shouldn't viewpoint; Karen reads it differently. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 907] - first list-item dropped at very bottom of page.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=907. 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=907 first list-item dropped at very bottom of page. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Priority||High Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 15:24 --- I can't reproduce the problem. A real testcase would have helped. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8778] New: - Infinite loop while rendering list-block
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=8778. 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=8778 Infinite loop while rendering list-block Summary: Infinite loop while rendering list-block Product: Fop Version: 0.20.3 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The attached testcase causes FOP to loop infinitely. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8778] - Infinite loop while rendering list-block
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=8778. 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=8778 Infinite loop while rendering list-block --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 15:30 --- Created an attachment (id=1774) Testcase FO file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Master reference for fo:page-sequence
If there are still any examples left in the current distribution would you please point out which? All examples should have been upgraded by now. Are you sure you don't have any old files in your FOP directory? On 03.05.2002 11:05:51 claes.bergsten wrote: Thanks missed that one. Maybe should fix that in the examples provided. Claes Your stylesheet still uses pre-Recommendation XSL:FO. Please see the release notes for instructions to resolve this: http://xml.apache.org/fop/relnotes.html When trying to process my fo-file I get the following error: FATAL ERROR: 'master-reference' for 'fo:page-sequence'matches no 'simple-page-master' or 'page-sequence-master' Cheers, Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 964] - FOP 0.17 throws exception with basic-link in xsl-region-before/after
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=964. 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=964 FOP 0.17 throws exception with basic-link in xsl-region-before/after [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Priority||High Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 15:45 --- Works with 0.20.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8778] - Infinite loop while rendering list-block
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=8778. 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=8778 Infinite loop while rendering list-block --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 15:54 --- I don't think this is actually being caused by the list-block. I was able to stop the infinite looping by removing the space-before=85mm attribute from the first block in the document. I'm attaching my doesn't break document. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8778] - Infinite loop while rendering list-block
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=8778. 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=8778 Infinite loop while rendering list-block --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 15:56 --- Created an attachment (id=1775) Same document as original poster, but doesn't break FOP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8778] - Infinite loop while rendering list-block
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=8778. 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=8778 Infinite loop while rendering list-block --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 15:57 --- Additionally, the infinite loop persisted on another document that had no list at all, but just the block with the aforementioned attribute. I'm also attaching that document. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8778] - Infinite loop while rendering list-block
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=8778. 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=8778 Infinite loop while rendering list-block --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 15:59 --- Created an attachment (id=1776) Simple FO that shows the attribute breaking FOP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1211] - Tables are not formatted properly.
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=1211. 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=1211 Tables are not formatted properly. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 15:59 --- Text positioning and background color work in 0.20.3 I'm somewhat worried about the etc. bit, though. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1231] - basic-link can't link to a page-sequence element
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=1231. 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=1231 basic-link can't link to a page-sequence element [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 16:02 --- *** This bug has been marked as a duplicate of 635 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 635] - Doesn't support id= attribute in fo:page-sequence
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=635. 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=635 Doesn't support id= attribute in fo:page-sequence [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 16:02 --- *** Bug 1231 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1242] - Error in Font-Documentation
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=1242. 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=1242 Error in Font-Documentation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED OS/Version||All Priority||High Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Master reference for fo:page-sequence
There are docs/xml2pdf.xsl docs/xml-docs/xml2pdf.xsl in fop-0.20.2-maintain branch with master-name attribute in page-sequence tag. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 5:48 PM To: [EMAIL PROTECTED] Subject: Re: Master reference for fo:page-sequence If there are still any examples left in the current distribution would you please point out which? All examples should have been upgraded by now. Are you sure you don't have any old files in your FOP directory? On 03.05.2002 11:05:51 claes.bergsten wrote: Thanks missed that one. Maybe should fix that in the examples provided. Claes Your stylesheet still uses pre-Recommendation XSL:FO. Please see the release notes for instructions to resolve this: http://xml.apache.org/fop/relnotes.html When trying to process my fo-file I get the following error: FATAL ERROR: 'master-reference' for 'fo:page-sequence'matches no 'simple-page-master' or 'page-sequence-master' Cheers, Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop build.xml
chrisg 02/05/03 10:51:24
Modified:.Tag: fop-0_20_2-maintain build.xml
Log:
replaced manifest-task with ant's builtin stuff
Revision ChangesPath
No revision
No revision
1.44.2.14 +17 -10xml-fop/build.xml
Index: build.xml
===
RCS file: /home/cvs/xml-fop/build.xml,v
retrieving revision 1.44.2.13
retrieving revision 1.44.2.14
diff -u -r1.44.2.13 -r1.44.2.14
--- build.xml 2 May 2002 22:27:24 - 1.44.2.13
+++ build.xml 3 May 2002 17:51:23 - 1.44.2.14
@@ -280,12 +280,10 @@
--
taskdef name=serHyph
classname=org.apache.fop.tools.anttasks.SerializeHyphPattern/
-taskdef name=xslt classname=org.apache.fop.tools.anttasks.Xslt/
-taskdef name=manifest classname=org.apache.fop.tools.anttasks.Manifest/
taskdef name=runTest classname=org.apache.fop.tools.anttasks.RunTest/
property name=main.class value=org.apache.fop.apps.Fop/
-property name=runtime.classpath value=lib/xerces-1.2.3.jar
lib/xalan-2.0.0.jar lib/xalanj1compat.jar lib/batik.jar lib/jimi-1.0.jar
lib/avalon-framework-cvs-20020315.jar/
+property name=runtime.classpath value=lib/xerces-1.2.3.jar
lib/xalan-2.0.0.jar lib/batik.jar lib/jimi-1.0.jar
lib/avalon-framework-cvs-20020315.jar/
filter filtersfile=${build.src}/codegen/filter/
@@ -583,14 +581,23 @@
!-- === --
target name=package depends=compile,hyphenation
echo message=Creating the jar file ${build.dir}/${name}.jar/
-manifest file=${build.dir}/Manifest.txt overwrite=yes
- mainclass=${main.class}
- classpath=${runtime.classpath}
- impltitle=${Name} implversion=${version}
- implvendor=Apache Software Foundation (http://xml.apache.org/fop/)/
-jar jarfile=${build.dir}/${name}.jar manifest=${build.dir}/Manifest.txt
+
+tstamp
+ format property=ts pattern=MMdd-HHmmss-z/
+/tstamp
+jar jarfile=${build.dir}/${name}.jar
basedir=${build.dest}
- includes=org/**,conf/**,hyph/**/
+ includes=org/**,conf/**,hyph/**
+manifest
+attribute name=Main-Class value=${main.class}/
+attribute name=Class-Path value=${runtime.classpath}/
+attribute name=Implementation-Title value=${Name}/
+attribute name=Implementation-Version value=${version}/
+attribute name=Implementation-Vendor value=Apache Software Foundation
(http://xml.apache.org/fop/)/
+attribute name=Build-Id value=${ts} (${user.name} [${os.name}
${os.version} ${os.arch}])/
+/manifest
+/jar
+
/target
target name=test depends=package
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8778] - Infinite loop while rendering list-block
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=8778. 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=8778 Infinite loop while rendering list-block --- Additional Comments From [EMAIL PROTECTED] 2002-05-03 17:51 --- Further tests show that 85mm is the threshhold size for for space-before attribute in this case. When it was changed to 84mm in the test document, it rendered fine. Likewise, it also worked fine in the super-simple test I posted earlier. What I suspect is happening is that FOP is attempting to place the leading block while honoring its space-before attrubute, but the test for break is leading FOP to try and reposition the block on the next page. The block naturally spills off the next page, leading FOP to try again...ad nauseum. This can be fixed with the addition of some logic to see if FOP is trying to reposition the entire element as it would be in this case and to either choose not to honor the space-before attribute after the second try (or maybe it just gives up after the second try, since the block is a natural conundrum that can't be handled effectively). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8785] New: - refrence-orientation does not implement yet
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=8785. 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=8785 refrence-orientation does not implement yet Summary: refrence-orientation does not implement yet Product: Fop Version: 0.20.2 Platform: Other OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I would like to change page orientation from portrait to landscape. fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master page-height=11in page-width=8.5in margin- left=1.0in margin-top=0.2in margin-bottom=1.0in margin-right=1.0in master-name=test-page-master fo:region-body margin-left=1.0in margin-top=0.2in margin- right=1.0in margin-bottom=1.0in/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-name=test-page-master fo:flow flow-name=xsl-region-body fo:block-container reference-orientation=90 fo:blockThis text should be rotated 90 degrees/fo:block /fo:block-container /fo:flow /fo:page-sequence /fo:root But when I run the code, it tell me refrence-orientation does not implement yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: What the spec says about table-row, table-cell etc.
OK, so I ran the following XPATH on the spec //div3[(@id = ./head/quote) and (.//table/tbody/tr[./td = 'Inherited: ']/td[(position() = 2) and (text() = 'yes')])]/head/quote And got the following universally inheritable attributes which I will add into my schema font-familyletter-spacing font-selection-strategytext-transform font-stretch word-spacing font-size-adjust color font-style intrusion-displace font-variant keep-together font-weightorphans countrywidows language leader-alignment script leader-pattern hyphenate leader-pattern-width hyphenation-character leader-length hyphenation-push-character-count rule-style hyphenation-remain-character-count rule-thickness start-indent auto-restore end-indent border-collapse display-align border-separation relative-align caption-side hyphenation-keep empty-cells hyphenation-ladder-count direction last-line-end-indent glyph-orientation-horizontal line-heightglyph-orientation-vertical line-height-shift-adjustment provisional-label-separation line-stacking-strategy provisional-distance-between-starts linefeed-treatment score-spaces white-space-treatment visibility text-align border-spacing text-align-lastfont text-indentpage-break-inside white-space-collapse white-space wrap-optionxml:lang Arved wrote: Comments below. -Original Message- From: Chuck Paussa [mailto:[EMAIL PROTECTED]] Sent: May 2, 2002 7:16 PM To: [EMAIL PROTECTED] Subject: What the spec says about table-row, table-cell etc. I've been working on a schema for FO documents so that I can off-load the validation chore. I created the schema from the W3C documents which state the following for table-cell: Contents: (%block;)+ In addition this formatting object may have a sequence of zero or more fo:markers as its initial children. The following properties apply to this formatting object: * [7.4 Common Accessibility Properties] * [7.6 Common Aural Properties] * [7.7 Common Border, Padding, and Background Properties] * [7.12 Common Relative Position Properties] * [7.26.1 border-after-precedence] * [7.26.2 border-before-precedence] * [7.26.4 border-end-precedence] * [7.26.6 border-start-precedence] * [7.14.1 block-progression-dimension] * [7.26.8 column-number] * [7.13.4 display-align] * [7.13.6 relative-align] * [7.26.10 empty-cells] * [7.26.11 ends-row] * [7.14.4 height] * [7.28.2 id] * [7.14.5 inline-progression-dimension] * [7.26.13 number-columns-spanned] * [7.26.14 number-rows-spanned] * [7.26.15 starts-row] * [7.14.12 width] FOP, in addition, both allows and implements the setting of block's inheritable attributes such as color and text-align which are then propagated down to the enclosed blocks. My questions are as follows: Is there a place in the spec that says Containers may hold inheritable attributes so they can be passed on to their child objects? Or is this just a side-effect of inheritabliity? Or is this illegal and will disappear in future FOP versions to be compatible with the spec? Yes, at Section 5.1.4. Every inheritable property exists on every formatting object, whether or not the property is actually applicable to (useable by) that FO. This isn't just a side-efefct of inheritability, this _is_ inheritability. :-) and Is there a list of these inheritable attributes ? Or do I just generate the list from those attributes that have an enumeration value of inherit? Don't do the latter...what you want to want to look at is the Inherited: field in the property descriptions. Chuck, one thing you may find helpful (maybe you've done it already) is to work off the XML version of the spec, and extract the property tables, at which point you can do SAX or XSLT to get at interesting bits. This was my approach. Regards, Arved
Re: [REDESIGN] Line layout manager discussion
Peter, Here's my point of view on where line-breaking (perhaps including hyphenation) happens. The end result of layout is a sequence of nested areas. However while layout is happening, line-breaking logic has to pretend that it's only working on a flat row of characters and other inline leaf nodes like external graphics. Keiron and I took different approaches to this, but the idea is about the same: lower level layout managers return information to the Line Layout Manager which allows it to make a decision about where to break the line. Once that decision is made, the appropriate areas can be created, depending on where the break occurs. Although it's possible to send information about IPDim down to lower level inline layout managers, I think it's simpler and clearer to concentrate knowlege (and strategy) about line-breaking in a single layout manager: the one actually creating Line Areas. There's a strong analogy with block-direction layout, where the Flow level (or perhaps the Page level?) LM is responsible for determining column/page breaks based on information provided by the lower level layout managers. The Flow and Line level LM are also responsible for justifying in either the inline or block progression dimensions and deciding how much stretch or shrink should be done. They either pass this information down to lower level layout managers (that was my plan) or do it directly on the flattened areas (Keiron's approach, at least at the line level). -Karen Peter B. West wrote: ... This leaves a question about where hyphenation is decided. In 4.7.2 point 5, there is a discussion about glyph substitution, insertion and deletion which seems to assume that the sequences of inline-areas being built into line-areas are in fact fo:characters. The corresponding sequences bubbling up from fo:inline and fo:basic-link are already wrapped as integral inline-areas and presented as a fait accompli to the parent line-builder. The fo:inline/fo:basic-link fo must obviously receive IPDim and BPDim information in order to present sane integral inline-areas to its parent, and to allow for the layout of nested fo:blocks. (This is pure hierarchical galley stuff.) In any case, there should be a correspondent in 4.7.3 to the discussion of substitution, insertion and deletion in 4.7.2, just to make it clear what the responsibilities of the inline-builder are. That's if I have this right, this time. What do you think? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties
Not really. As a fairly interested party, I must admit that mentions of throwing it out and starting over don't leave me totally indifferent, but I've got little enough time as it is for FOP these days, and I'm trying not to let myself be distracted. In any case, we all know that it's never right the first time around. Regards, Karen Peter B. West wrote: Hello devs. Does the near-silence on this one signify consent? Peter Keiron Liddle wrote: Hi Peter and others, What is the status of property handling? Are we going to go with Peter's suggestion and commit the java source to cvs and work on handling properties fully from there? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Arved, I'm definitely in favor of deciding how we think things are supposed to be laid out. Of course it would be nice if we were on the same wavelength with the majority of FO users and implementors... but I'm not too worried about that. Besides the stuff we're talking about currently, we need to agree on line-stacking issues (Keiron's already worked on vertical alignment, so he's probably up on that) and space specifier handling (but there I think the spec is fairly clear once one has read it 50 times or so :-). Arved Sandstrom wrote: Good...if we all agree with that then I think it is the main point gotten out of the way, because every other situation has to do with child FOs all being inline or block-level, for which the results are less dubious. . The main thing is, let's make sure that we have agreement (codified through use of these diagrammed examples) on all matters that affect placement. I understand that we want to have a warm fuzzy about our understanding of the spec, but that's not going to happen with everything. To be precise, if I can get a number of these examples created, what we can do is identify situations where we can say, this one is 100% solid (we know this is right, there is no uncertainty in the spec), this one is iffy (there may be small inconsistencies between our placement and what the spec authors intended), or this one is problematic (contradictions, for example). Once we have classified the examples, we can do damage control on the uncertain ones. Namely, let's do it this way, but let's be aware that things could be interpreted another way, and if so, how heavily committed are we in our code? On a related matter when it comes right down to brass tacks I am really only concerned about placement (accuracy of rendering). Both with Fop and with my other project I find it easier to use the conceptual areas, and I get the sense that others also feel this way, but let's face it, as long as our final result is consistent it doesn't really matter if our internal structures deviate. In general yes. So long as the extra levels of area wrappers we might or might not add in any given situation don't bring along border, padding, space-* etc. -Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Hi Keiron, I think this is a good start. I especially like the illustration which covers all aspects of the problem. I have some suggestions for the proposed text (see below). -Karen Keiron Liddle wrote: Hi devs, I have attached a picture of how I think this process should work (in principle not necessarily with actual areas or code). The spec should say something like: 4.7.2 A block level formatting object which contains inline level formatting objects that will create inline areas will create lines. A block level formatting object may contain both other block-level and inline level formatting objects. The block level FO creates and returns a block area or several block areas if it is split across more than one column or page. Any block level areas that are return[ed] by child formatting objects will be placed as direct children of this block area. Any inline level areas which are[a] return[ed] by child formatting objects will be placed into line areas. Consecutive inline areas will be placed into line areas. Minor corrections in [] above. The sequence of child areas returned to this block area will be handled so that a sequence of inline areas will be placed into a sequence of line areas and block areas will be placed in the correct order. Not sure this is quite clear enough; it also needs to express the idea that the ordering between the intermingled blocks and inlines is correct. (part 5. point 1 then says that any child fo that returns a block area means that the block area is a direct child of the current block area) 4.7.3 An inline level formatting object creates and returns inline areas and returns any block areas. Each line area can contain only one inline area created by the inline level formatting object. This inline area is created by adding child inline areas that are allowed in the parent line area (it is not required to fit, eg. no wrap). I'm not sure this is the right place to mention linebreak and overflow issues. The main idea is that an inline-level FO creates at least one inline area which holds inline areas generated and returned by any inline level child FOs. It might generate several inline areas, each one being placed in a new line area, if all its content doesn't fit in a single line. If the inline has any block-level FO descendants the block areas which they generate are directly returned by the inline FO. 6.6.7 (and other inline fo's) Areas: The fo:inline returns these areas, any block areas, any page-level-out-of-line ... So does that make more sense? I think some of the confusion is that a block area can create multiple block areas but this only occurs at page/column breaks. I assume you mean a block level FO can create multiple block areas. And similarly, an inline level FO can create multiple inline areas if it is broken into several lines. Regards, Keiron. Name: line.svg line.svgType: image/svg Encoding: base64 Name: line.gif line.gifType: GIF Image (image/gif) Encoding: base64 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: properties
Karen, I was your opinion that I was most concerned about on this one. I, for one, am quite happy to hold off to give you more time to make an argument. Part of my point was that it *was* in pretty good shape the first time around. Peter Karen Lease wrote: Not really. As a fairly interested party, I must admit that mentions of throwing it out and starting over don't leave me totally indifferent, but I've got little enough time as it is for FOP these days, and I'm trying not to let myself be distracted. In any case, we all know that it's never right the first time around. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [REDESIGN] Line layout manager discussion
Keiron et al., Just a quick reaction to this - I'm off to sit next to the footpath reading the newspapers and drinking tea. From what I see here you are changing the shape of the tree. The motivation seems to be to make it explicit that block areas contained within an inline area must bubble up to become direct children of the containing block area. I can't see that that is feasible, given the basic design principle of the spec that the area tree follows the fo tree. Specifically, by doing that, you lose what Karen called, iirc, the semantic markers of the enclosing inline-area, e.g., fo:inline or fo:basic-link. So how does that semantic information get to the once-but-no-longer enclosed fo:block? It is possible to arrange the transfer of such information to the block-area in the area tree, but then the inheritance becomes a purely algorithmic thing, and the structural link between the fo tree and the area tree is broken. It seems to me that one reason for the murkiness in this area of the spec is that the authors are at pains to preserve this structural relationship, while at the same time ensuring that the actual layout is determined in the way you propose. I think that it's possible to do this by clarifying the particular issues about line-building and inline-building in this context. The bottom line is that I think we have to clarify the text so that it comprehensibly expresses the situation laid out in Arved's original diagram of the handling of the fo:block within an fo:basic-link within the text of an fo:block. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Does FOP support PDF Form-filling fields?
I'm not sure what the exact name of the PDF feature is, but does FOP support, directly or indirectly, the PDF technique that allows the end-user of the PDF to click a page area and type in form information? I've seen this best done on an IRS Tax Form (1040EZ), but I don't know if this is a standard part of the PDF spec, or something that is hacked together with proprietary scripting that perhaps only Adobe tools support. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Does FOP support merging a PDF doc with a new PDF stream?
I have extensively-formatted, 1-4 page PDF Form documents that I would like to insert text annotations, equivalent to user-side form filling, but embedded directly in the original PDF. Does FOP's API, or any combination of supporting tools, have the ability to render/import a simple FO-PDF document consiting of text positioned in absolute coordinates on the page, and overlay/merge it with a background document that already exists in PDF. If the simple document existed solely in an annotation layer or other facilitiy PDF might have for markup, that would be fine. I suppose this step is more a PDF manipulation feature than FO rendering, but I thought this group was likely have addressed this question at some time previously. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Is SVG a preferred way to draw form lines?
I will be converting a few paper forms into FOP for rendering into PDF. I'm prioritizing reliability of rendering, with precise static layout, and compatibility/printing accuracy for the current versions of Adobe Acrobat on Windows. These documents won't need to flow or be layout-influenced by their content. I've worked with SVG, and would find it quite easy to draw the form boxes, captions and lines in absolute coordinates in SVG. On the other hand, there may be some merit to making traditional PDF text box elements with borders, perhaps even tables, assuming row/column/cell layout was practical. Is there a prevailing wisdom in the FOP community that one way is better than the other, or more predictably rendered, or more compatible with the Acrobat reader? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [REDESIGN] Line layout manager discussion
Comments below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: May 3, 2002 10:42 PM To: [EMAIL PROTECTED] Subject: Re: [REDESIGN] Line layout manager discussion [ SNIP ] From what I see here you are changing the shape of the tree. The motivation seems to be to make it explicit that block areas contained within an inline area must bubble up to become direct children of the containing block area. I can't see that that is feasible, given the basic design principle of the spec that the area tree follows the fo tree. Specifically, by doing that, you lose what Karen called, iirc, the semantic markers of the enclosing inline-area, e.g., fo:inline or fo:basic-link. So how does that semantic information get to the once-but-no-longer enclosed fo:block? It is possible to arrange the transfer of such information to the block-area in the area tree, but then the inheritance becomes a purely algorithmic thing, and the structural link between the fo tree and the area tree is broken. [ SNIP ] With respect to the second sentence of the above, I think we should be very clear at all times about exactly which area tree we are talking about - the conceptual area tree as described in the spec, or the real one constructed by Fop. Because in the conceptual tree block areas have a well-defined location and there is no bubbling up at all. Whereas in the real tree we can flatten completely and not have a tree at all, so we could have maximal bubbling. As far as semantic information, are we talking about during layout or once the area is passed off for rendering? Because it seems to me that if we have managers then they can take care of retaining the semantic information (e.g. all areas generated or returned in this manager belong within a link). Once the areas are passed off to the renderer practically all the information needed to properly render any area can be expressed as traits on that area - one main exception is that areas need to know their nearest ancestor reference area for positioning. I am not discounting an area tree per se - with my xslfo-proc project I find an area structure (partial in my SAX implementation) to be the most convenient way of recording current layout information. That is, manager X needs to store certain information and it may as well use Area objects to do it. But I lean strongly towards a viewpoint where the areas have no knowledge of original semantics. Regards, Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
