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 Simon Pepping <sp...@leverkruid.nl> on 2005/08/08 21:37:11 UTC
Re: [Bug 36004] - [PATCH] Block content in inline content
On Mon, Aug 08, 2005 at 04:36:40PM +0200, bugzilla@apache.org wrote:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36004
>
> ------- Additional Comments From jeremias@apache.org 2005-08-08 16:36 -------
> Simon, thanks for your work on inlines and for setting up the branch. As you
> will have seen, I've hacked around a little bit in the branch and I think
> we're ready to merge the branch back into trunk. All necessary tests pass.
> Would you please review? My KnuthElement/KnuthSequence mixture might be
> subject to discussion but it allowed not adjusting some of the LMs and creates
> fewer objects that way. WDYT?
I do not have much time to look at it more closely until Friday or the
weekend. From what I saw by scanning the svn commit logs, my first
reaction is that it works, but it is not what I like. It makes the
code less clean and more complicated by allowing and checking for two
alternative allowed datastructures. My idea is that all InlineLevelLMs
return a list of KnuthSequences for getNextKnuthElements. Of course
you can move it back into the trunk. I can always work further on it
when it is there.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: [Bug 36004] - [PATCH] Block content in inline content
Posted by Jeremias Maerki <de...@greenmail.ch>.
The branch is now merged back into the trunk. It's really cool how easy
this is with SVN in comparison to CVS.
On 08.08.2005 23:28:56 Jeremias Maerki wrote:
> So, I'll merge the branch back into the trunk tomorrow. Optionally
> fixing the LMs that don't return KnuthSequences, yet, should be easy.
> You had already done the big part.
Jeremias Maerki
Re: [Bug 36004] - [PATCH] Block content in inline content
Posted by Jeremias Maerki <de...@greenmail.ch>.
I guessed you wouldn't be that happy. I don't like it so much, either,
but we're already creating so many little objects, and especially
LinkedList are not that inexpensive. We have to decide on whether we
trade speed and memory consumption with code readability, as we have to
in many other places.
So, I'll merge the branch back into the trunk tomorrow. Optionally
fixing the LMs that don't return KnuthSequences, yet, should be easy.
You had already done the big part.
On 08.08.2005 21:37:11 Simon Pepping wrote:
> On Mon, Aug 08, 2005 at 04:36:40PM +0200, bugzilla@apache.org wrote:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=36004
> >
> > ------- Additional Comments From jeremias@apache.org 2005-08-08 16:36 -------
> > Simon, thanks for your work on inlines and for setting up the branch. As you
> > will have seen, I've hacked around a little bit in the branch and I think
> > we're ready to merge the branch back into trunk. All necessary tests pass.
> > Would you please review? My KnuthElement/KnuthSequence mixture might be
> > subject to discussion but it allowed not adjusting some of the LMs and creates
> > fewer objects that way. WDYT?
>
> I do not have much time to look at it more closely until Friday or the
> weekend. From what I saw by scanning the svn commit logs, my first
> reaction is that it works, but it is not what I like. It makes the
> code less clean and more complicated by allowing and checking for two
> alternative allowed datastructures. My idea is that all InlineLevelLMs
> return a list of KnuthSequences for getNextKnuthElements. Of course
> you can move it back into the trunk. I can always work further on it
> when it is there.
>
> Regards, Simon
>
> --
> Simon Pepping
> home page: http://www.leverkruid.nl
Jeremias Maerki