DO NOT REPLY [Bug 48237] afp renderer does not respect image color settings for svg
https://issues.apache.org/bugzilla/show_bug.cgi?id=48237 --- Comment #5 from Chris Bowditch bowditch_ch...@hotmail.com 2009-11-26 00:24:13 UTC --- Jeremias, our local B+W AFP Printer handles this and converts the colour SVG to B+W on the fly. However, one of our customers with B+W Printers said the AFP failed to print due to the colour in the GOCA objects. We believe this is a bug and should be fixed. Thanks, Chris -- 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: r828678 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp: goca/ modca/ modca/triplets/
acumis...@apache.org wrote:
Author: acumiskey
Date: Thu Oct 22 13:20:53 2009
New Revision: 828678
Hi Adrian,
there is a bug in this commit. AttributeQualifier was moved from end of
TLE to be between Attribute Name and Attribute Value.
I will commit a fix shortly.
Chris
URL: http://svn.apache.org/viewvc?rev=828678view=rev
Log:
Fixes https://issues.apache.org/bugzilla/show_bug.cgi?id=47941
Created Triplet interface.
Created new AttributeValueTriplet and AttributeQualifierTriplet.
Promoted truncate() from GraphicsCharacterString to AbstractAFPObject so it can
be reused for AttributeValueTriplet.
Added:
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/triplets/AttributeQualifierTriplet.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/triplets/AttributeValueTriplet.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/triplets/Triplet.java
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/goca/GraphicsCharacterString.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractAFPObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractTripletStructuredObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/TagLogicalElement.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/triplets/AbstractTriplet.java
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/goca/GraphicsCharacterString.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/goca/GraphicsCharacterString.java?rev=828678r1=828677r2=828678view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/goca/GraphicsCharacterString.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/goca/GraphicsCharacterString.java
Thu Oct 22 13:20:53 2009
@@ -45,7 +45,7 @@
*/
public GraphicsCharacterString(String str, int x, int y) {
super(x, y);
-this.str = truncate(str);
+this.str = truncate(str, MAX_STR_LEN);
}
/**
@@ -57,7 +57,7 @@
*/
public GraphicsCharacterString(String str) {
super(null);
-this.str = truncate(str);
+this.str = truncate(str, MAX_STR_LEN);
}
/** {...@inheritdoc} */
@@ -83,20 +83,6 @@
}
/**
- * Truncates the string as necessary
- *
- * @param str a character string
- * @return a possibly truncated string
- */
-private String truncate(String str) {
-if (str.length() MAX_STR_LEN) {
-str = str.substring(0, MAX_STR_LEN);
-log.warn(truncated character string, longer than + MAX_STR_LEN +
chars);
-}
-return str;
-}
-
-/**
* Returns the text string as an encoded byte array
*
* @return the text string as an encoded byte array
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractAFPObject.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractAFPObject.java?rev=828678r1=828677r2=828678view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractAFPObject.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractAFPObject.java
Thu Oct 22 13:20:53 2009
@@ -43,7 +43,7 @@
/** the structured field class id */
protected static final byte SF_CLASS = (byte)0xD3;
-private static final byte[] SF_HEADER = new byte[] {
+protected static final byte[] SF_HEADER = new byte[] {
0x5A, // Structured field identifier
0x00, // Length byte 1
0x10, // Length byte 2
@@ -177,6 +177,21 @@
}
}
+/**
+ * Truncates the string as necessary
+ *
+ * @param str a character string
+ * @param maxLength the maximum length allowed for the string
+ * @return a possibly truncated string
+ */
+protected String truncate(String str, int maxLength) {
+if (str.length() maxLength) {
+str = str.substring(0, maxLength);
+log.warn(truncated character string ' + str + ', longer than +
maxLength + chars);
+}
+return str;
+}
+
/** structured field type codes */
public interface Type {
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractTripletStructuredObject.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractTripletStructuredObject.java?rev=828678r1=828677r2=828678view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractTripletStructuredObject.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractTripletStructuredObject.java
Thu Oct 22 13:20:53 2009
@@
DO NOT REPLY [Bug 48290] New: AFP Renderer: AttributeQualifier Triplet occurs before TLE Value
https://issues.apache.org/bugzilla/show_bug.cgi?id=48290 Summary: AFP Renderer: AttributeQualifier Triplet occurs before TLE Value Product: Fop Version: 1.0dev Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: bowditch_ch...@hotmail.com Order of AttributeQualifier and Value Triplet were switched for TLE by following commit: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-commits/200910.mbox/%3c20091022132054.a5c7b2388...@eris.apache.org%3e This means TLE structure no longer conforms to AFP specification: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3M5M00/5.82.2?SHELF=APSBK320DT=20010307105730 The fix is fairly straight forward and follows shortly. -- 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 48255] PDFRectangle
https://issues.apache.org/bugzilla/show_bug.cgi?id=48255 --- Comment #2 from Gerald Buchgraber gerald.buchgra...@student.tugraz.at 2009-11-26 03:01:47 UTC --- Created an attachment (id=24622) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24622) [PATCH] Revisited implementation of PDFRectangle and PDFLink -- 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 48255] [PATCH] Revisited implementation of PDFRectangle and PDFLink (derived from new PDFAnnotation dictionary)
https://issues.apache.org/bugzilla/show_bug.cgi?id=48255 Gerald Buchgraber gerald.buchgra...@student.tugraz.at changed: What|Removed |Added Summary|PDFRectangle|[PATCH] Revisited ||implementation of ||PDFRectangle and PDFLink ||(derived from new ||PDFAnnotation dictionary) -- 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 48290] AFP Renderer: AttributeQualifier Triplet occurs before TLE Value
https://issues.apache.org/bugzilla/show_bug.cgi?id=48290 --- Comment #1 from Chris Bowditch bowditch_ch...@hotmail.com 2009-11-26 03:23:48 UTC --- bug fix committed in revision 884526 -- 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 48290] AFP Renderer: AttributeQualifier Triplet occurs before TLE Value
https://issues.apache.org/bugzilla/show_bug.cgi?id=48290 Chris Bowditch bowditch_ch...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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: r828678 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp: goca/ modca/ modca/triplets/
Adrian Cumiskey wrote:
Hi Chris,
Hi Adrian,
thanks for your reply.
I agree it might be better if the AttributeQualifier triplet is at the
end of the list as it is optional, and FullyQualifiedName and
AttributeValue are both manditory. I would be very surprised if this
should cause a problem as I don't believe there are any ordering rules
for triplets. I'd be interested to hear how bug manifests itself?
MO:DCA Specification dictates the order of the triplets, here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3M5M00/5.82.2?SHELF=APSBK320DT=20010307105730
Attribute Qualifier is the last part of TLE structured field.
One of our customers has a process that extracts the TLE values which
now fails because the 10 bytes of the AttributeQualifier occur in front
of the value.
Thanks,
Chris
Thanks,
Adrian.
2009/11/26 Chris Bowditch bowditch_ch...@hotmail.com
mailto:bowditch_ch...@hotmail.com
acumis...@apache.org mailto:acumis...@apache.org wrote:
Author: acumiskey
Date: Thu Oct 22 13:20:53 2009
New Revision: 828678
Hi Adrian,
there is a bug in this commit. AttributeQualifier was moved from end
of TLE to be between Attribute Name and Attribute Value.
I will commit a fix shortly.
Chris
URL: http://svn.apache.org/viewvc?rev=828678view=rev
http://svn.apache.org/viewvc?rev=828678view=rev
Log:
Fixes https://issues.apache.org/bugzilla/show_bug.cgi?id=47941
Created Triplet interface.
Created new AttributeValueTriplet and AttributeQualifierTriplet.
Promoted truncate() from GraphicsCharacterString to
AbstractAFPObject so it can be reused for AttributeValueTriplet.
Added:
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/triplets/AttributeQualifierTriplet.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/triplets/AttributeValueTriplet.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/triplets/Triplet.java
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/goca/GraphicsCharacterString.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractAFPObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractTripletStructuredObject.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/TagLogicalElement.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/triplets/AbstractTriplet.java
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/goca/GraphicsCharacterString.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/goca/GraphicsCharacterString.java?rev=828678r1=828677r2=828678view=diff
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/goca/GraphicsCharacterString.java?rev=828678r1=828677r2=828678view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/goca/GraphicsCharacterString.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/goca/GraphicsCharacterString.java
Thu Oct 22 13:20:53 2009
@@ -45,7 +45,7 @@
*/
public GraphicsCharacterString(String str, int x, int y) {
super(x, y);
-this.str = truncate(str);
+this.str = truncate(str, MAX_STR_LEN);
}
/**
@@ -57,7 +57,7 @@
*/
public GraphicsCharacterString(String str) {
super(null);
-this.str = truncate(str);
+this.str = truncate(str, MAX_STR_LEN);
}
/** {...@inheritdoc} */
@@ -83,20 +83,6 @@
}
/**
- * Truncates the string as necessary
- *
- * @param str a character string
- * @return a possibly truncated string
- */
-private String truncate(String str) {
-if (str.length() MAX_STR_LEN) {
-str = str.substring(0, MAX_STR_LEN);
-log.warn(truncated character string, longer than
+ MAX_STR_LEN + chars);
-}
-return str;
-}
-
-/**
* Returns the text string as an encoded byte array
*
* @return the text string as an encoded byte array
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractAFPObject.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/modca/AbstractAFPObject.java?rev=828678r1=828677r2=828678view=diff
Re: svn commit: r828678 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp: goca/ modca/ modca/triplets/
Hi Chris, 2009/11/26 Chris Bowditch bowditch_ch...@hotmail.com Adrian Cumiskey wrote: I agree it might be better if the AttributeQualifier triplet is at the end of the list as it is optional, and FullyQualifiedName and AttributeValue are both manditory. I would be very surprised if this should cause a problem as I don't believe there are any ordering rules for triplets. I'd be interested to hear how bug manifests itself? MO:DCA Specification dictates the order of the triplets, here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3M5M00/5.82.2?SHELF=APSBK320DT=20010307105730 I don't believe that it does, this is just a list of possible applicable triplets for the TagLogicalElement structure field, the order in which they are present should not be important. Attribute Qualifier is the last part of TLE structured field. One of our customers has a process that extracts the TLE values which now fails because the 10 bytes of the AttributeQualifier occur in front of the value. I do not think that it is correct for your customer to make this assumption about the position of the triplet in the structured field data. AFAIK it is still perfectly valid AFP so long as all the mandatory triplets are present and all the structured field data lengths and triplet data lengths are present and correct. But if this patch fixes the problem for your client I have no problem with you applying it. Adrian.
Re: svn commit: r828678 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp: goca/ modca/ modca/triplets/
Adrian Cumiskey wrote: Hi Chris, Hi Adrian, thanks for your input on this. It is appreciated. 2009/11/26 Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com Adrian Cumiskey wrote: I agree it might be better if the AttributeQualifier triplet is at the end of the list as it is optional, and FullyQualifiedName and AttributeValue are both manditory. I would be very surprised if this should cause a problem as I don't believe there are any ordering rules for triplets. I'd be interested to hear how bug manifests itself? MO:DCA Specification dictates the order of the triplets, here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3M5M00/5.82.2?SHELF=APSBK320DT=20010307105730 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3M5M00/5.82.2?SHELF=APSBK320DT=20010307105730 I don't believe that it does, this is just a list of possible applicable triplets for the TagLogicalElement structure field, the order in which they are present should not be important. You could well be right here. Since I am not an expert on AFP I asked Jeremias for his thoughts too. We could see nothing in the MO:DCA spec to confirm or deny either way. Attribute Qualifier is the last part of TLE structured field. One of our customers has a process that extracts the TLE values which now fails because the 10 bytes of the AttributeQualifier occur in front of the value. I do not think that it is correct for your customer to make this assumption about the position of the triplet in the structured field data. AFAIK it is still perfectly valid AFP so long as all the mandatory triplets are present and all the structured field data lengths and triplet data lengths are present and correct. But if this patch fixes the problem for your client I have no problem with you applying it. Based on what you've told me today I tend to agree that anyone writing an AFP Parser should not assume the order of triplets matches the specification. However, I would imagine that a lot of people writing such a parser would tend to (incorrectly?) assume that the order of the triplets would match that shown in the structured field definition in the specification. So if FOP does choose to deviate from the shown order, we may find that AFP streams cannot be processed by some printers/viewers/software. Which is not desirable. Adrian. Thanks, Chris
DO NOT REPLY [Bug 48293] New: Unable to extract the data from pdf file for greek fonts
https://issues.apache.org/bugzilla/show_bug.cgi?id=48293 Summary: Unable to extract the data from pdf file for greek fonts Product: Fop Version: all Platform: PC OS/Version: Windows XP Status: NEW Severity: critical Priority: P1 Component: fonts AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: maruthivenugopal.band...@ge.com Created an attachment (id=24624) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24624) it contains the problem with greek font in pdf Hi fop dev team, We are facing an issue for extracting data from the pdf files, which are belongs to greece, for example, when we tried to copy the content of pdf file in word document, it is displaying that content as square boxes. Kindly help us on this issue. Thanks Regards Maruthi -- 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: Thoughts on Bug 48237
Hi Jeremias, I think I see what you have in mind - the interface could simply expose methods like *Color convertXtoY(Color)*. Or did you have in mind the methods returning output type-specific color representaions? Should AbstractPaintingState be responsible holding the ColorConverter and exposing it as a property e.g for the utility of AFPGraphics2D before calling setColor() on the GraphicsObject instance? Cheers, Pete On Wed, Nov 25, 2009 at 8:26 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Hi Peter See my question I attached to bug 48237. But of course, the ideal case is to have the color converted properly if possible. On 24.11.2009 15:30:30 Peter Hancock wrote: At present FOP does not respect an image color setting of 'b+w' when rendering svg to afp (see Bug 48237) According to the AFP spec ( http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320DT=20001002123303 ) it does not seem possible to specify a grayscale color space, and so my question is how should colour be controlled? I think there are two general approached besides just using RGB: - CMYK with only the K component (that is a clear indication that we want a fully black color or shades of that) - using a Highlight color space (assuming black as a highlight/spot color) But I have no experience with highlight colors on AFP, so I can't tell if it would work. Since AFPGraphics2D is responsible for setting the color on the MODCA GraphicsObject prior to calling drawing methods, would a sensible fix to the problem be to convert the awt.Color before calling this setter? Probably. I have some tentative need to have a general color conversion facility for FOP (not just AFP). For example, at some point we may want to have color conversion from sRGB to CMYK. Another use case for a color converter would be a detector which would convert any grayscale color (R, G, B or C, M, Y with equal values) to a CMYK value (with only K) which might in certain situations improve output quality because otherwise a RIP might be inclined to mix black by mixing CMY. I can imagine that a general interface could be defined for which there could be multiple implementations depending on the use case and configuration. For the present case, one implementation of that interface per color setting could be written for AFP. Not sure, just brainstorming. Any thoughts would be most welcome, Pete Jeremias Maerki
Re: Thoughts on Bug 48237
Hi Peter On 26.11.2009 21:06:42 Peter Hancock wrote: Hi Jeremias, I think I see what you have in mind - the interface could simply expose methods like *Color convertXtoY(Color)*. Or did you have in mind the methods returning output type-specific color representaions? Pretty much just one very simple Color convert(Color) method. Not sure, yet, if it's too simple. ;-) But at least this wouldn't make any assumption what kind of color conversion happens. The setup is done elsewhere. Having a simple interface has the advantage that a converter can be used in different places. Should AbstractPaintingState be responsible holding the ColorConverter and exposing it as a property e.g for the utility of AFPGraphics2D before calling setColor() on the GraphicsObject instance? I haven't really thought that far, but that sounds about right. The original color should be preserved as long as possible IMO, and only be changed where it makes sense. And that would most probably be at the point where it is set on the AFP graphics object. Cheers, Pete On Wed, Nov 25, 2009 at 8:26 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Hi Peter See my question I attached to bug 48237. But of course, the ideal case is to have the color converted properly if possible. On 24.11.2009 15:30:30 Peter Hancock wrote: At present FOP does not respect an image color setting of 'b+w' when rendering svg to afp (see Bug 48237) According to the AFP spec ( http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320DT=20001002123303 ) it does not seem possible to specify a grayscale color space, and so my question is how should colour be controlled? I think there are two general approached besides just using RGB: - CMYK with only the K component (that is a clear indication that we want a fully black color or shades of that) - using a Highlight color space (assuming black as a highlight/spot color) But I have no experience with highlight colors on AFP, so I can't tell if it would work. Since AFPGraphics2D is responsible for setting the color on the MODCA GraphicsObject prior to calling drawing methods, would a sensible fix to the problem be to convert the awt.Color before calling this setter? Probably. I have some tentative need to have a general color conversion facility for FOP (not just AFP). For example, at some point we may want to have color conversion from sRGB to CMYK. Another use case for a color converter would be a detector which would convert any grayscale color (R, G, B or C, M, Y with equal values) to a CMYK value (with only K) which might in certain situations improve output quality because otherwise a RIP might be inclined to mix black by mixing CMY. I can imagine that a general interface could be defined for which there could be multiple implementations depending on the use case and configuration. For the present case, one implementation of that interface per color setting could be written for AFP. Not sure, just brainstorming. Any thoughts would be most welcome, Pete Jeremias Maerki Jeremias Maerki
