Re: font selection by character
> On Jul 20, 2007, at 05:47, Manuel Mall wrote: > > As to how the TextLM should then further handle it, I hadn't really > looked deeper into so far, but it seems like you have... 8-) Andreas, how about this as a way forward: You implement the font lists in the Property system / FO Tree and I deal with the implementation of the font selection based on char, Knuth box and area creation logic in TextLM using the font data structures you come up with? > > Cheers > > Andreas > Manuel
Caching CommonHyphenation (was: Re: The effect of the property cache ...)
On Jul 19, 2007, at 00:36, Andreas L Delmelle wrote:
On Jul 18, 2007, at 23:18, Jeremias Maerki wrote:
- One of the easiest candidates for another flyweight is probably
CommonHyphenation (56K instances, 2.3MB in my example). The few
member
variables could probably just be concatenated to a String (to be
used as
the key).
Interesting idea, will look into that asap.
FWIW:
Looked a bit closer at this, and it suddenly struck me that all the
base Property types, apart from CharacterProperty which I overlooked
as a possible candidate, were already cached:
StringProperty -> language, country, script
NumberProperty -> hyphenation-push/remain-character-count
EnumProperty -> hyphenate
CharacterProperty(*) -> hyphenation-character
(*) now also added, see http://svn.apache.org/viewvc?view=rev&rev=557814
This means we currently end up in the strange situation where
different/separate CommonHyphenation instances are generated from
identical sets of base Property instances.
Maybe the CommonHyphenation bundle could store references to the
original properties themselves instead of duplicating their content/
value and storing them as primitives? By itself, this should be
roughly the same in terms of overall memory consumption: replacement
of some primitives with references.
In that case, one of the additional benefits of the individual
Property caching is that you can now actually avoid calls to
StringProperty.equals() in the rest of the code. "identity" means the
same as "equality" here, so the fastest possible implementation for
CommonHyphenation.equals() would then come to look like:
public final class CommonHyphenation {
...
public final StringProperty language;
public final StringProperty script;
public final StringProperty country;
public final EnumProperty hyphenate;
...
public boolean equals(Object obj) {
if (obj == this) {
return true;
}
if (obj instanceof CommonHyphenation) {
CommonHyphenation ch = (CommonHyphenation) obj;
return (ch.language == this.language
&& ch.script == this.script
&& ch.country == this.country
&& ch.hyphenate == this.hyphenate
&& ...)
}
return false;
}
One thing that cannot be avoided is the multiple calls to
PropertyList.get() to get to the properties that are needed to
perform the check for a flyweight bundle. Maybe the initial
assignments can be moved into the getInstance() method, so they
become part of the static code. getInstance() would get a
PropertyList as argument, while the private constructor signature is
altered to accept all the base properties as parameters.
The key in the Map could be a composite String, but could also again
be the CommonHyphenation itself, if a decent hashCode()
implementation is added.
The benefit of using the instance itself is that the key in a
WeakHashMap is automatically released after the last object referring
to it has been cleared. Using a key other than the instance itself
would make WeakHashMap unusable, since the keys are in that case not
referenced directly by any object. The key cannot be embedded in the
instance itself, since that would prevent the entire entry from ever
being released...
The properties themselves being immutable and final, I guess it does
no harm to expose them as public members. Only a handful of places in
TextLM and LineLM would need a slight adjustment to compensate for
the lost getString() and getEnum() conversions. Maybe for
convenience, if really needed, accessors could be added like:
public String language() {
return language.getString();
}
...
public boolean hyphenate() {
return (hyphenate.getEnum() == EN_TRUE);
Opinions?
For the interested parties: full CommonHyphenation below, following
roughly the same principles as the Property caching.
Cheers
Andreas
--- Sample code ---
public final class CommonHyphenation {
private static final Map cache =
java.util.Collections.synchronizedMap(
new java.util.WeakHashMap());
private int hash = 0;
/** The "language" property */
private final StringProperty language;
/** The "country" property */
private final StringProperty country;
/** The "script" property */
private final StringProperty script;
/** The "hyphenate" property */
private final EnumProperty hyphenate;
/** The "hyphenation-character" property */
private final CharacterProperty hyphenationCharacter;
/** The "hyphenation-push-character-count" property */
private final NumberProperty hyphenationPushCharacterCount;
/** The "hyphenation-remain-character-count" property*/
private final NumberProperty hyphenationRemainCharacterCount;
/**
* Construct a CommonHyphenation object holding the given
properties
*
*/
private CommonHyphenation(StringProperty language,
StringProperty country,
Re: font selection by character
On Jul 20, 2007, at 05:47, Manuel Mall wrote: Moving this to a separate thread with a more meaningful subject (at least I think so). Looking back at something like font-selection strategy: the more I look at it, the more I agree with the initial suggestion to deal with it during the layout-phase. Instead of generating multiple FOText instances that are tied to different fonts, the CommonFont information should precisely be moved away from the FOText. I agree with the sentiment that this is a layout function and that generating separate FOText nodes during parsing is not the way to go. What ultimately convinced me was a suggestion (from way back when) that certain merging and substitution of unicode sequences into characters should also be performed much later in the process (if and when implemented). I would presume that font-selection needs to take into account the results after those have been applied. In my mind if we solve the issue how to get the applicable font list to TextLM the task of modifying TextLM to generate separate knuth boxes and later areas when the font changes shouldn't be too hard. Yes, there are text alignment issues to be dealt with but that could even be deferred to a second step. So, instead of a CommonFont object do we need a List object in the FO tree to deal with this? Not exactly a list of CommonFont info, if I'm correct, but more a list of references to the Font instances that are covered by each CommonFont. In fact, if you look at CommonFont, apart from the private fontState, it seems to be a possible candidate for caching as well. The only obstacle is the font-size, which can be percentage. AFAICT, this makes each CommonFont instance essentially dependent on the FO it is attached to... The image that was beginning to take form in my mind for the basic font-family fallback implementation: - make it CommonFont.fontState*s* a List instead of a single Font and - either add a char parameter to CommonFont.getFontState(), and have it return the first Font instance containing a mapping for the given char - or make it getFontStates() and have it return the entire List for the TextLM to sort out As to how the TextLM should then further handle it, I hadn't really looked deeper into so far, but it seems like you have... 8-) Cheers Andreas
font selection by character
Moving this to a separate thread with a more meaningful subject (at least I think so). > Looking back at something like font-selection strategy: the more I > look at it, the more I agree with the initial suggestion to deal with > it during the layout-phase. Instead of generating multiple FOText > instances that are tied to different fonts, the CommonFont > information should precisely be moved away from the FOText. I agree with the sentiment that this is a layout function and that generating separate FOText nodes during parsing is not the way to go. In my mind if we solve the issue how to get the applicable font list to TextLM the task of modifying TextLM to generate separate knuth boxes and later areas when the font changes shouldn't be too hard. Yes, there are text alignment issues to be dealt with but that could even be deferred to a second step. So, instead of a CommonFont object do we need a List object in the FO tree to deal with this? Any ideas, suggestions from the property gurus? Manuel
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Jul 20, 2007, at 01:17, Manuel Mall wrote: Nothing. I just don't like those being bound to the text either... Why duplicate the font-, alignment- and other info on the FOText descendant? Either there is no need to store them at the higher level at all, or they are always available from the parent so there is no compelling reason to bind them to the FOText as well. The main reason is that our object hierarchy does not easily allow to retrieve that without messy tests instanceof tests and typecasts. If you want to re-architect the object hierarchy within the fo tree just to avoid the need to bind against FOText, please by my guest. Well, it has been on my mind to do so, actually, albeit not just to avoid this binding. No priority so far. It's working. Never mind if the design is suboptimal --at least, nobody else seems to mind. :-) My point exactly. Good, so why all the fuss about this particular relatively small commit then? Hmm, Fuss? :-/ I wasn't making any fuss... Was I? Cheers Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Friday 20 July 2007 01:11, Andreas L Delmelle wrote: > On Jul 19, 2007, at 18:45, Manuel Mall wrote: > >> > >> And in doing so, we would eventually end up back where FOP Trunk > >> started in 2002: a monolithic black box, which becomes harder and > >> harder to maintain and extend over time. > >> > >> That's more the nature of my concern: that we do not fall prey to > >> bad old habits. > > > > I don't get your point in this context. What is different to > > binding the Font, Alignment, Color, ... properties to FOText to > > binding the Keep-together property to it? > > Nothing. I just don't like those being bound to the text either... > Why duplicate the font-, alignment- and other info on the FOText > descendant? Either there is no need to store them at the higher level > at all, or they are always available from the parent so there is no > compelling reason to bind them to the FOText as well. The main reason is that our object hierarchy does not easily allow to retrieve that without messy tests instanceof tests and typecasts. If you want to re-architect the object hierarchy within the fo tree just to avoid the need to bind against FOText, please by my guest. > Looking back at something like font-selection strategy: the more I > look at it, the more I agree with the initial suggestion to deal with > it during the layout-phase. Instead of generating multiple FOText > instances that are tied to different fonts, the CommonFont > information should precisely be moved away from the FOText. > This has more to do with CommonFont not being designed to handle list of fonts then its binding to FOText. If the logic for font selection is better placed in the TextLM we just need to give it the required data to be able to do so. If CommonFont can't do it we either need to redesign CommonFont or have another object that models font lists. > > Same principle, nothing new introduced here that wasn't there > > before. > > My point exactly. > Good, so why all the fuss about this particular relatively small commit then? > Cheers > > Andreas Manuel
Bounty for auto table layout?
Hi there, I'm really interested in having auto table layout implemented in FOP. Bug 40271 has a patch, but for nearly eight months there was no activity. So I thought that perhaps a fund/bounty might motivate a developer to implement this feature. As I use FOP only for non-commercial purposes, my own share wouldn't be enourmous (surely below 100 USD), but I hope others would join the effort to make the sum interesting. What do you all think? Is this a viable option, i.e. would it be accepted within the project? Was something like that done before at FOP or Apache in general? How could this be organized? Best regards, Jens
Re: OutOfMemoryError in current Trunk
On Jul 19, 2007, at 18:15, Andreas L Delmelle wrote:
On Jul 19, 2007, at 18:01, Chris Bowditch wrote:
Andreas L Delmelle wrote:
If there is anything special about that file, you could always
post it, but I'll try to see if I can reproduce with a simple FO
without special features. If I don't succeed, I might ask you to
post your code as well.
The FO file has some SVG embedded in fo:instream-foreign-object.
Important thing to check then, is if the problem persists without
the SVG. That could already give us a clue of the location.
FWIW, I did a quick while(true){...} test with a modified version of
our ExampleFO2PDF. With basic documents, I can't seem to reproduce
it. The last cycle, I stopped at 1 renderings, but I'm pretty
sure it would still be running if I hadn't. No noticeably slowdown
that would point towards the heap reaching its limits. No SVG tried yet.
Cheers
Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Jul 19, 2007, at 18:45, Manuel Mall wrote: And in doing so, we would eventually end up back where FOP Trunk started in 2002: a monolithic black box, which becomes harder and harder to maintain and extend over time. That's more the nature of my concern: that we do not fall prey to bad old habits. I don't get your point in this context. What is different to binding the Font, Alignment, Color, ... properties to FOText to binding the Keep-together property to it? Nothing. I just don't like those being bound to the text either... Why duplicate the font-, alignment- and other info on the FOText descendant? Either there is no need to store them at the higher level at all, or they are always available from the parent so there is no compelling reason to bind them to the FOText as well. Looking back at something like font-selection strategy: the more I look at it, the more I agree with the initial suggestion to deal with it during the layout-phase. Instead of generating multiple FOText instances that are tied to different fonts, the CommonFont information should precisely be moved away from the FOText. Same principle, nothing new introduced here that wasn't there before. My point exactly. FOText is the generic descendant of anything that can have text content being it a block, an inline, a wrapper, One could answer here that FOText corresponds to PCDATA in the source document, and PCDATA has no properties. FOText being indeed the 'generic descendant' results in there being roughly as many of those in any page-sequence as there are blocks, inlines, wrappers... put together (most likely even more: two or three FOTexts for a block with nested inlines or wrappers is not uncommon). Given that their ancestors already contain the exact same CommonFont info, I see no good reason at all to propagate all that info to FOText. I admit I am lost in your reasoning. Don't worry, I get that a lot. :-) Cheers Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Friday 20 July 2007 00:29, Andreas L Delmelle wrote: > On Jul 19, 2007, at 18:10, Andreas L Delmelle wrote: > > > > > >> There is not need for the inline obj to bind to the properties as > >> its LM > >> does not use them. > >> The bind is done only for the FOText as it is the > >> only object whose LM is currently making processing decisions on > >> it. > > > > See? And why is that? Because you decided to implement it that > > way. :-) > > > > Before your patch the property was not present on FOText, and was > > not dealt with by the TextLM, but now it is... > > Keeps and breaks on fo:blocks are definitely handled by the > > corresponding LM, so in that respect, your solution seems to > > introduce inconsistencies. > > Just to clarify: what I mean is, in the end, we could just as well > scrap the entire FO Tree and rewrite FOP to generate layoutmanagers > from the input directly. Who needs FONodes after all? What is their > use, if ultimately everything is handled by the LM anyway? > > And in doing so, we would eventually end up back where FOP Trunk > started in 2002: a monolithic black box, which becomes harder and > harder to maintain and extend over time. > > That's more the nature of my concern: that we do not fall prey to bad > old habits. > I don't get your point in this context. What is different to binding the Font, Alignment, Color, ... properties to FOText to binding the Keep-together property to it? Same principle, nothing new introduced here that wasn't there before. FOText is the generic descendant of anything that can have text content being it a block, an inline, a wrapper, I admit I am lost in your reasoning. > > Cheers > > Andreas Manuel
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Jul 19, 2007, at 18:10, Andreas L Delmelle wrote: There is not need for the inline obj to bind to the properties as its LM does not use them. The bind is done only for the FOText as it is the only object whose LM is currently making processing decisions on it. See? And why is that? Because you decided to implement it that way. :-) Before your patch the property was not present on FOText, and was not dealt with by the TextLM, but now it is... Keeps and breaks on fo:blocks are definitely handled by the corresponding LM, so in that respect, your solution seems to introduce inconsistencies. Just to clarify: what I mean is, in the end, we could just as well scrap the entire FO Tree and rewrite FOP to generate layoutmanagers from the input directly. Who needs FONodes after all? What is their use, if ultimately everything is handled by the LM anyway? And in doing so, we would eventually end up back where FOP Trunk started in 2002: a monolithic black box, which becomes harder and harder to maintain and extend over time. That's more the nature of my concern: that we do not fall prey to bad old habits. Cheers Andreas
Re: OutOfMemoryError in current Trunk
On Jul 19, 2007, at 18:01, Chris Bowditch wrote: Andreas L Delmelle wrote: If there is anything special about that file, you could always post it, but I'll try to see if I can reproduce with a simple FO without special features. If I don't succeed, I might ask you to post your code as well. The FO file has some SVG embedded in fo:instream-foreign-object. Important thing to check then, is if the problem persists without the SVG. That could already give us a clue of the location. Cheers Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Jul 19, 2007, at 16:10, Manuel Mall wrote: Now what does not completely sit right with me, is that the properties are still not accessible on the inline level. Your patch transfers the keeps to the FOText itself, instead of activating the property on inline-level FOs. That said, it obviously works, so no reason to complain. There is not need for the inline obj to bind to the properties as its LM does not use them. The bind is done only for the FOText as it is the only object whose LM is currently making processing decisions on it. See? And why is that? Because you decided to implement it that way. :-) Before your patch the property was not present on FOText, and was not dealt with by the TextLM, but now it is... Keeps and breaks on fo:blocks are definitely handled by the corresponding LM, so in that respect, your solution seems to introduce inconsistencies. No doubt it's the most convenient and quick way to solve it, but I'm wondering whether it is also qualitatively the best solution in the long run? Keep-with-next and keep-with-previous on fo:inlines, for instance, will have to be implemented someday as well. Cheers Andreas
Re: OutOfMemoryError in current Trunk
Andreas L Delmelle wrote: On Jul 19, 2007, at 16:37, Chris Bowditch wrote: Hi Chris I have been doing a little bit of testing with the current Trunk code and observed that I can generate an OutOfMemoryError simply by submitting the same 2 page document to FOP to render to Postscript over and over again. After just 2,900 renderings FOP dies with OutOfMemoryError. I think it is safe to assume that the memory leak exists in the current 0.94 branch also. I am keen to avoid releasing FOP whilst the code contains such a problem. If anyone is interested I can send you the FO file and test harness code I use to repeatidly generate PS off list. If there is anything special about that file, you could always post it, but I'll try to see if I can reproduce with a simple FO without special features. If I don't succeed, I might ask you to post your code as well. The FO file has some SVG embedded in fo:instream-foreign-object. Did you, by any chance, noticed a similar effect with other formats (which would indicate the leak is localized in the fotree or layout- code)? Yes, in one of the tests I was generating Area Tree XML with mimic Renderer set to the AFP Renderer and observed OOME. So I don't think the output format is relevant here. One of my colleagues is going to profile FOP. I will keep you all informed of any findings. Thanks, Chris
Re: OutOfMemoryError in current Trunk
On Jul 19, 2007, at 16:37, Chris Bowditch wrote: Hi Chris I have been doing a little bit of testing with the current Trunk code and observed that I can generate an OutOfMemoryError simply by submitting the same 2 page document to FOP to render to Postscript over and over again. After just 2,900 renderings FOP dies with OutOfMemoryError. I think it is safe to assume that the memory leak exists in the current 0.94 branch also. I am keen to avoid releasing FOP whilst the code contains such a problem. If anyone is interested I can send you the FO file and test harness code I use to repeatidly generate PS off list. If there is anything special about that file, you could always post it, but I'll try to see if I can reproduce with a simple FO without special features. If I don't succeed, I might ask you to post your code as well. Did you, by any chance, noticed a similar effect with other formats (which would indicate the leak is localized in the fotree or layout- code)? Cheers Andreas
OutOfMemoryError in current Trunk
Fellow Devs, I have been doing a little bit of testing with the current Trunk code and observed that I can generate an OutOfMemoryError simply by submitting the same 2 page document to FOP to render to Postscript over and over again. After just 2,900 renderings FOP dies with OutOfMemoryError. I think it is safe to assume that the memory leak exists in the current 0.94 branch also. I am keen to avoid releasing FOP whilst the code contains such a problem. If anyone is interested I can send you the FO file and test harness code I use to repeatidly generate PS off list. Hopefully at some point I will have time to profile FOP and figure out where the source of the memory leak is, but right now I don't have any more time, so this e-mail is just FYI. Chris
Re: AFP default font character set
On Thursday 19 July 2007 20:02, Adrian Cumiskey wrote: > Hi all, > > I have been looking at adding a new "No Operation" or > extension to the AFP renderer. I noticed that by > default (in the absence of any configuration) the AFPRenderer sets up > some base fonts which use the "CZH200 " character set. This > character set was not available on my IBM Infoprinter setup so I used > "C0N2" instead and it worked just fine. I was just wondering if > there was any particular reason why "CZH200 " was chosen? Is this > one of the most common font character sets that is available? > > Adrian. It was chosen because the font was available to me at the time and seem to most closely match the equivalent Base14 fonts. Same applies to the default monospaced and roman font setup. Any way, it was never the idea for this to be a useful feature when using AFP in a real IBM environment. Just a convenience when developing and using the AFPViewer application. Manuel
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Thursday 19 July 2007 19:49, Andreas L Delmelle wrote: > On Jul 19, 2007, at 13:34, Manuel Mall wrote: > > On Thursday 19 July 2007 19:27, Andreas L Delmelle wrote: > >> On Jul 19, 2007, at 04:06, Manuel Mall wrote: > >>> > >>> Sorry Andreas but I still don't get it. We have this test case > >>> > >>> This is >>> line="always">Blah blah blah blah! > >> > >> OK, then. Where ? > > > > inline_keep-together.xml line 39 > > Right... and where are are the fo:markers you were talking about? > Sorry my bad. I meant to write fo:wrapper not fo:marker. > Now what does not completely sit right with me, is that the > properties are still not accessible on the inline level. Your patch > transfers the keeps to the FOText itself, instead of activating the > property on inline-level FOs. > > That said, it obviously works, so no reason to complain. > There is not need for the inline obj to bind to the properties as its LM does not use them. The bind is done only for the FOText as it is the only object whose LM is currently making processing decisions on it. > > Cheers > > Andreas Cheers Manuel
Re: The effect of the property cache (or: playing around with a new toy)
On Jul 19, 2007, at 01:10, Andreas L Delmelle wrote: Number oneInt = new Integer(1); Number oneDouble = new Double(1.0); boolean check = (oneInt.hashCode() != oneDouble.hashCode()); => (check == true) Can this be relied upon? AFAICT, it can. Integer.hashCode() will simply return the int value, while Double.hashCode() uses Double.doubleToLongBits(), which should always produce different results, even if the numeric value is the same. The used implementations for equals(), I would presume to be safe: we can count on the fact that Integer oneInt = new Integer(1); check = (oneInt.equals(new Double(1))); check will always be false here. FTM, I have committed the change using the Number-subclass hashCode() implementations. Cheers Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Jul 19, 2007, at 10:49, Luca Furini wrote:
Hi Luca
Firstly, hi all! It has been quite a long time since I last posted
or committed anything, but I'm still here!. :-)
Then, congratulations for all the great progresses fop is making!
Good to see you're still monitoring. :-)
Andreas L. Delmelle wrote:
[inserting penalties with higher value to represent numeric keeps]
This should steer the line-breaking algorithm in the right
direction to satisfy all keep constraints, IIC. The only big
difference compared to an auto keep-constraint, if I judge
correctly, would then be that we would somehow have to use
penalties to represent all legal break-opportunities. Instead of
glues being considered as feasible breakpoints, they would always
be preceded by a zero-width penalty having a value corresponding
to the keep-constraint governing the base FO.
I'm not sure the "steering capability" of penalty values would be
enough to get the prescribed result [section 4.8 "Keeps and
breaks" (particularly the last paragraph)]: the algorithm could
still prefer violating a keep with force = N to satisfy some keeps
with force < N, as, IIRC, the demerits ultimately depends much more
on the necessary stretch / shrink than on the penalty value.
That's one detail I was still unsure about. Only if the other factors
remain identical, the algorithm would prefer a break at penalty 50
over one at penalty 100... but if the value of the penalty is only of
marginal influence as you suggest, then this would indeed not be enough.
I think that the breaking algorithm could be performed one time for
each distinct force value. Something like this:
lastConfirmedBreaks = ... the set of breaking points
considering only "always" keeps
ArrayList forceLevelList = findForceLevels(sequence); // in the
reversed order
int forceLevelIndex = 0;
boolean tryAgain = true;
while (tryAgain && forceLevelIndex <= forceLevelList.size() - 1) {
revisedSequence = setPenaltyValue(seq, lastConfirmedBreaks,
forceLevelList.get(i), HIGH_PENALTY_VALUE);
... compute the set of breaking points for revisedSequence
if (... they are still acceptable) {
lastConfirmedBreaks = ... these ones
i ++;
} else {
tryAgain = false
}
}
- in the sequence, keeps having force = "always" would be
represented by +INF penalties;
- keeps with numeric force start with a 0 penalty value;
Interesting, so the bottom-line would be:
- no explicit keep-constraint -> all remains as it is now
- explicit keep-constraints -> penalties are inserted at each
feasible break
-> "always" = +INF (immediately mark the feasible break as a non-
desirable one)
-> integer-keep = 0 (mark the feasible break, but do not set any
values yet)
- the method setPenaltyValue() sets those with the given force a
high value, and those with greater force (which have not been
chosen as breking points, this is why we must pass the computed
breaks too) are set to +INF so we are sure they would not be violated
If this approach is correct, the key point would be how to decide
whether or not the computed set of breaks is "still acceptable" ...
Well, it will ultimately take some tweaking, but I think your above
ideas are enough to get it working in basics. The only real tough one
will be: "How to express the satisfaction of the keep-constraints in
a formula?"
In the example I posted earlier:
Some text with "auto" keep-constraint
Some text with a keep.within-line constraint of "100"
keep.within-line="500"
Some more text in the first nested inline
More text after the first nested inline.
The "acceptable" set of breaks may turn out to give a result like
(with '|' = the end-boundary of the line)
Some text with "auto" keep-constraint" |(1)
Some text with a keep.within-line constraint of|(2)
"100" keep.within-line="500" |(3)
Some more text in the first nested inline |(4)
More text after the first nested inline|(5)
Line 1: no problem
Line 2: the text is wider than the line, and the keep is not
absolute, so relax it
Line 3: the content of the second nested inline fits together on a
line with the rest of the text under the first inline
Line 4: The remaining text of the first nested inline cannot fit on
the third line entirely, so move it to the next
Line 5: no problem
Only the third and the fourth line I'm still unsure about. May the
content in the fourth line be broken itself?
Thanks for the input!
Cheers
Andreas
AFP default font character set
Hi all, I have been looking at adding a new "No Operation" or extension to the AFP renderer. I noticed that by default (in the absence of any configuration) the AFPRenderer sets up some base fonts which use the "CZH200 " character set. This character set was not available on my IBM Infoprinter setup so I used "C0N2" instead and it worked just fine. I was just wondering if there was any particular reason why "CZH200 " was chosen? Is this one of the most common font character sets that is available? Adrian.
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Jul 19, 2007, at 13:34, Manuel Mall wrote: On Thursday 19 July 2007 19:27, Andreas L Delmelle wrote: On Jul 19, 2007, at 04:06, Manuel Mall wrote: Sorry Andreas but I still don't get it. We have this test case This is Blah blah blah blah! OK, then. Where ? inline_keep-together.xml line 39 Right... and where are are the fo:markers you were talking about? Now what does not completely sit right with me, is that the properties are still not accessible on the inline level. Your patch transfers the keeps to the FOText itself, instead of activating the property on inline-level FOs. That said, it obviously works, so no reason to complain. Cheers Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Thursday 19 July 2007 19:27, Andreas L Delmelle wrote: > On Jul 19, 2007, at 04:06, Manuel Mall wrote: > > > > Sorry Andreas but I still don't get it. We have this test case > > > > This is > line="always">Blah blah blah blah! > > OK, then. Where ? > inline_keep-together.xml line 39 > > Cheers > > Andreas Manuel
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
On Jul 19, 2007, at 04:06, Manuel Mall wrote: Sorry Andreas but I still don't get it. We have this test case This is Blah blah blah blah! OK, then. Where ? Cheers Andreas
Re: svn commit: r557347 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/layoutmgr/inline/ test/layoutengine/ test/layoutengine/stan
Firstly, hi all! It has been quite a long time since I last posted or
committed anything, but I'm still here!. :-)
Then, congratulations for all the great progresses fop is making!
And finally, concerning the keeps ...
Andreas L. Delmelle wrote:
[inserting penalties with higher value to represent numeric keeps]
This should steer the line-breaking algorithm in the right direction
to satisfy all keep constraints, IIC. The only big difference
compared to an auto keep-constraint, if I judge correctly, would then
be that we would somehow have to use penalties to represent all legal
break-opportunities. Instead of glues being considered as feasible
breakpoints, they would always be preceded by a zero-width penalty
having a value corresponding to the keep-constraint governing the
base FO.
I'm not sure the "steering capability" of penalty values would be enough
to get the prescribed result [section 4.8 "Keeps and breaks" (particularly
the last paragraph)]: the algorithm could still prefer violating a keep
with force = N to satisfy some keeps with force < N, as, IIRC, the
demerits ultimately depends much more on the necessary stretch / shrink
than on the penalty value.
I think that the breaking algorithm could be performed one time for each
distinct force value. Something like this:
lastConfirmedBreaks = ... the set of breaking points considering only
"always" keeps
ArrayList forceLevelList = findForceLevels(sequence); // in the reversed
order
int forceLevelIndex = 0;
boolean tryAgain = true;
while (tryAgain && forceLevelIndex <= forceLevelList.size() - 1) {
revisedSequence = setPenaltyValue(seq, lastConfirmedBreaks,
forceLevelList.get(i), HIGH_PENALTY_VALUE);
... compute the set of breaking points for revisedSequence
if (... they are still acceptable) {
lastConfirmedBreaks = ... these ones
i ++;
} else {
tryAgain = false
}
}
- in the sequence, keeps having force = "always" would be represented by
+INF penalties;
- keeps with numeric force start with a 0 penalty value;
- the method setPenaltyValue() sets those with the given force a high
value, and those with greater force (which have not been chosen as breking
points, this is why we must pass the computed breaks too) are set to +INF
so we are sure they would not be violated
If this approach is correct, the key point would be how to decide whether
or not the computed set of breaks is "still acceptable" ...
Hope this helps ...
Luca
Re: Lines breaking on '/' and '-'
Jeremias Maerki wrote: On 18.07.2007 18:00:57 Andreas L Delmelle wrote: On Jul 18, 2007, at 17:44, Manuel Mall wrote: Hi Manuel This proposed patch seems to cause a side-effect I would like a clarification on. The following fo snippet some long text used to have the effect of keeping "some long text" on a single page. After my patch it would also keep "some long text" on a single line! keep-together is an inherited property and it seems keep-together="always" is just a shorthand for keep-together.within-page="always" keep-together.within-line="always" keep-together.within-column="always" That is how I would interpret it. Me too. It is also how other popular commercial renderers work, so I'm +1000 for this change! I'm impressed that you have implemented keep-together.within-line so easily. Thanks Manuel! Chris
