Re: Improving Keeps and Breaks

[gerhard . oettl . ml]

Andreas L Delmelle schrieb:

Triggering layout sooner is the only way we are ever going to get FOP to 
accept arbitrarily large tables, without consuming massive amounts of 
heap.


It is little OT, but multipass would be another way - at the cost of 
runtime and diskspace/-access (if the memory footprint should be shrinked).
I know it is not a issue now, but I sometimes think [1] of how the 
"formating objects for indexing" (section 6.10 of xsl 1.1) could be 
implemented and it always ends in a multipass solution because in 
contrast to page-number-citation it is hardly possible to guess how much 
space to reserve for the resulting index-page-citation-list.


Indexing would be a great help for my project - I do it currently by 
creating as much page-number-citations as needed but without beeing able 
to use any advanced features, so I end up with long lists of pagenumbers 
that could/should be merged to page-ranges. It is not realy a big 
problem because it is a "private" project, but I want to keep the door 
open for a better solution that is contained in the standard.


Nevertheless resolving as much as possible at the FO tree building stage 
and trigger an earlier layout process would be an advantage for most use 
cases.



gerhard

[1] Yes, "thinking" is all what I do at present ;-)))

DO NOT REPLY [Bug 43658] New: - [PATCH] PS Renderer Bug rendered jobs connot be printed on duplex printers

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

   Summary: [PATCH] PS Renderer  Bug   rendered jobs connot be
printed on duplex printers
   Product: Fop
   Version: 0.94
  Platform: All
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: ps
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


[PATCH]
The problem here is testing. I don't have a duplex-capable printer so I
can test the behaviour. You obviously do. Can you please try to fix the
problem in code yourself and post a patch?

Jeremias Maerki

On 28.09.2007 10:18:02 Thomas Margreiter wrote:
> we have updated from FOP 0.20.5 to 0.94 FOP and since this update we cannot
> print in duplex-mode because the fop-renderers send on every page a page-Size
> statement 
> for example in PCL we get on each side a 'ESC &l1O'  for landscapeA4 ! 
> when we print this on HP-Printers (HP 4530, HP 4000, Brother Printers ... ) 
the
> printer disables the duplex-mode because it recognizes a new Page-size ) only
> xerox printers ignore the page-size command on every page ! 
>

... the same problem also exists with the PS-Renderer (PageSetup - command)

-- 
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: Improving Keeps and Breaks

[Andreas L Delmelle]

On Oct 19, 2007, at 13:32, Vincent Hennebert wrote:


Andreas L Delmelle wrote:

On Oct 18, 2007, at 19:23, Vincent Hennebert wrote:


I think I see your point. Basically you’re proposing a push  
method (a LM
notifies its parent LM that it has a break-before) while mine is  
a pull

method (a LM asks its children LMs if they have break-before).


Yep, although it would not be the LM but rather the FO that pushes  
the

break-before upwards to its parent if it is also the first child. The


Sure, of course. BTW, that may be a dumb question, but: how does a FO
know that it is the first child of its parent? AFAICT there’s no such
information in the FObjs.


Oh, that's pretty easy. Each FObj has a firstChild member, so the  
most straightforward idiom for this would be something like:


if (parent.firstChild == null) { ... } //if checking before  
addChildNode() has been called
if (this == parent.firstChild) { ... } //if you check after  
addChildNode() has been called



Which means that an object would blindly
notify its parent that it has a break, and that would be up to the
parent to figure out whether it should take it into account or not.
Would be a bit overkill, wouldn’t it?


No, it wouldn't.

Or at least: depends on what you mean exactly by 'overkill'?

LMs would largely continue to work as they do now, except that  
under a
certain set of conditions, they don't need to check the outside  
anymore:
only take into account the forced break on its own FO. If there is  
none,

then no need to recursively check for first descendants having forced
breaks.


Of course, but I’m concerned about spreading code relevant to the same
functionality over several places of the codebase.


That will always be a concern. If you separate some related logic  
into YAUC[*], the same reasoning applies, IMO. Even if the logic is  
contained in a separate class, you still have to look at/know of the  
other classes.


[*] (yet-another-utility-class)



Keeping in mind the above mentioned idea of triggering layout  
sooner, if

we can guarantee that the layoutengine always receives complete rows,
then the table-layout job should become a bit simpler in the general
use-case, while still not adding much complexity in trickier, more
exotic cases, like:
//table-cell/block[position() > [EMAIL PROTECTED]'page']


That one triggers a break /inside/ the table-row, not before it.


What I meant precisely... and, in practice, this will occur far less  
often than forced breaks on the first block in a cell, IIC.



Anyway, at a given LM level the work to do looks simple enough to me.



