Re: Improving Keeps and Breaks
On Oct 19, 2007, at 13:32, Vincent Hennebert wrote:
Andreas L Delmelle wrote:
On Oct 18, 2007, at 19:23, Vincent Hennebert wrote:
snip/
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)
snip /
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
DO NOT REPLY [Bug 43658] - [PATCH] PS Renderer Bug rendered jobs connot be printed on duplex printers
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=43658. 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
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=43658. 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=21011action=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
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=43650. 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
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
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
Hi Andreas, Andreas L Delmelle wrote: On Oct 18, 2007, at 19:23, Vincent Hennebert wrote: snip/ 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 children if any, create a new one if necessary, change the
