RE: Problems with break conditions and empty pages

[Glen Mazza]

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> > -Original Message-
> > From: Glen Mazza [mailto:[EMAIL PROTECTED]
> >
> 
> Hi Glen,
> 
> > Also, as food for thought, I wonder if the two
> methods
> > Luca has mentioned should eventually be in
> > FlowLayoutManager (FLM) instead.  The break
> properties
> > appear relevant only for fo:flow descendants.
> 
> Interesting idea. The FLM may have more convenient
> access to the information
> needed to deal with exactly this type of
> situation... 

Well, the FLM is the immediate LM child of PSLM, so it
should have everything that PSLM does (except for the
static content, which I don't think we care about when
it comes to page breaking anyway.)  Ideally, FLM
should be the topmost LM that handles the page
breaking, no?  I wonder if the Knuth code should be
out of PSLM completely, i.e., have FLM have this
method:

PageViewport[] generatePages(),

which would be called by PSLM, and once it returns,
PSLM then takes care of static content before sending
each page to the AreaTreeModel for rendering.

(Or, have the FLM feed the pages back to PSLM
one-by-one, after it finishes the flow for that page. 
Same principle here--the FLM would do the breaking.)

Luca, Jeremias, WDYT?

> at the very least,
> it's worth considering moving part of the logic to
> FLM --say, storing a
> state variable indicating whether the last
> page-break was forced or not-- so
> the result of PSLM.needNewPage() would depend on
> FLM.needNewPage() which
> would in its turn depend on 'lastPBForced'.
> OTOH, this state variable could also be stored in
> the PSLM itself...
> 
> Roughly, the logic could become something like
> 
> PSLM.needNewPage(int breakVal) {
>   if( (curPage != null) &&
> (curPage.getPage().isEmpty() ) {
> if( breakVal == PAGE ) {
>   return (currentPageNum == 1);
> } else {
>   boolean evenPage = (currentPageNum % 2 == 0);
>   return ((breakVal == (evenPage ? ODD_PAGE :
> EVEN_PAGE)) ||
> lastPBForced);
> }
>   } else {
> return true;
>   }
> }
> 

The logic is not as much a concern to me as its
location.  This seems like it should ideally *all* be
in FLM.  I would think FLM is to completely take care
of the fo:flow, including making 47 pages if need be,
doing the incrementing of columns within the span on
each page, etc.  PSLM would just add the static
content after each page-viewport is returned to it by
FLM.  I wonder if PSLM should be so designed that if
we had multiple ways to break up pages--it might mean
multiple FLM implementations, but PSLM would be the
same regardless.

Thanks,
Glen

DO NOT REPLY [Bug 34354] - Not suported "menu"

[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=34354





--- Additional Comments From [EMAIL PROTECTED]  2005-04-22 03:23 ---
(In reply to comment #4)
> "How this(Menu)can be implemented in PDF in the first place" My 
> answer is that I don't need implementation of it , I want only that Batik 
> ignore it - it's not an error to use it.

   It is an error to use it.  You can not add arbitrary elements to
the SVG namespace.  If the menu element were in another namespace
(say Adobe something) Batik would ignore it and processes the elements
in the SVG namespace but you can not place arbitrary elements in the SVG 
namespace, it is a violation of the SVG specification.

-- 
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 34354] - Not suported "menu"

[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=34354





--- Additional Comments From [EMAIL PROTECTED]  2005-04-22 01:43 ---
(In reply to comment #3)
> Your example file gives me error messages in Adobe SVG Viewer and Batik 
> Squiggle. You seem to use an old SVG dialect (SVG 1.0 Candidate 
> Recommendation) which is totally out of date. And then I can't find any 
> reference to the "menu" elements in any of the SVG specifications. So it is 
> not clear to me what you're trying to do here. You might want to be a bit 
more 
> verbose about that. Where are these menus defined? Does Batik itself support 
> them? If Batik doesn't, FOP won't, either. I also don't see how this can be 
> implemented in PDF in the first place.

The code can't work by itself , it is looking for JavaScript functions that 
manipulate the SVG output (Context Menu of Adobe is working not Only in Adobe 
I tried it also in corel SVG viewer and it's worked just fine.
I can attaché SVG with no calls to any JS function. and regarding the your 
question , "How this(Menu)can be implemented in PDF in the first place" My 
answer is that I don't need implementation of it , I want only that Batik 
ignore it - it's not an error to use it.



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

RE: Problems with break conditions and empty pages

[Andreas L. Delmelle]

> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]


> Also, a break-before="page" on the very first block in the
> document seems to be ignored. Is that correct behaviour?

After consulting the Rec, I'm still a bit confused, but I'm beginning to
think that it *is* correct to drop the very first break-before (or last
break-after), and that one blank page is the maximum between the two blocks
I described earlier...

> Overall, there seems to be something wrong in this logic in
> PSLM.needNewPage() :

So it seems I was wrong about the above. My apologies.

Problem of the first or last odd/even page-break before/after *in* a block
remains...

Greetz,

Andreas

RE: Problems with break conditions and empty pages

[Andreas L. Delmelle]

> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>

> I also tried two fo:blocks, first one with break-after="even-page" and the
> second with break-before="even-page", and I don't know exactly what the
> result is supposed to be, but IIC, if the first block ends on an odd page,
> there should be three blank pages in between (?)

Sorry, that's 'two' blank pages. The second block should start on the third
empty page (= the second even page).

Cheers,

Andreas

RE: Problems with break conditions and empty pages

[Andreas L. Delmelle]

> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>

Hi Glen,

> Also, as food for thought, I wonder if the two methods
> Luca has mentioned should eventually be in
> FlowLayoutManager (FLM) instead.  The break properties
> appear relevant only for fo:flow descendants.

Interesting idea. The FLM may have more convenient access to the information
needed to deal with exactly this type of situation... at the very least,
it's worth considering moving part of the logic to FLM --say, storing a
state variable indicating whether the last page-break was forced or not-- so
the result of PSLM.needNewPage() would depend on FLM.needNewPage() which
would in its turn depend on 'lastPBForced'.
OTOH, this state variable could also be stored in the PSLM itself...

Roughly, the logic could become something like

PSLM.needNewPage(int breakVal) {
  if( (curPage != null) && (curPage.getPage().isEmpty() ) {
if( breakVal == PAGE ) {
  return (currentPageNum == 1);
} else {
  boolean evenPage = (currentPageNum % 2 == 0);
  return ((breakVal == (evenPage ? ODD_PAGE : EVEN_PAGE)) ||
lastPBForced);
}
  } else {
return true;
  }
}

Question then only remains where that 'lastPBForced' is set --somewhere in
PSLM.makeNewPage()?

As to your preceding question:

> > Just so I understand how this is supposed to work,
> > will someone please confirm my assumptions below:
> >

Your assumptions are all absolutely correct IMO.

Cheers,

Andreas

RE: Problems with break conditions and empty pages

[Andreas L. Delmelle]

> -Original Message-
> From: Luca Furini [mailto:[EMAIL PROTECTED]
>
>

Hi,

> It seems there is a bug affecting the creation of the right kind of page
> for documents containing blocks with break-* = "odd-page" or "even-page".
>


> I think this could depend on the conditions tested in the methods
> PSLM.needEmptyPage() and PSLM.needNewPage(); in particular, the first one
> should return false if the first page has already been created, while now
> it seems to return always true.

Agreed. Had a quick look, and wondered if it could be caused by the
breakValue being passed in.
If this value is _always_ influenced by the break-* props of the _current_
block, regardless of whether the break condition has already been met on a
previous or following page, *and* that block spans multiple pages, the
result is incorrect... It seems the methods in themselves are not the only
cause, but we should also look at the points where the breakValue is
computed.

I also tried two fo:blocks, first one with break-after="even-page" and the
second with break-before="even-page", and I don't know exactly what the
result is supposed to be, but IIC, if the first block ends on an odd page,
there should be three blank pages in between (?) Currently, the result is
exactly what you would expect if only one of the two break-* props had been
specified as 'page'.
Also, a break-before="page" on the very first block in the document seems to
be ignored. Is that correct behaviour?

Overall, there seems to be something wrong in this logic in
PSLM.needNewPage() :

if the current page is empty, then
  if the break-condition is 'page', then
we don't need a new page
  else if the current page is odd, then
we need a new page if the break-condition is 'even-page'
  else
we need a new page if the break-condition is 'odd-page'
else
  we need a new page

So, bottom-line is that we can only need a new page

if the current one is not empty, or
if the current one is empty, but it isn't odd/even...

These tests should be combined in some other way, but I can't say which way
exactly. Maybe the breakValue should be extended to contain more info than
just PAGE/ODD/EVEN ...?
Seems like we also need to be able to answer the question:
"Did we end up on the current page as a result of a previous forced
break-after?"


Cheers,

Andreas

Re: Problems with break conditions and empty pages

[Glen Mazza]

Also, as food for thought, I wonder if the two methods
Luca has mentioned should eventually be in
FlowLayoutManager (FLM) instead.  The break properties
appear relevant only for fo:flow descendants.

Glen

--- Glen Mazza <[EMAIL PROTECTED]> wrote:
> Just so I understand how this is supposed to work,
> will someone please confirm my assumptions below:
> 
> 1.) If FOP is processing a block on the middle of
> page
> 17 with a break-before value of "even-page", FOP is
> supposed to render this block at the top of page 18
> instead.
> 
> and
> 
> 2.) If FOP is processing a block on the middle of
> page
> *18* with a break-before value of "even-page", FOP
> is
> supposed to render it at the top of page 20 instead.
>  
> 
> and
> 
> 3.) The above processing is done only once for the
> fo:block with this property.  I.e., assuming no
> child
> of fo:block has this property as well, if the block
> takes up multiple pages it will use pages
> 18-19-20-21-22..., for (1) above, and *not*
> 18-20-22-24... 
> 
> Thanks,
> Glen 
> 
> 
> --- Luca Furini <[EMAIL PROTECTED]> wrote:
> > It seems there is a bug affecting the creation of
> > the right kind of page
> > for documents containing blocks with break-* =
> > "odd-page" or "even-page".
> > 
> > If break-before = "odd-page" *each* page with some
> > content is odd; even
> > pages are all empty.
> > 
> > If break-before = "even-page" the content is
> placed
> > only on even pages,
> > while odd pages are empty; moreover, if the block
> > with break-before is the
> > first one in the document it is placed on the
> first
> > page (which is odd!),
> > without adding an empty page before.
> > 
> > The same happens with break-after.
> > 
> > I think this could depend on the conditions tested
> > in the methods
> > PSLM.needEmptyPage() and PSLM.needNewPage(); in
> > particular, the first one
> > should return false if the first page has already
> > been created, while now
> > it seems to return always true.
> > 
> > I'll look at this again next week, obviously
> unless
> > someone finds a fix
> > before! :-)
> > 
> > Regards
> > Luca
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 

Re: Problems with break conditions and empty pages

[Glen Mazza]

Just so I understand how this is supposed to work,
will someone please confirm my assumptions below:

1.) If FOP is processing a block on the middle of page
17 with a break-before value of "even-page", FOP is
supposed to render this block at the top of page 18
instead.

and

2.) If FOP is processing a block on the middle of page
*18* with a break-before value of "even-page", FOP is
supposed to render it at the top of page 20 instead.  

and

3.) The above processing is done only once for the
fo:block with this property.  I.e., assuming no child
of fo:block has this property as well, if the block
takes up multiple pages it will use pages
18-19-20-21-22..., for (1) above, and *not*
18-20-22-24... 

