Re: # characters for Base-14 fonts

[Ryan Lortie <de...@desrt.ca>]

On Sun, 2008-08-31 at 17:36 -0400, Ryan Lortie wrote:
> On Sun, 2008-08-31 at 22:22 +0200, Andreas Delmelle wrote:
> > Not sure what the cause of the issue is (yet), but as for a final  
> > try, the following seems to produce desirable results:
> > 
> > <fo:block font-family="serif, Symbol">
> >    (<fo:character character="&#x2191;"/>1) (+2) (<fo:character  
> > character="&#x2200;"/>3) (text)
> > </fo:block>

One additional thing that I've noticed since I wrote my reply:

The <character> tag actually has no effect on the character that it
prints -- instead it affects the layout of the rest of the line, causing
the 'serif' parts of the line to be aligned properly with character in
the tag.

If you put a letter inside <character> then the 'serif' parts of the
line end up lined up like normal.  If you put a symbol then they end up
lined up properly with that symbol.

Look at this:

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

In this case everything looks great -- and it appears that the (+2) and
(+4) that have moved down -- not the ∀ or the ↑ up.

I also did some tests with several lines of text.  Only the physical
line containing the <character> tag renders properly -- the others have
the same issue.

When looking at the several lines of text, however, something
immediately jumps out at you -- any line containing a <character>
rendered with Symbol is taller than all the other lines.  I guess this
is what "makes room" for the 'Symbol' characters to be rendered properly
inline with the 'serif' characters.

So my new wild guess about the nature of this problem is something like:

'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).

Not knowing Java and being completely unfamiliar with the FOP codebase I
have no way to verify that this is the actual nature of the problem or
to know how I'd go about fixing it.  Can anyone help? :)

Thanks for tuning into the saga thus far...

Cheers


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

Re: # characters for Base-14 fonts

[Ryan Lortie <de...@desrt.ca>]

Very sorry.  I meant to reply to this much sooner.

On Tue, 2008-09-02 at 21:20 +0200, Andreas Delmelle wrote:
> If you want, you can open a Bugzilla(*) entry for this, so that the  
> issue is tracked.

I have done so.  The bug is here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=45733 for anyone who
is interested.

Thanks for your help verifying this problem and tracking down its cause.

Cheers


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

Re: # characters for Base-14 fonts

[Andreas Delmelle <an...@telenet.be>]

On Sep 1, 2008, at 01:06, Ryan Lortie wrote:

> <snip />

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

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.

If you want, you can open a Bugzilla(*) entry for this, so that the  
issue is tracked.


Thanks

Andreas

(*) https://issues.apache.org/bugzilla

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org