Fop
  1. Fop
  2. FOP-1716

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

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: general
    • Labels:
      None
    • Environment:
      Operating System: Linux
      Platform: All
    • External issue ID:
      48048

      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.

        Activity

        Hide
        d.w. harks added a comment -

        Attachment GraphicsBeginArea.patch has been added with description: Patch

        Show
        d.w. harks added a comment - Attachment GraphicsBeginArea.patch has been added with description: Patch
        Hide
        Jeremias Maerki added a comment -

        Thanks for spotting this and sending a patch! It is applied now: http://svn.apache.org/viewvc?rev=884129&view=rev

        Show
        Jeremias Maerki added a comment - Thanks for spotting this and sending a patch! It is applied now: http://svn.apache.org/viewvc?rev=884129&view=rev
        Hide
        Glenn Adams added a comment -

        batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

        Show
        Glenn Adams added a comment - batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

          People

          • Assignee:
            fop-dev
            Reporter:
            d.w. harks
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development