Thanks,
Glen 


--- Luca Furini <[EMAIL PROTECTED]> wrote:
> It seems there is a bug affecting the creation of
> the right kind of page
> for documents containing blocks with break-* =
> "odd-page" or "even-page".
> 
> If break-before = "odd-page" *each* page with some
> content is odd; even
> pages are all empty.
> 
> If break-before = "even-page" the content is placed
> only on even pages,
> while odd pages are empty; moreover, if the block
> with break-before is the
> first one in the document it is placed on the first
> page (which is odd!),
> without adding an empty page before.
> 
> The same happens with break-after.
> 
> I think this could depend on the conditions tested
> in the methods
> PSLM.needEmptyPage() and PSLM.needNewPage(); in
> particular, the first one
> should return false if the first page has already
> been created, while now
> it seems to return always true.
> 
> I'll look at this again next week, obviously unless
> someone finds a fix
> before! :-)
> 
> Regards
> Luca
> 
> 
> 
> 
> 
> 
> 

Problems with break conditions and empty pages

[Luca Furini]

It seems there is a bug affecting the creation of the right kind of page
for documents containing blocks with break-* = "odd-page" or "even-page".

If break-before = "odd-page" *each* page with some content is odd; even
pages are all empty.

If break-before = "even-page" the content is placed only on even pages,
while odd pages are empty; moreover, if the block with break-before is the
first one in the document it is placed on the first page (which is odd!),
without adding an empty page before.

The same happens with break-after.

I think this could depend on the conditions tested in the methods
PSLM.needEmptyPage() and PSLM.needNewPage(); in particular, the first one
should return false if the first page has already been created, while now
it seems to return always true.

I'll look at this again next week, obviously unless someone finds a fix
before! :-)

Regards
Luca