especially where the cell's column-number corresponds to the highest
column-number.

Triggering layout sooner is the only way we are ever going to get  
FOP to

accept arbitrarily large tables, without consuming massive amounts of
heap. A 'simple' grid of 5 x 500 cells generates +5000 FONodes
(table-cells must have at least one block each) that stay in memory
until the page-sequence is completely finished. I wonder how many
break-possibilities that generates... :/


Like said above, I don’t think anything in my approach prevents that
from happening.


Indeed not. Did I say anything else?

A matter of taste, probably, but I think I’d prefer the pull  
method: the
LM performs requests to the appropriate children LMs exactly when  
and if

needed.


The only thing an LM should initially pull/request from its children,
AFAIU, is a list of elements, given a certain LayoutContext.
When composing its own element list, an LM should ideally be able to
rely on the lists it receives from its children. Then add/delete/ 
update

elements and (un)wrap, depending on context that is unknown or
irrelevant to the child.


That one I don’t quite agree with. Although I thought of it too on
a first step. I think it’s more complicated to play with a list of
elements, try and get the first one from children if any, create a new
one if necessary, change the break context (column, page) if needed,
etc., rather than simply request the applicable children LMs for their
break-before values. And again, in the case of tables that means that
the merging algorithm needs to deal with many possibilities of break
elements to occur. That’s really not its job I think.



That may simplify code as well (and improve its readability) as
some form of pull method is necessary anyway (the
mustKeepWithPrevious/WithNext/Together methods).


Keeps are a different story indeed. Big difference is that keeps have
strengths, and breaks do not.


Yes, but keeps and breaks are handled at the same place, mainly, when
a LM considers the stacking of children LMs (BlockLM, for example).  
And

the treatment is very similar.


The point is that the layoutengine/-algorithm can focus on the keeps,  
since the breaks would have been 'normalized' (since it is very easy  
to do so; for keeps this much less straightforward, since the  
strengths need to be considered as well, so that might indeed lead to  
unneces

DO NOT REPLY [Bug 43658] - [PATCH] PS Renderer Bug rendered jobs connot be printed on duplex printers

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-10-19 06:52 ---
This is not a bug. See my post [1] on fop-user on how to configure FOP to 
generate Postscript that works on a Duplex (HP) Printer.

I don't mean to sound ungrateful, but I did explain this to you on the mailing 
list yesterday. Your patch is invalid since it replicates existing 
functionality. The PSPageDeviceDictionary class is already capable of de-
duplicating page device settings if they don't change between pages.

[1] http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-
users/200710.mbox/[EMAIL PROTECTED]

-- 
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 43658] - [PATCH] PS Renderer Bug rendered jobs connot be printed on duplex printers

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





--- Additional Comments From [EMAIL PROTECTED]  2007-10-19 06:16 ---
Created an attachment (id=21011)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21011&action=view)
patch file for Bug 43658


-- 
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 43650] - [PATCH] PCL Renderer Bug rendered jobs connot be printed on duplex printers

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|PCL Renderer  Bug   rendered|[PATCH] PCL Renderer  Bug
   |jobs connot be printed on   |rendered jobs connot be
   |duplex printers |printed on duplex printers




-- 
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: font selection by character

[Jeremias Maerki]

Great, thanks for looking into it! AFAIU, your concept is right. The
spec refers to CSS on how to handly the font selection (see [1]).

But I also think that's the minimal algorithm. If you have two Symbol
characters and a space between, it's probably slightly better-looking to
use Symbol's space character, i.e. no font-family change for only
white-space. But I'd stick to what's easier to implement, first.

CSS also defines a font-matching concept which, AFAIU, kicks in when
mere font-selection doesn't help anymore. But IMO, that's another
building site which shouldn't be too difficult to add once we have the
basic infrastructure for char-by-char font selection.

[1] http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-family
[2] http://www.w3.org/TR/REC-CSS2/fonts.html#algorithm

Jeremias Maerki



On 19.10.2007 13:50:55 Manuel Mall wrote:
> Because the issue of font selection by character was raised again on 
> fop-user I have started to look at it as the appropriate font data 
> structures are now in place.
> 
> I am just looking for a confirmation here of the selection algorithm. My 
> understanding is that for each character, independent of its context, 
> the font list is searched for the first font with a matching glyph. 
> This means in particular for characters like space and hyphen (as used 
> for hyphenation), they will always be taken from the first font 
> containing them even if their 'neighbouring' characters are from a 
> different font?
> 
> Manuel

font selection by character

[Manuel Mall]

Because the issue of font selection by character was raised again on 
fop-user I have started to look at it as the appropriate font data 
structures are now in place.

