Uploaded image for project: 'FOP'
  1. FOP
  2. FOP-1569

incorrect line height for mixed font content

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Resolution: Unresolved
    • 2.5
    • None
    • font/unqualified
    • None
    • Operating System: All
      Platform: All
    • 45733

    Description

      In context of having <fo:block> with multiple font families listed, like:

      <block font-family='serif,Symbol'>
      (∀1) (+2) (↑3) (+4) (∀5)
      </block>

      or

      <block font-family='serif,Symbol'>
      (∀1) (+2) (<character character='↑'/>3) (+4) (∀5)
      </block>

      from http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/200808.mbox/%3c1220224006.15155.13.camel@moonpix%3e

      """
      'Symbol' is a taller font than 'serif'.

      FOP decides how tall each line should be and then places characters
      within that line. In the event that a character is "too tall" to fit
      then it ends up being aligned to the top (and hanging out the bottom).
      This is what happens when you have UTF8 character inline.

      When you use <character> you somehow get FOP to notice that you're
      placing taller characters in the line and it takes this into account
      when deciding the proper height of the line.

      When you don't use <character> then FOP makes its decision about the
      height of the line based solely on the first listed font family
      (ignoring all of the others, irrespective of if they are used for font
      substitution in that line).

      """

      Andreas Delmelle provides addition insight in his email here: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/200809.mbox/%3c12DB9901-D56D-4C4C-A77B-CF3A35C4EE5E@telenet.be%3e

      """
      Having taken a quick, closer look at the related code, it goes in
      this direction indeed.

      Technically, the story is that, without fo:character or fo:inline a
      combined text-area is generated for each separate 'word' (in the
      sense of: uninterrupted sequence of non-white-space characters,
      regardless of whether they can be rendered in the same font).

      Those areas are currently all based on a single alignment-context
      (which seems to correspond to the first font-family in the list; this
      explains why we get a different result when putting the Symbol font
      first). AFAICT, it does not seem like a real tough problem to
      solve... I do seem to remember Max pointing out this issue at some
      time while implementing font-selection
      If we place the characters in an fo:inline or an fo:character, the
      only big difference is that a new alignment-context is created
      automatically, which later on triggers correct baseline alignment of
      the two pieces.
      """

      Attachments

        Activity

          People

            Unassigned Unassigned
            desrt@desrt.ca Ryan Lortie (desrt)
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: