https://issues.apache.org/bugzilla/show_bug.cgi?id=48048
Summary: [PATCH] AFP renderer outputs incorrect values for GBAR ( Graphics Begin Area ) Product: Fop Version: all Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: d...@dwink.net Created an attachment (id=24414) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24414) Patch Per the AFP GOCA specification at http://www.outputlinks.com/SpecialInterest/AFPColorConsortium/ibm_goca_ha3n1r01.pdf , the GBAR order should output two bytes: 0x68 (the order code) and a 1-byte set of bit flags. The current FOP implementation interprets the specification in a least-significant-bit fashion: bit 0 is the least-valued bit, and bit 1 is the next-least-valued bit to the left. This makes the valid values (in hex) either 0x01 or 0x03, and the constants are set to generate these values. However, according to the preface to the specification (page iv, or #6 in the PDF) , "bits are specified with bit 0 meaning the most significant bit". Interpreting the specification this way makes the valid values for the second byte either 0x80 or 0xC0. The attached patch updates the Graphics Begin Area code to use the proper constant values. Many AFP viewers and printers ignore the bit field entirely, but those that interpret it strictly reject FOP's generated AFP output. To reproduce: Render an FO containing an SVG into AFP format; then examine the output using an AFP interpreter or hex editor. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.