You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2008/09/03 08:25:43 UTC

DO NOT REPLY [Bug 45733] New: incorrect line height for mixed font content

https://issues.apache.org/bugzilla/show_bug.cgi?id=45733

           Summary: incorrect line height for mixed font content
           Product: Fop
           Version: all
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: fonts
        AssignedTo: fop-dev@xmlgraphics.apache.org
        ReportedBy: desrt@desrt.ca


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.
"""


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45733] incorrect line height for mixed font content

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45733

--- Comment #3 from Glenn Adams <gl...@skynav.com> 2012-04-07 01:44:12 UTC ---
resetting P2 open bugs to P3 pending further review

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45733] incorrect line height for mixed font content

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45733

Glenn Adams <gl...@skynav.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45733] incorrect line height for mixed font content

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45733

Eric <e....@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |e.d.programmer@gmail.com

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45733] incorrect line height for mixed font content

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45733

--- Comment #2 from Max Berger <ma...@berger.name> 2010-03-12 08:05:32 UTC ---
This was exactly the issue that I pointed out - tried to fix it back then which
did not work out, and then forgot about it.

related bug #46720

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45733] incorrect line height for mixed font content

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45733

--- Comment #1 from Eric <e....@gmail.com> 2010-03-11 14:30:35 UTC ---
I'm also having a problem with this, just trying to use 1 custom font from 2
different font files, one for a normal Lucida and one for bold.  The bold one
came out bigger in a PDF which looks really bad, so I've been looking for a fix
or workaround to either get them to the same size or at least line them up on
the bottom edge instead.  The output looked better in the PreviewPanel than it
did in the PDF.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.