[FOP-1716] [PATCH] AFP renderer outputs incorrect values for GBAR ( Graphics Begin Area )

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 2.5
• Component/s: unqualified
• Environment: Operating System: Linux; Platform: All
• External issue ID: 48048
• Assignee: fop-dev
• Reporter: d.w. harks
• Created: 24/Oct/09 11:18
• Updated: 18/Dec/12 17:00
• Resolved: 01/Apr/12 06:56

Description

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.