DO NOT REPLY [Bug 20506] New: - PS Renderer: Grayscale JPEG images fail with rangecheck
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=20506. 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=20506 PS Renderer: Grayscale JPEG images fail with rangecheck Summary: PS Renderer: Grayscale JPEG images fail with rangecheck Product: Fop Version: 0.20.5 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: images AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When a Grayscale (8bit) JPEG image is rendered using the PS Renderer (maintenance branch) the PostScript interpreter will fail with a rangecheck. The same JPEG works fine in the PDF Renderer. I've already checked if the ASCII-85 filter is the problem but it is not. At the moment I don't have an idea what's wrong. Many other JPEG (even with ICC profiles) work fine. The image dictionary seems to be in order but I could be wrong. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20506] - PS Renderer: Grayscale JPEG images fail with rangecheck
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=20506. 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=20506 PS Renderer: Grayscale JPEG images fail with rangecheck --- Additional Comments From [EMAIL PROTECTED] 2003-06-05 13:40 --- Created an attachment (id=6645) A sample 8-bit grayscale JPEG image - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20506] - PS Renderer: Grayscale JPEG images fail with rangecheck
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=20506. 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=20506 PS Renderer: Grayscale JPEG images fail with rangecheck [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Layout transactions
--- Peter B. West [EMAIL PROTECTED] wrote: Such a transaction has a minimum and a maximum impact. Assuming that we must place the first line of the footnote on the same page, The line-area generator would pass this information up for the decision to be made about committing the transaction to the page, requesting a transaction with a smaller impact, or declaring the page full, and passing the request for a new canvas area up the tree to the page factory. In the latter case, the line-area generator would subsequently iniatiate a transaction involving only the remainder of the footnote. Peter, Both your writing here as well as the XSL spec indicate that footnotes can extend on to subsequent pages (as I guess they must be allowed to, should someone insist on a 47-paragraph footnote). But, curiously missing from the spec (AFAICT) is any indication that it would be preferable to avoid having that happen--and I wonder if, consequently, the algorithms you are thinking of are not capturing that concern. Thinking of the traditional way footnotes appear in books, ordinarily as the footnote grows the author will choose to shrink the main body of text on that page to accomodate the larger footnote. I believe that this is almost invariably deemed preferable to avoid the eyesore (?) of having the footnote split onto the second page. (Am I correct here?) Perhaps adding to the fun here, this shrinking of the main body of text can also result in subsequent footnote citations on the page ending up on the next page, meaning that the size calculations for its footnote would also need to move. Will the algorithms that you are thinking of take care of that? (I hope so--it will be a *long* time before I will understand enough about this in order to help out!) Thanks, Glen __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20506] - PS Renderer: Grayscale JPEG images fail with rangecheck
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=20506. 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=20506 PS Renderer: Grayscale JPEG images fail with rangecheck [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-05 21:22 --- The PSRenderer missed /DeviceGray colorspace. Simple fix: in method renderBitmap() add this line between the first if-else pair: else if (img.getColorSpace().getColorSpace() == ColorSpace.DEVICE_GRAY) write(/DeviceGray setcolorspace); I will submit patch when I have access to CVS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20528] New: - 19753 Segmentation fault
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=20528. 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=20528 19753 Segmentation fault Summary: 19753 Segmentation fault Product: Fop Version: 0.20.4 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Running FOP 0.20.4 fails with a segfault. All files are Web accessible in a directory at http://www.nmt.edu/tcc/help/pubs/python22/xml/;. without-kluge.fo: Fails with a segfault. without-kluge.out: All output from FOP command during execution. with-kluge.fo: Works fine. The source files (DocBook-XML 4.2 with Modular Stylesheets 1.60.1) are without-kluge.xml and with-kluge.xml, and they differ by only the omission of four lines just after a comment containing the string `POISON'. This problem isn't stopping me dead, but I'm about to convert a whole bunch of DocBook-SGML 4.1 files to the FOP route and would like to be sure of my tool base. Please do not hesitate to contact me if I can provide further help. I am a longtime developer myself. I regret that I haven't been able to find a smaller example that fails. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20528] - 19753 Segmentation fault
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=20528. 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=20528 19753 Segmentation fault --- Additional Comments From [EMAIL PROTECTED] 2003-06-05 22:37 --- Created an attachment (id=6658) FO source that makes FOP 0.20.4 crash. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20528] - 19753 Segmentation fault
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=20528. 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=20528 19753 Segmentation fault --- Additional Comments From [EMAIL PROTECTED] 2003-06-05 22:38 --- Created an attachment (id=6659) Slight variant of without-kluge.fo that works - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20528] - 19753 Segmentation fault
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=20528. 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=20528 19753 Segmentation fault --- Additional Comments From [EMAIL PROTECTED] 2003-06-05 22:38 --- Created an attachment (id=6660) Figure required by without-kluge.fo and with-kluge.fo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20529] New: - Support for RTF
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=20529. 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=20529 Support for RTF Summary: Support for RTF Product: Fop Version: 0.20.3 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello FOP Gurus, Need your help any reply would be greatly appreciated. We have portal running on .NET environment with SQL server as backend and C Sharp for generating webpages using MSXML and XSL. This portal uses Apache FOP version (0.20.3rc) to generate XML content into PDF using XSL FO when user requests. Now we would like see this output in MS Word or RTF (Editable format) format, so that user can further edit document generated by XSL FO and FOP. My question is does FOP support word or RTF format output? If yes some examples on how to achieve this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20506] - PS Renderer: Grayscale JPEG images fail with rangecheck
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=20506. 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=20506 PS Renderer: Grayscale JPEG images fail with rangecheck --- Additional Comments From [EMAIL PROTECTED] 2003-06-05 23:23 --- Created an attachment (id=6661) Gray Image - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20528] - 19753 Segmentation fault
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=20528. 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=20528 19753 Segmentation fault [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-06 06:49 --- Segmentation faults are bugs in the Java VM. This has nothing to do with FOP. Buggy Java programs should never result in a segmentation fault. Please try another JDK or upgrade your VM. Both your FO files work fine under: - JDK 1.4.1_02 (Windows) - JDK 1.4.0_03 (Windows) - JDK 1.3.1_08 (Windows) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/layout LineArea.java
jeremias2003/06/06 00:28:00
Modified:src/org/apache/fop/layout Tag: fop-0_20_2-maintain
LineArea.java
Log:
Fix NoSuchMethodError when FOP is compiled under JDK1.4 but run under JDK1.3.
Reason: StringBuffer.append(StringBuffer) has been added with JDK1.4.
Revision ChangesPath
No revision
No revision
1.53.2.19 +4 -4 xml-fop/src/org/apache/fop/layout/Attic/LineArea.java
Index: LineArea.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/layout/Attic/LineArea.java,v
retrieving revision 1.53.2.18
retrieving revision 1.53.2.19
diff -u -r1.53.2.18 -r1.53.2.19
--- LineArea.java 20 May 2003 20:50:52 - 1.53.2.18
+++ LineArea.java 6 Jun 2003 07:27:59 - 1.53.2.19
@@ -1214,7 +1214,7 @@
return wordStart;
} else if (hyph == null preString != null) {
// no hyphenation points, but a inword non-letter character
-remainingString.append(preString);
+remainingString.append(preString.toString());
this.addWord(remainingString, startw, ls, textState);
return wordStart + remainingString.length();
} else if (hyph != null preString == null) {
@@ -1230,12 +1230,12 @@
// hyphenation points and a inword non letter character
int index = getFinalHyphenationPoint(hyph, remainingWidth);
if (index != -1) {
-
remainingString.append(preString.append(hyph.getPreHyphenText(index)));
+
remainingString.append(preString.append(hyph.getPreHyphenText(index)).toString());
remainingString.append(this.hyphProps.hyphenationChar);
this.addWord(remainingString, startw, ls, textState);
return wordStart + remainingString.length() - 1;
} else {
-remainingString.append(preString);
+remainingString.append(preString.toString());
this.addWord(remainingString, startw, ls, textState);
return wordStart + remainingString.length();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/render/ps PSRenderer.java
jeremias2003/06/06 01:21:50
Modified:src/org/apache/fop/render/ps Tag: fop-0_20_2-maintain
PSRenderer.java
Log:
Fix for grayscale images (#20506)
Submitted by: Zhong(George) Yi [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.15.2.19 +8 -2 xml-fop/src/org/apache/fop/render/ps/Attic/PSRenderer.java
Index: PSRenderer.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/ps/Attic/PSRenderer.java,v
retrieving revision 1.15.2.18
retrieving revision 1.15.2.19
diff -u -r1.15.2.18 -r1.15.2.19
--- PSRenderer.java 2 Jun 2003 19:55:08 - 1.15.2.18
+++ PSRenderer.java 6 Jun 2003 08:21:50 - 1.15.2.19
@@ -617,6 +617,8 @@
write(gsave);
if (img.getColorSpace().getColorSpace() == ColorSpace.DEVICE_CMYK)
write(/DeviceCMYK setcolorspace);
+else if (img.getColorSpace().getColorSpace() == ColorSpace.DEVICE_GRAY)
+write(/DeviceGray setcolorspace);
else
write(/DeviceRGB setcolorspace);
@@ -685,7 +687,11 @@
}
}
out.write(imgmap);
-((Finalizable)out).finalizeStream();
+if (out instanceof Finalizable) {
+((Finalizable)out).finalizeStream();
+} else {
+out.flush();
+}
} catch (IOException e) {
if (!ioTrouble)
e.printStackTrace();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20506] - PS Renderer: Grayscale JPEG images fail with rangecheck
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=20506. 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=20506 PS Renderer: Grayscale JPEG images fail with rangecheck --- Additional Comments From [EMAIL PROTECTED] 2003-06-06 08:26 --- Applied to CVS. Thanks George. So obvious! I didn't look enough. BTW, don't mark the bug as resolved too soon. It could get lost that way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop CHANGES
jeremias2003/06/06 01:24:52 Modified:.Tag: fop-0_20_2-maintain CHANGES Log: Fix for grayscale images (#20506) Revision ChangesPath No revision No revision 1.10.2.62 +2 -0 xml-fop/CHANGES Index: CHANGES === RCS file: /home/cvs/xml-fop/CHANGES,v retrieving revision 1.10.2.61 retrieving revision 1.10.2.62 diff -u -r1.10.2.61 -r1.10.2.62 --- CHANGES 2 Jun 2003 19:58:08 - 1.10.2.61 +++ CHANGES 6 Jun 2003 08:24:52 - 1.10.2.62 @@ -1,5 +1,7 @@ == Done since 0.20.4 release +- Fix for bug #20506 (grayscale images in PS renderer) (JM) + Submitted by: Zhong(George) Yi [EMAIL PROTECTED] - Fix for bad font encodings in the PS renderer (Fonts get reencoded as WinAnsiEncoding, Symbol and ZapfDingbats show correctly now) (JM) Financed by: CTB/McGraw-Hill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Layout transactions
Peter B. West [EMAIL PROTECTED] wrote: it may be better if there is only room for a single line of a multi- line footnote, to throw the text line plaus the whole of the footnote onto the next page. I think this is the main point of what you were writing--avoiding having just one line of a footnote with the remainder on the next page--sounds good. Thanks for clearing that up. Thanks, Glen __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
