DO NOT REPLY [Bug 36004] [PATCH] Block content in inline content

[bugzilla]

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

Glenn Adams  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #6 from Glenn Adams  2012-04-01 07:09:24 UTC ---
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

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

Re: block content in inline content

[Jeremias Maerki]

Not much to contribute here but I'm glad to see that you're working in
this area! I felt a little lonely lately. :-)

On 22.12.2005 10:13:37 Simon Pepping wrote:
> I have tried to removed the double-list return type (a list of
> KnuthSequences) of InlineLevelLM.getNextKnuthElements. I have
> abandoned those efforts.
> 
> If the return type is only a single list, the call stack has to return
> to LineLM.getNextKnuthElements for every completed paragraph and every
> sequence of block elements. This is certainly possible, and was the
> case in the past. It is true that most paragraphs consist of only one
> Knuth paragraph, and do not contain block content. For those
> paragraphs a single list return type would be efficient.
> 
> It would require look-ahead: Can the next sequence of Knuth elements
> be appended to this one? And caching the sequence if not. Probably not
> a big deal.
> 
> Nevertheless, I do not feel inspired to code this only for sake of the
> return type.
> 
> Having an inherited method with a list with different types of content
> elements will be a problem when we would ever use type-safe
> collections. I would prefer to tackle this by defining a return type
> KnuthSequences, which would be able to hold a single KnuthSequence or
> a list of KnuthSequences, with logic to handle both cases
> transparently for its clients.
> 
> I thought you may wish to know these considerations.
> 
> Simon
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.nl



Jeremias Maerki

block content in inline content

[Simon Pepping]

I have tried to removed the double-list return type (a list of
KnuthSequences) of InlineLevelLM.getNextKnuthElements. I have
abandoned those efforts.

If the return type is only a single list, the call stack has to return
to LineLM.getNextKnuthElements for every completed paragraph and every
sequence of block elements. This is certainly possible, and was the
case in the past. It is true that most paragraphs consist of only one
Knuth paragraph, and do not contain block content. For those
paragraphs a single list return type would be efficient.

It would require look-ahead: Can the next sequence of Knuth elements
be appended to this one? And caching the sequence if not. Probably not
a big deal.

Nevertheless, I do not feel inspired to code this only for sake of the
return type.

Having an inherited method with a list with different types of content
elements will be a problem when we would ever use type-safe
collections. I would prefer to tackle this by defining a return type
KnuthSequences, which would be able to hold a single KnuthSequence or
a list of KnuthSequences, with logic to handle both cases
transparently for its clients.

I thought you may wish to know these considerations.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Block content in inline content

[Jeremias Maerki]

