Bug report for Fop [2008/07/06]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende| | 8767|Ass|Min|2002-05-03|Image and solid colour background rectangle sizes | | 9379|New|Nor|2002-05-24|MIF Renderer generates incorrect MIF code | |10379|New|Enh|2002-07-01|Improvement to FOP Classloader| |12494|New|Nor|2002-09-10|fop produces pdf file which Acrobat Reader refuses| |12610|New|Enh|2002-09-13|[PATCH] onLoad Action for PDF documents or how to | |13586|New|Blk|2002-10-13|fop will not work on linux alpha because jre is br| |13734|New|Nor|2002-10-17|Hyphenation does not work correctly on long string| |14248|New|Enh|2002-11-05|51-page FO example, could be added to the samples | |14352|New|Enh|2002-11-07|It would be nice if FOP could be plugged into popu| |14356|New|Nor|2002-11-07|*NOT* embedding TrueTypeFont in PDF causes Acrobat| |14419|New|Enh|2002-11-10|Implement SourceResolver, Image Resolver | |14529|New|Nor|2002-11-13|SVG url references do not work| |14679|New|Enh|2002-11-19|Pluggable renderers | |14924|New|Nor|2002-11-28|Table disappears when it ends when the page ends | |15020|New|Enh|2002-12-03|Reuse of fo-tree | |16017|Opn|Nor|2003-01-13|Jpeg's and the PDF Serializer | |16130|New|Nor|2003-01-15|PS-Renderer emits lots of redundant moveto's | |16156|New|Nor|2003-01-16|0.20.5rc SVG example does not work| |16713|New|Nor|2003-02-03|Hyphenation error in tables | |17369|New|Nor|2003-02-25|Footnote duplication | |17380|New|Nor|2003-02-25|Batik Component will not recognize fe SVG elem| |17921|New|Nor|2003-03-12|Kerning is broken for standard fonts | |18292|New|Nor|2003-03-24|24 bit PNG not displayed correctly| |18801|New|Nor|2003-04-08|visibility property is not implemented | |19228|New|Blk|2003-04-22|[PATCH] Child LayoutContext is null in certain cir| |19341|Ver|Nor|2003-04-26|leader doesn't work since 0.20.5.rc2 | |19695|New|Enh|2003-05-06|[PATCH] Allow fox:destination as child of fox:outl| |19717|New|Enh|2003-05-07|Lets add support for JimiClassesPro.zip to build.x| |19769|Ass|Enh|2003-05-08|Indefinite page size is not implemented | |20280|Ass|Enh|2003-05-27|text-align and text-align-last only partially impl| |20407|New|Enh|2003-06-02|[PATCH] Configure image caching using the configur| |20827|New|Enh|2003-06-17|Derive other font styles and weights from normal T| |21265|Opn|Nor|2003-07-02|referencing a custom font (TTF or Adobe Type 1) fo| |21905|New|Nor|2003-07-26|large list-item-label bleeds into following block | |21982|New|Maj|2003-07-30|NullPointer Exception in LazyFont with embedded fo| |22450|New|Maj|2003-08-15|Unterminated iteration in JPEGReader class| |22627|Opn|Nor|2003-08-21|Update mirror/download page HEADER README (was [| |24148|New|Nor|2003-10-27|Kerning upsets text-align=end |
Re: svn commit: r674245 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/table/TableFObj.java
Hi,
Author: adelmelle
Date: Sat Jul 5 15:53:58 2008
New Revision: 674245
switch (side) {
-case CommonBorderPaddingBackground.BEFORE:
-borderBefore = new ConditionalBorder(borderSpec,
collapsingBorderModel);
-break;
-case CommonBorderPaddingBackground.AFTER:
-borderAfter = new ConditionalBorder(borderSpec,
collapsingBorderModel);
-break;
-case CommonBorderPaddingBackground.START:
-borderStart = borderSpec;
-break;
-case CommonBorderPaddingBackground.END:
-borderEnd = borderSpec;
-break;
-default: assert false;
+case CommonBorderPaddingBackground.BEFORE:
+borderBefore = new ConditionalBorder(borderSpec,
collapsingBorderModel);
+break;
+case CommonBorderPaddingBackground.AFTER:
+borderAfter = new ConditionalBorder(borderSpec,
collapsingBorderModel);
+break;
+case CommonBorderPaddingBackground.START:
+borderStart = borderSpec;
+break;
+case CommonBorderPaddingBackground.END:
+borderEnd = borderSpec;
+break;
+default: assert false;
FWIW, the original indentation scheme was following Java’s code
conventions:
http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#468
No big deal, however.
Vincent
DO NOT REPLY [Bug 45351] New: Unnecessary hyphenation, swallowed characters
https://issues.apache.org/bugzilla/show_bug.cgi?id=45351 Summary: Unnecessary hyphenation, swallowed characters Product: Fop Version: all Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] I have a case where a word is hyphenated even though sufficient space appears to be available, and the text following the hyphen is dropped. In another case, white space and following non-white characters immediately preceding a fo:inline are dropped. The attachment contains two fo:blocks, each illustrating one of these two issues. I am not sure this is the same bug in both cases. However, if I remove the hyphenate=true attribute, both problems go away. The example uses language=fr (and the latest offo patterns). However, at least the first issue does not appear to be language specific; if I change the language attribute to en, in this particular example, the first problem persists. Minor modifications to the example change its behavior. For example, if the first block is reduced to fo:blockgrammaire ?/fo:block, the word is no longer hyphenated, but the question mark and the preceding space are dropped. If I remove the first word of the second fo:block, the second problem goes away. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45351] Unnecessary hyphenation, swallowed characters
https://issues.apache.org/bugzilla/show_bug.cgi?id=45351 --- Comment #1 from [EMAIL PROTECTED] 2008-07-07 06:15:33 PST --- Created an attachment (id=0) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=0) fo containing two fo:blocks, each illustrating one of the two issues described. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45351] Unnecessary hyphenation, swallowed characters
https://issues.apache.org/bugzilla/show_bug.cgi?id=45351 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #0|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45351] Unnecessary hyphenation, swallowed characters
https://issues.apache.org/bugzilla/show_bug.cgi?id=45351 --- Comment #2 from [EMAIL PROTECTED] 2008-07-07 06:21:15 PST --- Created an attachment (id=1) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=1) first attachment rendered by today's fop-trunk -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: svn commit: r670341 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FONode.java FOText.java FOTreeBuilder.java FObjMixed.java
I know I'm late on this one but I've only just stumbled over it while
playing with the AFP renderer in the GOCA branch. This change is very
dangerous as it essentially breaks every FOP extension that uses
character content, especially those not developed inside the FOP project.
I'm lucky it doesn't (shouldn't) break Barcode4J but I would strongly
suggest to revert this interface change especially since the method
signature doesn't change while the semantics do.
On 22.06.2008 13:18:03 adelmelle wrote:
Author: adelmelle
Date: Sun Jun 22 04:18:03 2008
New Revision: 670341
URL: http://svn.apache.org/viewvc?rev=670341view=rev
Log:
Changed FONode.addCharacters() signature to match the characters() event (use
'length' as a parameter instead of 'end')
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FONode.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOTreeBuilder.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FObjMixed.java
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FONode.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FONode.java?rev=670341r1=670340r2=670341view=diff
==
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FONode.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FONode.java Sun Jun 22
04:18:03 2008
@@ -274,12 +274,12 @@
*
* @param data array of characters containing text to be added
* @param start starting array element to add
- * @param end ending array element to add
+ * @param length number of elements to add
* @param pList currently applicable PropertyList
* @param locator location in the XSL-FO source file.
* @throws FOPException if there's a problem during processing
*/
-protected void addCharacters(char[] data, int start, int end,
+protected void addCharacters(char[] data, int start, int length,
PropertyList pList,
Locator locator) throws FOPException {
// ignore
snip/
Jeremias Maerki
Re: svn commit: r674484 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
Hi Jeremias, You'll see in a moments time when the recent svn commit on XMLRenderer arrives... :). Just thought I would put these small changes planned in the Temp_AreaTreeNewDesign into trunk as they do no harm and may actually be useful for someone else who may wish to write their own custom XML based Renderer. Adrian. Jeremias Maerki wrote: What for? Just curious. On 07.07.2008 15:28:26 acumiskey wrote: Author: acumiskey Date: Mon Jul 7 06:28:26 2008 New Revision: 674484 URL: http://svn.apache.org/viewvc?rev=674484view=rev Log: Added new AbstractXMLRenderer base class. Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java (with props) Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java?rev=674484view=auto == --- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java (added) +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java Mon Jul 7 06:28:26 2008 snip/ Jeremias Maerki
Re: Absolute-positioned block-containers using left and bottom
On Fri, Jul 4, 2008 at 6:09 PM, Andreas Delmelle [EMAIL PROTECTED] wrote: Now, I'm wondering... In theory, it should not be too difficult to get at this info, since ultimately it is also needed when computing 'top' or 'left' if they are specified as a percentage. In that case, the value is obtained through AbstractBaseLayoutManager.getBaseLength() - getReferenceAreaIPD() or getReferenceAreaBPD(). Yeah, thank you, that was it! Right under my nose, yet I could not see it ... :-) Now everything should be ok in revision 674489. Regards Luca
Re: svn commit: r670341 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FONode.java FOText.java FOTreeBuilder.java FObjMixed.java
On Jul 7, 2008, at 15:22, Jeremias Maerki wrote: I know I'm late on this one but I've only just stumbled over it while playing with the AFP renderer in the GOCA branch. This change is very dangerous as it essentially breaks every FOP extension that uses character content, especially those not developed inside the FOP project. I'm lucky it doesn't (shouldn't) break Barcode4J but I would strongly suggest to revert this interface change especially since the method signature doesn't change while the semantics do. I'd rather keep it the other way around, like it is now. It's much less confusing if the same parameters are used as in the SAX characters() event. If this breaks external code, then my apologies (it even broke some internal classes too, but those issues didn't show when running the test-suite; Max discovered them). Still -1 for reverting. Cheers Andreas
Re: svn commit: r674245 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/table/TableFObj.java
On Jul 7, 2008, at 12:44, Vincent Hennebert wrote:
Hi,
Author: adelmelle
Date: Sat Jul 5 15:53:58 2008
New Revision: 674245
switch (side) {
-case CommonBorderPaddingBackground.BEFORE:
-borderBefore = new ConditionalBorder(borderSpec,
collapsingBorderModel);
snip /
+case CommonBorderPaddingBackground.BEFORE:
+borderBefore = new ConditionalBorder(borderSpec,
collapsingBorderModel);
+break;
FWIW, the original indentation scheme was following Java’s code
conventions:
http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#468
Sorry. I paid no mind, but the change did seem a bit out-of-place...
I'll rectify.
Cheers
Andreas
Re: svn commit: r674484 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
On Jul 7, 2008, at 15:39, Jeremias Maerki wrote: On 07.07.2008 15:28:26 acumiskey wrote: Author: acumiskey Date: Mon Jul 7 06:28:26 2008 New Revision: 674484 URL: http://svn.apache.org/viewvc?rev=674484view=rev Log: Added new AbstractXMLRenderer base class. Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/ AbstractXMLRenderer.java (with props) What for? Just curious. Me too... Just abstracting to abstract seems to make little sense. :-/ Cheers Andreas
Re: Absolute-positioned block-containers using left and bottom
On Jul 7, 2008, at 16:06, Luca Furini wrote: On Fri, Jul 4, 2008 at 6:09 PM, Andreas Delmelle [EMAIL PROTECTED] wrote: Now, I'm wondering... In theory, it should not be too difficult to get at this info, since ultimately it is also needed when computing 'top' or 'left' if they are specified as a percentage. In that case, the value is obtained through AbstractBaseLayoutManager.getBaseLength() - getReferenceAreaIPD() or getReferenceAreaBPD(). Yeah, thank you, that was it! Right under my nose, yet I could not see it ... :-) Yea, I know that one. Glad to be on the other side for once. ;-) Now everything should be ok in revision 674489. Cool! Really good to see you active again. Cheers Andreas
Re: svn commit: r670341 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FONode.java FOText.java FOTreeBuilder.java FObjMixed.java
On Jul 7, 2008, at 18:09, Andreas Delmelle wrote: On Jul 7, 2008, at 15:22, Jeremias Maerki wrote: I know I'm late on this one but I've only just stumbled over it while playing with the AFP renderer in the GOCA branch. This change is very dangerous as it essentially breaks every FOP extension that uses character content, especially those not developed inside the FOP project. I'm lucky it doesn't (shouldn't) break Barcode4J but I would strongly suggest to revert this interface change especially since the method signature doesn't change while the semantics do. I'd rather keep it the other way around, like it is now. It's much less confusing if the same parameters are used as in the SAX characters() event. If this breaks external code, then my apologies (it even broke some internal classes too, but those issues didn't show when running the test-suite; Max discovered them). Still -1 for reverting. Note: I do appreciate the feedback, and I see where this can become problematic, but OTOH, if there is a class that relies on the ending index being passed, the solution is rather straightforward. The change was ultimately also motivated by the simple question: Why did we need to compute the end-index off start and length for every characters() event? The answer: Because FONode.addCharacters() expected it. That's the only reason, so it made more sense to simply make it a length (no additional operation needed) and only compute the end index if we really need it... That said: Would it relieve your concerns a bit if this change were better documented? (Which I'd be glad to take care of, since I neglected to do so in spite of the change being so high up in the hierarchy /and/ exposed to potential subclasses... :/) Andreas