I am just looking for a confirmation here of the selection algorithm. My 
understanding is that for each character, independent of its context, 
the font list is searched for the first font with a matching glyph. 
This means in particular for characters like space and hyphen (as used 
for hyphenation), they will always be taken from the first font 
containing them even if their 'neighbouring' characters are from a 
different font?

Manuel

Re: Improving Keeps and Breaks

[Vincent Hennebert]

Hi Andreas,

Andreas L Delmelle wrote:
> On Oct 18, 2007, at 19:23, Vincent Hennebert wrote:

>> I think I see your point. Basically you’re proposing a push method (a LM
>> notifies its parent LM that it has a break-before) while mine is a pull
>> method (a LM asks its children LMs if they have break-before).
> 
> Yep, although it would not be the LM but rather the FO that pushes the
> break-before upwards to its parent if it is also the first child. The

Sure, of course. BTW, that may be a dumb question, but: how does a FO 
know that it is the first child of its parent? AFAICT there’s no such 
information in the FObjs. Which means that an object would blindly 
notify its parent that it has a break, and that would be up to the 
parent to figure out whether it should take it into account or not. 
Would be a bit overkill, wouldn’t it?


> LMs would largely continue to work as they do now, except that under a
> certain set of conditions, they don't need to check the outside anymore:
> only take into account the forced break on its own FO. If there is none,
> then no need to recursively check for first descendants having forced
> breaks.

Of course, but I’m concerned about spreading code relevant to the same 
functionality over several places of the codebase.


> Currently (sorry if it becomes boring to stress this) the construction
> of the layout-tree starts only when the end-of-page-sequence event
> occurs. I still see room for changing this in the future, and so I need
> to consider the effects on the layout-algorithm as well: the algorithm
> will, for instance, no longer be able to rely on *all* childLMs being
> available the first time it enters the loop... The last childLM in an
> iteration might turn out to be not-the-last-one-after-all. For many
> following FONodes, the LMs do not exist yet at that point. Not in my
> head, at least. ;-)

I think nothing would prevent the layout process from being started 
earlier. On most FOs only the first child needs to be checked for 
a break. And for a table, only the first row needs to be retrieved in 
order to know if a break must occur before it. That’s another topic, but 
we could imagine that FObj instances and corresponding LMs are 
dynamically created when requested by a parent LM. Whereas at the 
(child) FObj level, it’s unclear to me how we will be able to say that 
we know enough to start the layout, and that we don’t need to grab 
further children FObjs.


> Anyway, I remember that when I implemented implicit column-numbers, I
> also gave TableBody an instance member to check whether we are adding
> cells in the first row or not, so this particular case would be easily
> addressed. (Checking... yep, it's still there.)
> 
> Come to think of tables, I'd consider 'propagation' in terms of pushing
> a forced break on a cell to the first cell in the row.
> In the table-layout code, at the point where we have a reference to the
> row or the first cell in a row, we would immediately know whether there
> is a forced break on a first descendant in any of the following sibling
> cells without having to request the corresponding childLMs and trigger a
> tree-traversal of who-knows-how-many levels.
> 
> Keeping in mind the above mentioned idea of triggering layout sooner, if
> we can guarantee that the layoutengine always receives complete rows,
> then the table-layout job should become a bit simpler in the general
> use-case, while still not adding much complexity in trickier, more
> exotic cases, like:
> //table-cell/block[position() > [EMAIL PROTECTED]'page']

That one triggers a break /inside/ the table-row, not before it. Anyway, 
at a given LM level the work to do looks simple enough to me.


> especially where the cell's column-number corresponds to the highest
> column-number.
> 
> Triggering layout sooner is the only way we are ever going to get FOP to
> accept arbitrarily large tables, without consuming massive amounts of
> heap. A 'simple' grid of 5 x 500 cells generates +5000 FONodes
> (table-cells must have at least one block each) that stay in memory
> until the page-sequence is completely finished. I wonder how many
> break-possibilities that generates... :/

Like said above, I don’t think anything in my approach prevents that 
from happening.


>> A matter of taste, probably, but I think I’d prefer the pull method: the
>> LM performs requests to the appropriate children LMs exactly when and if
>> needed.
> 
> The only thing an LM should initially pull/request from its children,
> AFAIU, is a list of elements, given a certain LayoutContext.
> When composing its own element list, an LM should ideally be able to
> rely on the lists it receives from its children. Then add/delete/update
> elements and (un)wrap, depending on context that is unknown or
> irrelevant to the child.

That one I don’t quite agree with. Although I thought of it too on 
a first step. I think it’s more complicated to play with a list of 
elements, try and get the first one from ch