What the hell is unfortunate about having a better idea? If that helps
make the code simpler and more easily understandable that's cool. And it
sounds like it does. I simply had to fix the problem somehow because I
want to get the first release out as soon as possible. And I was very
happy that you already provided me with something to start with (that
doesn't happen for the first time. Hey Luca!). It doesn't have to be
(and can't be) perfect in this short time. So I'm perfectly happy if you
look at this again when you have time.

On 21.08.2005 20:58:36 Simon Pepping wrote:
> Thanks for solving bug 36248, total number of pages with empty block
> :ClassCastException in KnuthInlineBox.
> 
> Unfortunately perhaps, I think I have a better idea for handling block
> content in inline content, specifically in InlineLM. 
> 
> For each block Knuth element that InlineLM receives from a BlockLevel
> child LM, it should insert a complete one-line paragraph into its
> return list. This paragraph consists of a KnuthBox, a KnuthGlue with
> infinite stretchability, and a negative infinite penalty.  In this way
> InlineLM would hide the block content from the other LMs, which is
> appropriate. This also solves the problem that getNextKnuthElements
> does not really return the same type of object for BlockLevel and
> InlineLevel LMs.
> 
> It allows us almost to go back to the old code in LineLM. The only
> difference is that the return list may contain multiple paragraphs,
> whose end is signalled by a negative infinite penalty. Even this is
> not really necessary, but I think it is more efficient than returning
> to LineLM at the end of each paragraph.
> 
> I have not investigated how InlineLM would do the conversion from
> block elements to a paragraph and back, but I do not see a huge
> problem there.
> 
> If no one else does it before me, I will try to work out this idea,
> but not until several weeks from now.
> 
> Sorry for not thinking of this rather obvious solution earlier. It
> would have saved some work.



Jeremias Maerki

Block content in inline content

[Simon Pepping]

Thanks for solving bug 36248, total number of pages with empty block
:ClassCastException in KnuthInlineBox.

Unfortunately perhaps, I think I have a better idea for handling block
content in inline content, specifically in InlineLM. 

For each block Knuth element that InlineLM receives from a BlockLevel
child LM, it should insert a complete one-line paragraph into its
return list. This paragraph consists of a KnuthBox, a KnuthGlue with
infinite stretchability, and a negative infinite penalty.  In this way
InlineLM would hide the block content from the other LMs, which is
appropriate. This also solves the problem that getNextKnuthElements
does not really return the same type of object for BlockLevel and
InlineLevel LMs.

It allows us almost to go back to the old code in LineLM. The only
difference is that the return list may contain multiple paragraphs,
whose end is signalled by a negative infinite penalty. Even this is
not really necessary, but I think it is more efficient than returning
to LineLM at the end of each paragraph.

I have not investigated how InlineLM would do the conversion from
block elements to a paragraph and back, but I do not see a huge
problem there.

If no one else does it before me, I will try to work out this idea,
but not until several weeks from now.

Sorry for not thinking of this rather obvious solution earlier. It
would have saved some work.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: [Bug 36004] - [PATCH] Block content in inline content

[Jeremias Maerki]

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

[Jeremias Maerki]

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, [EMAIL PROTECTED] wrote:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=36004
> > 
> > --- Additional Comments From [EMAIL PROTECTED]  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

Re: [Bug 36004] - [PATCH] Block content in inline content

[Simon Pepping]

On Mon, Aug 08, 2005 at 04:36:40PM +0200, [EMAIL PROTECTED] wrote:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36004
> 
> --- Additional Comments From [EMAIL PROTECTED]  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

DO NOT REPLY [Bug 36004] - [PATCH] Block content in inline content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36004


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |




--- Additional Comments From [EMAIL PROTECTED]  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?

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

DO NOT REPLY [Bug 36004] - [PATCH] Block content in inline content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36004


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-08-04 22:31 ---
Moved to the branch 'inlineblock' for further development

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

DO NOT REPLY [Bug 36004] - [PATCH] Block content in inline content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36004





--- Additional Comments From [EMAIL PROTECTED]  2005-08-03 22:33 ---
Implementation notes


KnuthSequence now has a variable and a method declaring whether it
contains a sequence of inline or block Knuth elements.

getNextKnuthElements() of InlineLevelLMs construct and return a list
of KnuthSequences. During the construction, if the last sequence is an
inline sequence, it is kept open for addition of further returned
inline Knuth elements (lastSequence != null). While it is open, newly
received inline sequences are added to it. It is closed when a
received inline sequence is ended by a negative infinite penalty,
which signals a forced line break, or when a forced line break is read
(TextLM).

Those InlineLevelLMs that can have BlockLevelLM children, turn the
list of Knuth elements that they receive from their BlockLevelLM
children into a block sequence, after having wrapped their
positions. Before they add this sequence to their return list, they
close the open inline sequence. They create a separate sequence for
each block level child LM.

LineLM, collectInlineKnuthElements: inline Knuth sequences are turned
into paragraphs. The positions of the elements of block sequences are
wrapped. knuthParagraphs is a list of Paragraphs and block
KnuthSequences.

Represent each block sequence (one line area) by a LineBreakPosition,
with iParIndex as the index of the block sequence in
knuthParagraphs. The LBP must be placed as
lineLayoutsList[0].possibilitiesList[0].breakPositions[0], in
agreement with the placement of LBPs of inline sequences. The type of
the block sequence leads to different processing in addAreas: an
iterator over the block sequence, the child area being placed in a
single line area (and the block areas must be children of a single
inline area, which is a descendant of the child area of the line
area).

State diagram of InlineLM:
Possible states:
 I: lastSequence != 0 && lastSequence.isInlineSequence()
 B: lastSequence != 0 && !lastSequence.isInlineSequence()
 0: lastSequence == 0
Start state = 0
InlineLevelLMs return a list of Knuth sequences, mixed inline and
 block; each returned sequence is a separate event
BlockLevelLMs return a list of Knuth elements
Possible events:
 ILM(i): InlineLevelLM returns inline sequence
 ILM(ic): InlineLevelLM returns closed inline sequence
 ILM(b): InlineLevelLM returns block sequence
 BLM(s): BlockLevelLM, curLM == lastLM
 BLM(o): BlockLevelLM, curLM != lastLM
 BLM:BlockLevelLM = BLM(s) or BLM(o)
Symbols:
 [ I: open new lastInlineSequence and add to return list,
  add returned inline sequence
 [ L: open new lastBlockSequence and add to return list,
  add returned list
 + I: add inline sequence to existing lastInlineSequence
 + L: add list to existing lastBlockSequence
 ]: close sequence
 B: add block sequence to return list
Transitions:
0 - ILM(i): [ I,  state becomes I
  - ILM(ic): [ I ],   state remains 0
  - ILM(b): B,state remains 0
  - BLM:[ L,  state becomes B
I - ILM(i): + I,  state remains I
  - ILM(ic): + I ],   state becomes 0
  - ILM(b): ] B,  state becomes 0
  - BLM:] [ L,state becomes B
B - ILM(i): ] [ I,state becomes I
  - ILM(ic): ] [ I ], state becomes 0
  - ILM(b): ] B,  state becomes 0
  - BLM(s): + L,  state remains B
  - BLM(o): ] [ L,state remains B

The routine may end in states 0 or I. Technically it can also end in
state B, but the parent LM will never consider a returned block
sequence as open; therefore ending in state B is effectively ending in
state 0.

An inline sequence must be closed by an explicit negative infinite
penalty, so that the parent LM can see that it is closed. A block
sequence is implicitly closed. Only its creator can add elements to
it.

State diagram of InlineLevelLMs with InlineLevelM children:
Possible states:
 I: lastSequence != 0
 0: lastSequence == 0
Start state = 0
InlineLevelLMs return a list of Knuth sequences, mixed inline and
 block; each returned sequence is a separate event
Possible events:
 ILM(i): InlineLevelLM returns inline sequence
 ILM(ic): InlineLevelLM returns closed inline sequence
 ILM(b): InlineLevelLM returns block sequence
Symbols:
 [ I: open new lastInlineSequence and add to return list,
  add returned inline sequence
 + I: add inline sequence to existing lastInlineSequence
 ]: close sequence
 B: add block sequence to return list
Transitions:
0 - ILM(i): [ I,  state becomes I
  - ILM(ic): [ I ],   state remains 0
  - ILM(b): B,state remains 0
I - ILM(i): + I,  state remains I
  - ILM(ic): + I ],   state becomes 0
 

DO NOT REPLY [Bug 36004] - [PATCH] Block content in inline content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36004>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36004





--- Additional Comments From [EMAIL PROTECTED]  2005-08-03 22:14 ---
Created an attachment (id=15868)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15868&action=view)
My work on block content in inline content


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

DO NOT REPLY [Bug 36004] New: - [PATCH] Block content in inline content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36004>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36004

   Summary: [PATCH] Block content in inline content
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: page-master/layout
AssignedTo: fop-dev@xml.apache.org
ReportedBy: [EMAIL PROTECTED]


This patch contains the current state of my work on block content in inline 
content.

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