(Chris) Re: Traits

[Glen Mazza <gr...@yahoo.com>]

Sorry for the delay, Chris.  BTW, I'm thrilled you're
taking an interest in layout--let's get some patches
from you so we can get you up to committer status!  

--- Chris Bowditch <bo...@hotmail.com> wrote:
> Wouldnt want to have to
> replicate these 
> functions on every sub-class of Area. 

I wouldn't worry too much about that.  I believe
methods themselves don't take up that much memory--and
to a certain degree, we're supposed to be a "reference
implementation"--so methods not relevant for all
instances of a certain base class should not be
defined with that class.

> OTOH not every
> class that derives from 
> Area will have Padding and spacing attributes.
> 

Yes, for that reason I would recommend keeping those
methods in the child classes--even if duplicated. 

> What do you think? I can supply patches if
> necessary.
> 

You said you were interested in working with
block-centering issues.  The
examples\fo\basic\normal.fo example in the 1.0
distribution--which I've been looking at--when run for
PDF in 1.0 has three errors in it (you can see how it
should look if you run it w/0.20.5):

1.)  The "Extensible Markup Language 1.0" title (the
one with a blue background) it not centered properly
within the block.  This is probably an issue within
PDFRenderer.java renderText() function.

2.)  The first lines of text within each fo:block
incorrectly have a leading space appended to them. 
I'm looking at this one currently, it's a problem with
layoutmgr.TextLayoutManager and fo.flow.Block, not
related to the above.

3.)  The inline font-variant="small caps" for
"Extensible Markup Language" in the Abstract section
is not working.  (However, I'm not trained in fonts at
all--this may be very difficult to fix.)

Would you like to tackle the first one (and the third,
if you want a real challenge)?  I'm looking at the
second right now (although you're welcome to beat me
to it on that one as well!), and the third may not be
that bad, given that it's already implemented in
0.20.x (hopefully it can be copied over into 1.0).

But in general, you don't have to wait for me--look at
*any* of the 1.0 example .fo files, check for bugs
(based on comparing 0.20.x vs. 1.0), and submit
patches for them.  Best thing may be to attach (1) the
FO file, (2) PDF before patch applied, (3) PDF after
and (4) of course! the patch itself.

Thanks,
Glen

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: (Chris) Re: Traits

["J.Pietschmann" <j3...@yahoo.de>]

Glen Mazza wrote:
> 1.)  The "Extensible Markup Language 1.0" title (the
> one with a blue background) it not centered properly
> within the block.  This is probably an issue within
> PDFRenderer.java renderText() function.

This may be due to unstripped spaces, see next point.

In any case, justified text seems to be broken. I can't
even figure out *where* text justification is done.

> 2.)  The first lines of text within each fo:block
> incorrectly have a leading space appended to them. 
> I'm looking at this one currently, it's a problem with
> layoutmgr.TextLayoutManager and fo.flow.Block, not
> related to the above.

That's probably in Block.handleWhiteSpace(), I think
because bPrevWasLF starts with false. Ther's probably a
superfluous trailing space as well, for a similar reason.
Also, it seems that the current imlementation will collapse
the two spaces between A and B
  A <fo:wrapper text-decoration="underline">B</fo:wrapper>
but it shouldn't, there should be one space followed by an
underlined space (it's in one of the spec errata).

BTW the entire whitespace handling is incredibly wasteful
if text is intented with multiple spaces to the level of
surrounding elements.

> 3.)  The inline font-variant="small caps" for
> "Extensible Markup Language" in the Abstract section
> is not working.  (However, I'm not trained in fonts at
> all--this may be very difficult to fix.)

Well, in the maintenance code this was hacked in FOText.layout(),
it checked for the font-variant and fed runs of lowercase letters
to with a smaller font and uppercased to further processing in
LineArea.addText() (through addRealText()).
It's not out of the question to do the same in HEAD. Of course,
it would be even better to check whether the font understands
the small caps variant natively and try to take advantage of this
first (there is a reason small caps is a variant, rather than
everybody emulating it itself using uppercase and an 80% sized
font). This requires extending FontState or something like this.

Implementing small caps *efficiently*, well, this is probably a
real challenge.

J.Pietschmann