Fop
  1. Fop
  2. FOP-1385

[PATCH] Support baseline-shift for images

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: images
    • Labels:
      None
    • Environment:
      Operating System: Mac OS X 10.4
      Platform: All
    • External issue ID:
      42785

      Description

      This patch adds support for image plugins to define their baseline-shift. Please note:
      This may break existing image plugins, but recompilaton should be sufficient.

      1. alignmentadjust.patch
        7 kB
        Max Berger
      2. baselineshift.patch
        6 kB
        Max Berger

        Activity

        Max Berger created issue -
        Hide
        Max Berger added a comment -

        The actual patch file

        Show
        Max Berger added a comment - The actual patch file
        Hide
        Max Berger added a comment -

        Attachment baselineshift.patch has been added with description: baselineshift patch

        Show
        Max Berger added a comment - Attachment baselineshift.patch has been added with description: baselineshift patch
        Hide
        Max Berger added a comment -

        Some other comments while I am at it:

        External graphic dimensions are specified in millipoints (int), where as inline-graphics are specified in pts (float). I have followed the same pattern for this patch, but find it quite inconsitent.

        Show
        Max Berger added a comment - Some other comments while I am at it: External graphic dimensions are specified in millipoints (int), where as inline-graphics are specified in pts (float). I have followed the same pattern for this patch, but find it quite inconsitent.
        Hide
        Vincent Hennebert added a comment -

        (In reply to comment #2)

        Hi Max,

        Thanks for your patch. However, I'm slightly reluctant to apply it as
        is. I have a few questions:

        • I can understand the need for an intrinsic baseline-shift for images,
          especially if the image represents, say, a mathematical formula...
          That said, in plain FO I think I would use the alignment-adjust
          property (XSL-FO 1.1, 7.14.1). Now I easily understand that it would
          be difficult to store this information separately from the image but,
          still, shouldn't the image have an intrinsic alignment-adjust instead?
          The description of alignment-adjust says that this property especially
          applies to images which lack of a baseline-table. Whereas
          baseline-shift recreates a whole baseline-table for the area. Granted,
          this doesn't change many things but I think it would be more
          consistent.
        • IIC, the intrinsic baseline-shift may only be a length? Isn't that
          limiting? If the image is scaled for whatever reason, then the length
          no longer makes sense. A percentage would probably be more robust.
          Especially if it's expressed in terms of the image's height. And guess
          what, that's exactly the case with alignment-adjust.
          BTW, percentages are the reason why the other FOs return a Length
          object for their baseline-shift.

        > Some other comments while I am at it:
        >
        > External graphic dimensions are specified in millipoints (int), where
        > as inline-graphics are specified in pts (float). I have followed the
        > same pattern for this patch, but find it quite inconsitent.

        I'm not sure of what you are referring to? For both ExternalGraphic and
        InstreamForeignObject the intrinsic dimensions are specified in
        millipoints.

        WDYT?
        Thanks,
        Vincent

        Show
        Vincent Hennebert added a comment - (In reply to comment #2) Hi Max, Thanks for your patch. However, I'm slightly reluctant to apply it as is. I have a few questions: I can understand the need for an intrinsic baseline-shift for images, especially if the image represents, say, a mathematical formula... That said, in plain FO I think I would use the alignment-adjust property (XSL-FO 1.1, 7.14.1). Now I easily understand that it would be difficult to store this information separately from the image but, still, shouldn't the image have an intrinsic alignment-adjust instead? The description of alignment-adjust says that this property especially applies to images which lack of a baseline-table. Whereas baseline-shift recreates a whole baseline-table for the area. Granted, this doesn't change many things but I think it would be more consistent. IIC, the intrinsic baseline-shift may only be a length? Isn't that limiting? If the image is scaled for whatever reason, then the length no longer makes sense. A percentage would probably be more robust. Especially if it's expressed in terms of the image's height. And guess what, that's exactly the case with alignment-adjust. BTW, percentages are the reason why the other FOs return a Length object for their baseline-shift. > Some other comments while I am at it: > > External graphic dimensions are specified in millipoints (int), where > as inline-graphics are specified in pts (float). I have followed the > same pattern for this patch, but find it quite inconsitent. I'm not sure of what you are referring to? For both ExternalGraphic and InstreamForeignObject the intrinsic dimensions are specified in millipoints. WDYT? Thanks, Vincent
        Hide
        Max Berger added a comment -

        Vincent,

        1) you are right, alignment-adjust seems a better attribute to use. I did some
        tests with the foprep application (JEuclids MathML in FO preprocessor), and
        using percentage values here seems to work fine.

        2) I also have the feeling that I need to set "alignment-baseline" to
        "alphabetic" as well (in the case of Math, but have it settable by the plugin),
        but i am not sure about this, as I have no experience with non-latin languages,
        and even less with non-latin languages and Math.

        3) If i read the spec correctly, the values of baseline-shift and
        alignment-adjust are in the opposite direction: So far I had to use a negative
        baseline-shift, and i should use a positive alignment-adjust (my understanding
        of the spec). However, during my tests I had to use a negative alignment-adjust,
        suggesting that fop has a bug here. This needs further investigation.

        4) The pt. vs. millipoint: What I was referring to is:
        org/apache/fop/fo/flow/InstreamForeignObject.java and
        org/apache/fop/fo/XMLObj,
        which store dimensions using float in pt., where as
        org/apache/fop/fo/flow/ExternalGraphic.java
        stores dimensions in "int" in millipoints.
        Both are fine with me, however, I think this is inconsistent and should be
        unified rather sooner than later. However, changing this will definitely break
        plugins, so it should be done as soon as possible!

        Show
        Max Berger added a comment - Vincent, 1) you are right, alignment-adjust seems a better attribute to use. I did some tests with the foprep application (JEuclids MathML in FO preprocessor), and using percentage values here seems to work fine. 2) I also have the feeling that I need to set "alignment-baseline" to "alphabetic" as well (in the case of Math, but have it settable by the plugin), but i am not sure about this, as I have no experience with non-latin languages, and even less with non-latin languages and Math. 3) If i read the spec correctly, the values of baseline-shift and alignment-adjust are in the opposite direction: So far I had to use a negative baseline-shift, and i should use a positive alignment-adjust (my understanding of the spec). However, during my tests I had to use a negative alignment-adjust, suggesting that fop has a bug here. This needs further investigation. 4) The pt. vs. millipoint: What I was referring to is: org/apache/fop/fo/flow/InstreamForeignObject.java and org/apache/fop/fo/XMLObj, which store dimensions using float in pt., where as org/apache/fop/fo/flow/ExternalGraphic.java stores dimensions in "int" in millipoints. Both are fine with me, however, I think this is inconsistent and should be unified rather sooner than later. However, changing this will definitely break plugins, so it should be done as soon as possible!
        Hide
        Max Berger added a comment -

        and yet another question:

        5) when overwriting alignment adjust, there are two possibilities:
        a) Retrieve set (from .fo file) alignment adjust, and add image-intrinsic
        alignment-adjust
        b) retrieve set alignment adjust. If it is auto (default if not set), then use
        image-intrinsic alignment-adjust, otherwise use the one given from the user

        I think b makes more sense, as the user will be able to explicitly overwrite the
        automatic calculated alignment adjust. However, this behavior may be a little
        irritating, as specifying a value at all (e.g. 0pt instead of auto) will already
        make a difference.

        Show
        Max Berger added a comment - and yet another question: 5) when overwriting alignment adjust, there are two possibilities: a) Retrieve set (from .fo file) alignment adjust, and add image-intrinsic alignment-adjust b) retrieve set alignment adjust. If it is auto (default if not set), then use image-intrinsic alignment-adjust, otherwise use the one given from the user I think b makes more sense, as the user will be able to explicitly overwrite the automatic calculated alignment adjust. However, this behavior may be a little irritating, as specifying a value at all (e.g. 0pt instead of auto) will already make a difference.
        Hide
        Max Berger added a comment -

        Attachment alignmentadjust.patch has been added with description: Updated patch which uses alignment-adjust

        Show
        Max Berger added a comment - Attachment alignmentadjust.patch has been added with description: Updated patch which uses alignment-adjust
        Hide
        Max Berger added a comment -

        If updated the patch to use alignment-adjust instead of baseline-shift, as this is indeed a better solution.

        in reply to my own comments:
        1) done
        2) this defaults to baseline, which is good enough for my use.
        3) I misread the spec. It was just unclearly written.
        4) The issue still stands, for the patch I've used length exclusively, which does not have this problem
        5) Strategy b) is used.

        Show
        Max Berger added a comment - If updated the patch to use alignment-adjust instead of baseline-shift, as this is indeed a better solution. in reply to my own comments: 1) done 2) this defaults to baseline, which is good enough for my use. 3) I misread the spec. It was just unclearly written. 4) The issue still stands, for the patch I've used length exclusively, which does not have this problem 5) Strategy b) is used.
        Hide
        Andreas L. Delmelle added a comment -

        Looked OK to me, so patch applied.

        see: http://svn.apache.org/viewvc?view=rev&rev=554423

        Thanks for the contribution!

        Show
        Andreas L. Delmelle added a comment - Looked OK to me, so patch applied. see: http://svn.apache.org/viewvc?view=rev&rev=554423 Thanks for the contribution!
        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
        Glenn Adams made changes -
        Field Original Value New Value
        Affects Version/s trunk [ 12323672 ]
        Affects Version/s all [ 12323671 ]

          People

          • Assignee:
            fop-dev
            Reporter:
            Max Berger
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development